amazon-web-services - 随机哈希前缀如何提高 S3 大规模 GET 性能？

Question

我要继续指出这个问题已经在这里被询问和回答了 Add a random prefix to the key names to improve S3 performance? — 在我看来还不够。

谁能用更通俗的术语解释一下，向要大规模访问的对象添加随机哈希前缀如何有助于提高性能？

一个场景可能有助于说明我的理解不足:

1000 个客户端都在尝试(具有适当的权限)对存储桶 bar 中的对象 foo 执行 GET 请求，那么如何制作 foo --> 4jd8fb-foo 有助于缓解系统压力？客户不是都希望在他们的 GET 请求中使用相同的对象吗？

我显然遗漏了一些可能很愚蠢的东西，但我真的很想了解为什么这会有所帮助——我猜我的误解源于 S3 处理索引和分区的方式，但我将不胜感激一些进一步的指导.

Answer 1

我认为您的直觉是正确的:对象键前缀中的熵对改进完全相同的一个对象的重复读取没有任何作用。

这不是正在考虑的性能类型(尽管如果您有这种工作负载，您应该考虑在 S3 前面使用 CloudFront，将工作负载分配给数十个边缘位置的节点，并将缓存副本保留在任何位置附近你的观众恰好是)。

随机前缀会影响水平扩展潜力，这会通过减少索引中热点的发生率来直接提高潜在的写入容量——即可实现的对象创建和覆盖率(以每秒请求数为单位)¹。

这通过为 S3 的分区拆分逻辑提供一些可靠的东西来提高潜在的写入容量。如果您有(例如)十六进制对象键前缀，S3 可能仅在对象键的第一个八位字节上将您的存储桶分成多达 16 个不同的分区，第二个八位字节为 256 个，第三个八位字节为 4096 ... - 简单的更改，您为服务提供了一种简单的方法，可以一次又一次地将每个分区上的工作负载减半。

如果您正在创建具有不断增加的键的对象，尤其是时间戳，则无法通过将一个分区分成两个来减少一个分区上的负载，因为无论何时考虑拆分，新对象总是将位于右侧(> 拆分点)新分区，而左侧(< 拆分点)将保留很少或不处理新对象创建。

---

¹ 每秒请求数，而不是有效负载带宽，因为带宽似乎不是问题，因为 S3 显然独立于对象键(对象索引和对象)对其后备存储进行分片有效负载似乎是单独存储的，否则分区拆分在机器方面将非常昂贵，更不用说这是一个更加精细的操作，因为必须将持久存储的对象移动到新的存储位置。