【问题标题】：Creating prefixes in S3 to paralellise reads and increase performance在 S3 中创建前缀以并行读取并提高性能
【发布时间】：2018-11-22 12:04:56
【问题描述】：
我正在做一些研究，我正在阅读此页面
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/，然后以某种方式将它们映射到负载均衡器？
【问题讨论】：
标签：
amazon-web-services
amazon-s3
【解决方案1】：
S3 的设计类似于 Java 中的 Hashtable/HashMap。前缀形成哈希桶的哈希......并且实际文件存储在这些桶中的组中......
要搜索特定文件，您需要比较哈希桶中的所有文件...而获取哈希桶是即时的（恒定时间）。
因此，键的描述性越强，哈希桶就越多，因此这些桶中的项目就越少......这使得查找速度更快......
例如 一个包含世界上所有国家/地区的旅游景点详细信息的桶
Bucket1：placeName.jpg（桶中所有文件无前缀）
Bucket2: countryName/state/placeName.jpg
现在，如果您正在澳大利亚/新南威尔士州寻找 Sydney.info...在第二个桶中查找会更快。
【解决方案2】：
不，S3 永远不会连接到 LB。 This article 涵盖了这个主题，但重要的亮点：
(...) S3 中的键按前缀分区
(...)
分区被拆分的原因可能是持续的高请求率，或者是因为它们包含大量键（这会减慢分区内的查找速度）。将键移动到新创建的分区有开销，但由于请求率低且没有特殊技巧，即使在分区拆分操作期间，我们也可以保持相当高的性能。这种拆分操作每天在整个 S3 上发生数十次，并且从用户性能的角度来看根本不会被注意到。但是，当单个分区上的请求率显着增加时，分区拆分对请求性能不利。那么，随着时间的推移，这些较重的工作负载是如何工作的呢？键本身的智能命名！
所以Australia/NSW/ 可以从同一个分区读取，而Australia/NSW1/ 和Australia/NSW2/ 可以从另外两个分区读取。不一定要那样，但前缀仍然允许对如何分区数据进行一些控制，因为您可以更好地了解您将对它进行什么样的读取。您的目标应该是使读取均匀分布在前缀上。