【问题标题】：How does a random hash prefix improve S3 large-scale GET performance?随机哈希前缀如何提高 S3 大规模 GET 性能？
【发布时间】：2018-04-05 18:11:50
【问题描述】：
我将继续指出，Add a random prefix to the key names to improve S3 performance? 已在此提出并回答了这个问题——我认为这还不够。
有人能用更通俗的术语解释一下，为要大规模访问的对象添加随机哈希前缀如何有助于提高性能吗？
一个场景可能有助于说明我缺乏理解：
1000 个客户端都在尝试（具有适当的权限）对存储桶 bar 中的对象 foo 执行 GET 请求，那么使 foo --> 4jd8fb-foo 有助于减轻系统压力？客户端是否仍然希望在其 GET 请求中使用相同的对象？
我显然遗漏了一些可能很愚蠢的东西，但我真的很想弄清楚为什么这会有所帮助 - 我猜我的误解源于 S3 如何处理索引和分区，但非常感谢一些进一步的指导.
【问题讨论】：
标签：
amazon-web-services
amazon-s3
【解决方案1】：
我建议您的直觉是正确的：对象键前缀中的熵对改善对完全相同的一个对象的重复读取没有任何作用。
这不是正在考虑的那种性能（尽管如果您有这种工作负载，您应该考虑在 S3 之前使用 CloudFront，将工作负载分配给数十个边缘站点的节点，并将缓存副本保存在任何位置附近你的观众恰好是）。
随机前缀影响水平扩展潜力，通过减少索引中热点的发生率，这直接提高了潜在的写入容量 - 即可实现的对象创建和覆盖率（以每秒请求数计）。
这通过为 S3 的分区分割逻辑提供可靠的工作来提高潜在的写入容量。如果您有（例如）十六进制对象键前缀，S3 可能会在对象键的第一个八位字节上将您的存储桶分成多达 16 个不同的分区，第二个八位字节为 256，第三个八位字节为 4096……所以看起来- 简单的更改，您为服务提供了一种简单的方法，可以一次又一次地将每个分区上的工作负载减半。
如果您使用不断递增的键（尤其是时间戳）创建对象，则无法通过将一个分区拆分为两个来减少负载，因为无论何时考虑拆分，新对象始终存在将在右侧（> 分割点）新分区中，而左侧（< 分割点）将只处理很少或不创建新对象。
¹ 每秒请求数，而不是有效负载带宽，因为带宽似乎不是问题，因为 S3 显然独立于对象键（对象索引和对象）对其后备存储进行分片有效负载似乎是单独存储的，否则分区拆分在机器方面会非常昂贵，更不用说这是一项更精细的操作，因为必须将持久存储的对象移动到新的存储位置。