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

您希望这个bucket每秒立即接收超过150个PUT请求。公司应该如何确保最佳绩效

A） AmazonS3将自动管理这种规模的性能

B） 向键名称添加随机前缀

---

正确答案是B，我正试图弄清楚为什么是B。有人能解释一下B的意义吗？如果它仍然是真的？

查找/写入工作意味着使用相似或有序的文件名可能会损害性能

仍然建议在S3键之前添加哈希/随机ID，以减轻大量访问对象的高负载

---

自2018年7月17日AWS发布以来，不再需要对S3密钥进行散列和随机前缀，以提高性能：

---

如何将随机性引入S3

使用随机十六进制哈希作为文件夹名称的前缀。例如：

s3://BUCKET/23a6 FOLDERNAME/FILENAME.zip

在文件名前面加上时间戳。例如：

s3://BUCKET/FOLDERNAME/2013-26-05-15-00-00-FILENAME.zip

---

B是正确的，因为当您添加随机性（称为熵或某种无序性）时，可以将位于索引中同一分区中的所有对象彼此靠近。（例如，前缀为当前年份的键）当您的应用程序遇到流量增加时，它将尝试从索引的同一部分读取，导致性能下降。因此，应用程序开发人员添加一些随机前缀以避免这种情况。

---

注意：AWS可能已经注意到了这一点，因此开发人员不需要注意，只想尝试给出问题的正确答案。

S3前缀通常由前6-8个字符决定

这一点在2018年年中有所改变——见公告

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

S3不是传统的“存储”——每个目录/文件名都是键/值对象存储中的一个单独对象。此外，数据还必须进行分区/分片，以缩放到无数个对象。是的，这种新的分片有点“自动”，但如果你创建了一个新的进程，它以疯狂的并行方式写入到不同的子目录中，它就不是真正的自动分片了。在S3从新的访问模式中学习之前，您可能会在S3相应地重新硬存储/重新分区数据之前遇到S3限制

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

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

TLDR：

“旧前缀”仍然很重要。 将数据写入bucket的根目录，其中的第一级目录将确定“前缀”（例如，将其设置为随机）

“新前缀”确实起作用，但一开始不起作用。适应负载需要时间

另一种方法-如果您预计大量数据将很快涌入新的S3存储桶，您可以联系您的AWS TAM（如果您有）并要求他们对其进行预分区。

从2021年6月开始

正如AWS指南《最佳实践设计模式：优化AmazonS3性能》中提到的，应用程序在一个bucket中每个前缀每秒至少可以实现3500个PUT/COPY/POST/DELETE或5500个GET/HEAD请求

我认为随机前缀将有助于扩展S3性能。 例如，如果我们在一个S3存储桶中有10个前缀，那么它将有多达35000个put/copy/post/delete请求和55000个read请求

---

事实上，随机前缀阈值来自第二个链接：如果您在Amazon S3存储桶中的工作负载通常超过每秒100个PUT/LIST/DELETE请求……原因是：S3使用索引立即定位存储桶。索引使用树。分支用于对相似的值进行分组。分支已满时，必须创建分支，并将值移动到分支。创建分支时，必须锁定父分支。如果您开始敲打同一个分支，它可能会创建无法及时解决以赶上的积压工作，并且索引在赶上之前无法找到值。因此，当达到阈值时，系统通常会开始拒绝请求。是否有任何文档说明将“一级目录”用作“前缀”，即2018年每“前缀”概念的新费率？或者“S3前缀通常由前6-8个字符决定”，值得一提的是，如果您的存储桶使用KMS加密，那么在这些大数字下，KMS可以解密的请求数量将开始达到限制。（某些地区每秒最多5500个请求）感谢您提到一个AWS地区的加密限制。aws文件对此进行了一些更新：美国东部（北弗吉尼亚州）、美国西部（俄勒冈州）和欧盟（爱尔兰）地区：每秒10000。在KMS可用的所有其他地区，限制增加到每秒5500个请求。