文件中包含大量部件,很容易找到合适的部件大小(因为可能的部件大小的排列数量有限,并且部件大小通常可以假设落在 MiB 或 MB 边界上)。
然而,对于给定的上传,随着部分数量的减少,部分大小的多种不同可能性会出现,并且很难有一个算法来猜测该数量并且耗时来确认计算。
了解部分大小很有用,因为当有效负载匹配时,S3 中用于 ETag 计算的算法只会为两个相同的对象生成相同的值并且这两个对象是在上传期间使用相同的部分大小创建的。 否则,它会为两个相同的对象生成不同的 ETag 值。 (HTTP 本身不要求两个相同的对象具有相同的 ETag,但匹配 ETag 值对于完整性验证很有用)。
是否可以了解用于上传 S3 中现有对象的部分大小?
我会回答我自己的问题,因为这已经困扰我一段时间了,我刚刚找到了解决这个问题的方法。对于复制存储桶的内容,我见过的大多数(如果不是全部)解决方案都采用猜测部分大小,并简单地放弃在源存储桶和目标存储桶上具有匹配 etag 的想法。有趣的是,aws 自己发布了钟楼框架,该框架依靠猜测部件号,并且仅假设它已被 aws cli 工具复制。
事实证明,有一种记录在案的方法可以做到这一点:aws cli 工具有一个 get-object 和 head-object api 选项,它可以让您指定您想要的部件号,如下所示:
aws s3api head-object --bucket YOURBUCKET --key YOURKEY --part-number 1
这将返回一个如下所示的标头:
{
"AcceptRanges": "bytes",
"ContentType": "application/octet-stream",
"LastModified": "Mon, 31 Jul 2017 08:23:11 GMT",
"ContentLength": 8388608,
"ETag": "\"XXXX-6\"",
"ServerSideEncryption": "AES256",
"PartsCount": 6,
"Metadata": {}
}
在这种情况下,正如您所看到的,我们通过第 1 部分的 ContentLength 标头得知此上传的部分大小应该是多少:即 8 MB,与用于上传此对象的大小相同...
如果你使用 --debug 标志,你可以看到这是如何在 REST 世界中完成的:他们只是添加一个 url 参数partNumber=1
aws --debug s3api head-object --bucket YOURBUCKET --key YOURKEY --part-number 1
....
2017-07-31 16:21:46,968 - MainThread - botocore.endpoint - DEBUG - Making request for OperationModel(name=HeadObject) (verify_ssl=True) with params:
{'body': '', 'url': u'https://s3.amazonaws.com/YOURKEY/?partNumber=1',
'headers': {'User-Agent': 'aws-cli/1.11.127 Python/2.7.12 Linux/4.4.35-33.55.amzn1.x86_64 botocore/1.5.90'},
'context': {'auth_type': None, 'client_region': 'us-east-1', 'signing': {'bucket': u'YOURBUCKET'}, 'has_streaming_input': False, 'client_config': <botocore.config.Config object at 0x7f20a8e1ff50>},
-----> 'query_string': {u'partNumber': 1}, <-----
'url_path': u'/YOURBUCKET/YOURKEY', 'method': u'HEAD'}
....
下一步是弄清楚如何签署此类网址。 aws cli 命令“aws s3 presign”无法执行此操作。
当我尝试通过 AWS Batch 提交的代码将大文件上传到 S3 时,这对我很有帮助。我遇到以下错误:
“无法解析 ExceptionName:InvalidArgument 消息:部件号必须是 1 到 10000 之间的整数(含 1 和 10000)。”
我必须弄清楚默认部分大小到底是多少,以及有多少部分用于其他上传。 Gery 的答案中建议的命令很有帮助。