Amazon Web Services（AWS）最近了S3请求速率得到显著性能，并能够并行化请求以扩展到所需的吞吐量。值得注意的是，这种性能提升还“移除了随机化对象前缀的任何先导”，并可以在S3对象命名中使用“逻辑或顺序命名模式，而不会对性能产生任何影响”。

Amazon Simple Storage Service（Amazon S3）是一种服务，用于“随时随地存储和检索任意数量的数据”。业界将其作为各种大型场景的存储后端，客户在向服务传输对象或从服务获取对象时往往需要非常高的吞吐量。根据S3，应用程序现在可以实现“每秒至少3,500次PUT/POST/DELETE和5,500次GET请求”，高于之前的“每秒300 PUT/LIST/DELETE或800多次GET请求“。

一个重要的方面是S3现在还自动根据“桶的前缀”提供这种吞吐量的提升，并且“前缀的数量没有限制”，这意味着应用程序可以使用并行所需的前缀来实现所需的吞吐量，并“通过计算集群的因子”有效地扩展S3性能。除此之外，这种大规模的高性能S3不再需要随机对象命名。

这一显著变化的技术细节目前还没有文档化，但之前版本的性能指南说明了常用场景面临的一些底层的挑战，如在上传大量对象时，“客户有时候会使用序号或日期和时间作为键名称的一部分”（根据的数据）：

\examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg\examplebucket/2013-26-05-15-00-00/cust3857422/photo2.jpg\examplebucket/2013-26-05-15-00-00/cust1248473/photo2.jpg\examplebucket/2013-26-05-15-00-00/cust8474937/photo2.jpg\examplebucket/2013-26-05-15-00-00/cust1248473/photo3.jpg\...\examplebucket/2013-26-05-15-00-01/cust1248473/photo4.jpg\examplebucket/2013-26-05-15-00-01/cust1248473/photo5.jpg\examplebucket/2013-26-05-15-00-01/cust1248473/photo6.jpg\examplebucket/2013-26-05-15-00-01/cust1248473/photo7.jpg\...\

使用带有顺序前缀的大量对象会引入性能问题，因为它增加了“Amazon S3将大量键定位到特定分区的可能性，从而压垮分区的I/O容量”。这个问题只能通过人工命名约定来缓解，例如添加哈希键前缀或反向嵌入ID，用以随机化键名和分区访问。

这些技术限制对于应用程序设计来说是不太友好的，并且AWS也承认这种“随机性确实会引入一些有趣的挑战”，例如，“当你想列出键名称中具有特定日期的键”。后来，S3分区机制进行了重新设计，架构师和开发人员现在可以设计和实现S3支持的应用程序，并严格使用面向用例的命名方案。

云经济学家兼“”作者Corey Quinn在他的文章中称赞了这一改进：

\

[...]将实现细节呈现给客户是历史遗留问题。你应该在不需要了解服务如何运作的情况下获得可接受的性能。我很高兴这个历史遗留问题现在被丢进了历史垃圾箱[...]

\

对于GET密集型的工作负载，AWS建议继续使用它的内容交付网络（CDN），以进一步优化延迟和传输速率，同时降低成本。

根据提供的指南，微软Azure的Blob Storage使用“基于范围的分区方案来伸缩系统和进行负载均衡”。根据“”的说明，Google Cloud Platform的Cloud Storage“通过文件的名称/路径对上传连接进行自动均衡，分配到多个后端分片[…]”。因此，两种服务都建议使用基于显式哈希前缀而不是顺序命名方案来优化大规模场景下的性能。

在相关的新闻中，Amazon S3最近宣布了基于对象标签的，以及，这两者都可以进一步提高特定用例的性能。

Amazon S3文档提供了一个，包括和。除了支持常规之外，AWS CLI还提供，以便更有效地复制、移动和同步大量对象。为此提供支持。在之外，所有客户都可以自动获得所有的改进，而无需支付额外费用。

查看英文原文：