为密钥名称添加随机前缀以提高S3性能？

Question

您希望此存储桶每秒立即收到超过150个PUT请求.公司应该做些什么来确保最佳绩效？

A)Amazon S3将自动管理此规模的性能.

B)为键名添加随机前缀.

正确的答案是B,我试图找出原因.有人可以解释B的重要性,如果它仍然是真的吗？

Answer 1

自7/17/2018 AWS公告发布以来,不再需要对S3密钥进行哈希和随机前缀来查看改进的性能:https: //aws.amazon.com/about/aws/whats-new/2018/07/amazon -S3-宣布-增加请求速率的高性能/

Answer 2

S3前缀过去由前6-8个字符确定；

\n

这种情况在 2018 年中期发生了变化 - 请参阅公告\n https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

\n

但这是半真半假的。实际上前缀（在旧定义中）仍然很重要。

\n

S3 不是传统的 \xe2\x80\x9cstorage\xe2\x80\x9d - 每个目录/文件名都是键/值对象存储中的单独对象。而且数据还必须进行分区/分片才能扩展到数十亿个对象。所以，是的，这个新的分片有点像 \xe2\x80\x9cautomatic\xe2\x80\x9d，但如果您创建了一个新进程，并以疯狂的并行方式写入不同的子目录，则事实并非如此。在 S3 从新的访问模式中学习之前，您可能会在相应地对数据进行重新分片/重新分区之前遇到 S3 限制。

\n

学习新的访问模式需要时间。数据的重新分区需要时间。

\n

2018 年中期情况确实有所改善（对于没有统计数据的新存储桶，吞吐量约为 10 倍），但如果数据正确分区，情况仍然不是这样。虽然公平地说，如果您没有大量数据，或者访问数据的模式不是高度并行的（例如，在 S3 中的许多 Tb 数据上运行 Hadoop/Spark 集群，则这可能不适用于您）数百个任务并行访问同一存储桶）。

\n

总而言之：

\n

“旧前缀”仍然很重要。\n将数据写入存储桶的根目录，那里的一级目录将确定“前缀”（例如使其随机）

\n

“新前缀”确实有效，但最初不起作用。需要时间来适应加载。

\n

附言。另一种方法 - 如果您预计很快就会有大量数据涌入新的 S3 存储桶，您可以联系您的 AWS TAM（如果有的话）并要求他们预先分区。

\n