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

Question

我将继续指出这个问题已在此处提出并回答：向密钥名称添加随机前缀以提高 S3 性能？我认为 \xe2\x80\x94 还不够。

\n\n

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

\n\n

一个场景可能有助于说明我的缺乏理解：

\n\n

foo1000 个客户端都在尝试（具有适当的权限）对存储桶中的对象执行 GET 请求，那么-->bar如何帮助减轻系统压力？客户端是否仍然希望在 GET 请求中使用相同的对象？foo4jd8fb-foo

\n\n

我显然错过了一些可能很愚蠢的东西，但我真的很想弄清楚为什么这会有所帮助\xe2\x80\x94 我猜我的误解源于S3如何处理索引和分区但我们将不胜感激一些进一步的指导。

\n

Answer 1

我建议您的直觉是正确的：对象键前缀中的熵不会做任何事情来改善对完全相同的一个对象的重复读取。

这不是我们所考虑的性能类型（尽管如果您有这种工作负载，您应该考虑在 S3 之前使用 CloudFront，在数十个边缘位置的节点之间分配工作负载，并在观看者出现的任何地方保留缓存副本成为）。

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

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

If you are creating objects with ever-incrementing keys, particularly timestamps, there isn't anything that can be done to reduce the load on one partition by splitting it into two, because wherever a split is contemplated, new objects are always going to be in the right-side (> split point) new partition, while the left-side (< split point) would be left handling little or no new object creation.

¹ in requests per second, not payload bandwidth, as bandwidth doesn't seem to be a concern, because S3 apparently shards its backing store independently of object keys -- the object index and the object payload appear to be stored separately, otherwise partition splits would be extremely expensive in machine terms, not to mention being a much more delicate operation, since durably-stored objects would have to be moved to new storage locations.