我正在使用Amazon弹性转码器结合Lambda和Step函数从WAV文件中转码MP3
我需要在数据库中存储转码MP3的MD5/S3ETag
头值
目前,我必须在一个单独的过程中使用这些来获取这些,这非常缓慢:
s3_cli = boto3.client("s3",aws_access_key_id=ACCESS_KEY,aws_secret_access_key=SECRET_KEY)
s3_resp = s3_cli.head_object(Bucket=bucket, Key=mp3_key)
s3obj_etag = s3_resp['ETag'].replace('"', '')
在此之前,我希望Elastic Transcoder能够在作业响应中提供转码文件MD5哈希,但我在任何地方都看不到
有没有人对如何更好地处理这个问题有什么建议,或者我在回复/文档中遗漏了什么
不幸的是,它没有。
截至当前的AWS Python Boto3 1.18.60 SDK(或任何其他SDK,包括REST API),输出对象的实体标记不会返回job response object中的任何位置
这很可能是因为实体标记表示对象的特定版本,并且主要用于高效缓存失效
弹性转码器作业不会产生相同输出的多个版本,因此,为什么它会返回
ETag
值?如果有人需要ETag,他们可以从S3对象获得它另一个问题是,如果大输入有多部分输出,会发生什么?SDK返回什么?一个列表的
ETag
头值?您有多个部件,但没有多个版本这一实施将违反RFC 7232 specification for the ^{} header :
在本例中,您的实际问题是,您需要文件的MD5哈希,即使它们是多部分的
现在,您的代码将用于获取单个文件的MD5哈希值,但是如果它们是多部分的,则不会像您预期的那样对多部分上载进行哈希。Amazon不计算整个文件的散列,而是计算每个部分的散列,然后将其组合成单个散列集作为
ETag
头这很有意义:他们在接收每个部分时计算每个部分的哈希值。传输完所有部分后,他们将合并散列,而不是通过读取可能达到AWS对象大小限制的文件来计算最终MD5散列-5TB。在Amazon的scale&;下,尝试为每个人的文件生成MD5哈希;你会发现他们的方式很聪明:)
这可能就是为什么S3 API Reference会这样说:
它是一个MD5散列,但是当它是一个多部分上传时,不是,所以上面的技术是正确的
要正确计算多部分上传的MD5哈希,请尝试检查这个伟大的answer以响应"What is the algorithm to compute the Amazon-S3 Etag for a file larger than 5GB?"
总之,不幸的是,您在Amazon Elastic Transcoder返回的响应中没有对象的MD5摘要哈希-您必须自己完成这项繁重的工作&;如果你有巨大的文件,这可能需要很长时间
没有解决方法或更快的解决方案-您拥有最快的解决方案,因为您已经以最有效的方式从头部获取了
ETag
值我可能会建议在尝试确定文件的最终MD5摘要之前,尝试并行HTTP头请求以获取对象的元数据(
s3_cli.head_object(...)
)例如,如果您有500个文件,这肯定会加快速度-不要单独进行API请求
您肯定能够并行发送它们,因此将请求之间花费的时间全部转移到Amazon的基础设施上
获得回应&;然后一起处理
相关问题 更多 >
编程相关推荐