您希望此存储桶每秒立即收到超过 150 个 PUT 请求。公司应该怎么做才能确保最佳绩效？
A) Amazon S3 将自动管理这种规模的性能。
B) 为键名添加随机前缀。
正确答案是 B，我正试图弄清楚为什么会这样。有人可以解释一下 B 的意义吗？如果它仍然是真的？
【问题讨论】：
标签： amazon-s3
自 2018 年 7 月 17 日 AWS 公告起，不再需要散列和为 S3 密钥添加随机前缀来提高性能： https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/
【讨论】：
S3 前缀过去由前 6-8 个字符确定；
这种情况在 2018 年年中发生了变化 - 请参阅公告 https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/
但那是半真半假。实际上前缀（在旧定义中）仍然很重要。
S3 不是传统的“存储”——每个目录/文件名都是键/值对象存储中的一个单独对象。并且数据必须被分区/分片以扩展到数十亿个对象。所以是的，这个新的分片有点“自动”，但如果你创建了一个新进程，它以疯狂的并行性写入不同的子目录，就不是真的了。在 S3 从新的访问模式中学习之前，您可能会在 S3 相应地重新分片/重新分区数据之前遇到 S3 限制。
学习新的访问模式需要时间。数据的重新分区需要时间。
情况在 2018 年年中确实有所改善（对于没有统计信息的新存储桶而言，吞吐量约为 10 倍），但如果数据正确分区，情况仍然不理想。虽然公平地说，如果您没有大量数据，或者您访问数据的模式不是高度并行的（例如，在 S3 中的许多 Tbs 数据上运行 Hadoop/Spark 集群，具有数百个以上的数据），这可能不适用于您并行访问同一存储桶的任务数）。
TLDR：
“旧前缀”仍然很重要。 将数据写入存储桶的根目录，一级目录将确定“前缀”（例如随机）
“新前缀”确实有效，但最初无效。适应加载需要时间。
附言。另一种方法 - 您可以联系您的 AWS TAM（如果有的话）并要求他们对新的 S3 存储桶进行预分区，如果您预计很快会有大量数据涌入它。
【讨论】：
查找/写入工作意味着使用相似或有序的文件名会损害性能。
仍然建议在 S3 密钥前添加哈希/随机 ID，以减轻频繁访问的对象的高负载。
【讨论】：
如何在 S3 中引入随机性？
使用随机十六进制哈希为文件夹名称添加前缀。例如：s3://BUCKET/23a6-FOLDERNAME/FILENAME.zip
为文件名加上时间戳。例如：s3://BUCKET/ FOLDERNAME/2013-26-05-15-00-00-FILENAME.zip
【讨论】：
B 是正确的，因为当您添加随机性（称为熵或某种无序性）时，可以将位于索引的同一分区中的所有对象彼此靠近放置。（例如，以当前年份为前缀的键）当您的应用程序遇到流量增加时，它将尝试从索引的同一部分读取，从而导致性能下降。因此，应用程序开发人员添加了一些随机前缀来避免这种情况。 注意：AWS 可能已经处理了这个问题，因此 Dev 不需要处理，只是想尝试为所提出的问题提供正确的答案。
【讨论】：
截至 2021 年 6 月。
如 AWS 指南最佳实践设计模式：优化 Amazon S3 性能中所述，应用程序可以在存储桶中每个前缀每秒至少实现 3,500 个 PUT/COPY/POST/DELETE 或 5,500 个 GET/HEAD 请求。
我认为随机前缀将有助于扩展 S3 性能。 例如，如果我们在一个 S3 存储桶中有 10 个前缀，那么它将有多达 35000 个 put/copy/post/delete 请求和 55000 个读取请求。
https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html
【讨论】：
@tagar 确实如此，尤其是如果您不在阅读密集型场景中！ 您必须了解文档的小字符才能逆向工程它在内部是如何工作的，以及您是如何受到系统的限制的。没有魔法！
503 Slow Down 错误通常在 S3 的单个分片处于热点场景时发出：对单个分片的请求过多。难以理解的是，分片是如何在内部完成的，并且不能保证所宣传的请求限制。
pre-2018 行为提供了详细信息：建议以随机字符开头的前缀的前 6-8 位数字以避免热点。
他们可以假设 S3 存储桶的初始分片是基于前缀的前 8 位数字完成的。
https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/
2018 年后：自动分片已到位，AWS 不再建议打扰前缀的前几位...但是来自此文档：
amazon-s3-performance-tips-fb76daae65cb
人们可以理解，这种自动分片重新平衡只有在对前缀的负载逐渐扩大到广告限制的情况下才能正常工作：
如果前缀的请求率逐渐增加，Amazon S3
向上扩展以处理对两个前缀中的每一个的请求。 （S3 将
向上扩展以处理 3,500 个 PUT/POST/DELETE 或 5,500 个 GET 请求
第二。）因此，存储桶处理的整体请求率
双打。
根据我的经验，503 可能会出现在广告水平之前，并且无法保证 S3 内部进行的内部重新平衡的速度。 如果您处于写入密集型场景（例如上传大量小对象），则自动缩放不会有效地重新平衡您的负载。
简而言之：如果您依赖 S3 性能，我建议您遵守 2018 年之前的规则，以便您的存储的初始分片立即生效，而不依赖于 S3 的自动重新平衡算法。
【讨论】：