新的“S3提高请求率性能”公告是什么意思

Joh*_*ees 13 performance amazon-s3 amazon-web-services

2018 年 7 月 17 日,AWS 发布了一份官方公告,解释说不再需要随机化每个 S3 对象键的第一个字符来实现最佳性能:https : //aws.amazon.com/about-aws/whats-new /2018/07/amazon-s3-announces-increased-request-rate-performance/

Amazon S3 宣布提高请求率性能

发表于:2018 年 7 月 17 日

Amazon S3 现在提供更高的性能,以支持每秒至少 3,500 个添加数据的请求和每秒 5,500 个检索数据的请求,这可以节省大量处理时间而无需额外费用。每个 S3 前缀都可以支持这些请求率,从而可以轻松显着提高性能。

今天在 Amazon S3 上运行的应用程序无需更改即可享受这种性能改进,在 S3 上构建新应用程序的客户无需进行任何应用程序自定义即可实现此性能。Amazon S3 对并行请求的支持意味着您可以根据计算集群的系数扩展 S3 性能,而无需对应用程序进行任何自定义。性能按前缀扩展,因此您可以并行使用任意数量的前缀来实现所需的吞吐量。前缀的数量没有限制。

这种 S3 请求速率性能提升消除了任何先前的指导,即随机化对象前缀以实现更快的性能。这意味着您现在可以在 S3 对象命名中使用逻辑或顺序命名模式,而不会对性能产生任何影响。此改进现已在所有 AWS 区域推出。有关更多信息,请访问 Amazon S3 开发人员指南。

这很好,但也令人困惑。它说每个 S3前缀都可以支持这些请求率,从而可以轻松显着提高性能

但是由于前缀和分隔符只是GET Bucket (List Objects)列出存储桶内容时 API 的参数,所以谈论“每个前缀”的对象检索性能如何有意义。每次调用都GET Bucket (List Objects)可以选择它想要的任何前缀和分隔符,因此前缀不是预定义的实体。

例如,如果我的存储桶有这些对象:

a1/b-2
a1/c-3
Run Code Online (Sandbox Code Playgroud)

然后,每当我列出存储桶内容时,我都可以选择使用“/”或“-”作为分隔符,因此我可能会认为我的前缀是

a1/ 
Run Code Online (Sandbox Code Playgroud)

或者

a1/b-
a1/c-
Run Code Online (Sandbox Code Playgroud)

但由于GET ObjectAPI 使用整个密钥,因此对象检索不存在特定前缀或分隔符的概念。那么我可以期待 5,500 req/sec ona1/或者 5,500 req/sec ona1/b-和 5,500 ona1/c-吗?

那么有人可以解释一下当它为“每个 s3 前缀”建议特定级别的性能(例如,每秒 +5,500 次请求以检索数据)时该公告的含义吗?

Mic*_*bot 12

这里实际上被称为前缀的东西似乎是一种过度简化,实际上是指存储桶索引的每个分区。索引是词法的,因此根据对象键中的前导字符进行拆分。因此,它被称为前缀

S3 自动且透明地管理索引分区,因此此处“前缀”的精确定义实际上有些不精确:它是“S3 决定需要的任何东西来支持您的存储桶的工作负载”。S3 根据工作负载拆分索引分区,因此今天可能具有相同“前缀”的两个对象明天可能具有不同的前缀,所有这些都在后台完成。

现在, a1/a-... 和 a1/b-... 和 a1/c-... 可能都是一个前缀。但是在桶上扔足够的流量,S3 可能会决定应该拆分分区,这样明天 a1/a- 和 a1/b- 可能在一个前缀中,而 a1/c- 可能在它自己的前缀中。(也就是说,键 < a1/c- 在一个分区中,而键 >= a1/c- 现在在另一个分区中)。

没有记录何时何地以及具体是什么阈值触发拆分行为,但它似乎只与请求数量有关,而不与对象的数量或大小有关。以前,这些分区被限制为每个每秒几百个请求,并且已经显着增加。

  • 我完全相信 S3 会适应工作负载,是的。请求端高流量的官方指南和以前一样,是将 CloudFront 与 S3 结合使用,因为 CloudFront 是全局分布的,并且会将对象缓存在离请求它们的查看器最近的边缘。定价是这样的,将 CloudFront 添加到 S3 通常基本上不会对总体成本产生影响(因为当请求从 CloudFront 到达以服务缓存未命中时,S3 不会对任何带宽收费)。 (3认同)