在S3中创建前缀以并行读取并提高性能

Question

我正在做一些研究，我正在读这一页https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html

上面写着

Amazon S3会自动扩展到高请求率。例如，您的应用程序可以在存储桶中的每个前缀每秒至少实现3,500个PUT/POST/DELETE和5,500个GET请求。存储桶中的前缀数量没有限制。以指数方式提高您的读取或写入性能很简单。例如，如果您在Amazon S3存储桶中创建10个前缀以并行化读取，您可以将读取性能扩展到每秒55,000个读取请求。

我不知道最后一点是什么意思。我的理解是，对于文件名“Australia/NSW/Sydney”，前缀是“Australia/NSW”。对的

创建其中的10个如何提高读取性能？您是否创建了例如Australia/NSW1/、Australia/NSW2/、Australia/NSW3/，然后以某种方式将它们映射到负载均衡器？

Answer 1

不，S3永远不会连接到LB。本文涵盖了这个主题，但重要的亮点是：

(...) S3中的键按前缀进行分区

（...）

分区被拆分要么是由于持续的高请求率，要么是因为它们包含大量键（这会减慢分区内的查找速度）。将键移动到新创建的分区中会有开销，但由于请求率低且没有特殊技巧，即使在分区拆分操作期间，我们也可以保持相当高的性能。这种拆分操作在S3中每天发生数十次，从用户性能的角度来看根本没有被注意到。但是，当单个分区的请求率显着增加时，分区拆分会对请求性能不利。那么，这些较重的工作负载如何随着时间的推移发挥作用呢？对键本身进行智能命名！

因此，可以从同一分区读取澳大利亚/新南威尔士州，而可以从其他两个分区读取澳大利亚/新南威尔士州。不一定要这样，但前缀仍然允许对如何划分数据进行一些控制，因为您可以更好地了解将对数据执行何种读取。您的目标应该是使读取均匀分布在前缀上。

Answer 2

S3的设计类似于Java中的哈希表/哈希映射。前缀构成哈希桶的哈希。。。而实际的文件则分组存储在这些存储桶中。。。

要搜索特定文件，您需要比较哈希桶中的所有文件......而进入哈希桶是即时的（恒定时间）。

因此，键的描述性越强，散列桶就越多，因此这些桶中的项目就越少......这使得查找速度更快......

例如。世界上所有国家的旅游景点详细信息桶
Bucket1： placeame.jpg（桶中的所有文件没有前缀）
Bucket2： Country Name/state/place eName.jpg

现在，如果您正在澳大利亚/新南威尔士州寻找Sydney.info...在第二桶中查找会更快。