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

我要继续，并指出，这已经被问到，并在这里回答-在我看来不够充分

有人能用更通俗的术语确切地解释一下，向要按比例访问的对象添加随机哈希前缀如何有助于提高性能

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

1000个客户端都在尝试（使用适当的权限）对bucket

bar

中的对象

foo

执行GET请求，那么让

foo

-->

4jd8fb foo

如何帮助减轻系统压力呢？客户机在GET请求中是否仍然需要相同的对象

---

我显然错过了一些可能很愚蠢的事情，但我真的很想了解一下为什么这会有帮助——我想我的误解源于S3如何处理索引和分区，但如果能提供一些进一步的指导，我将不胜感激。

我认为你的直觉是正确的：对象键前缀中的熵对提高重复读取的准确率没有任何作用同一个物体

这不是正在考虑的性能（尽管如果你有这样的工作量，你应该考虑在S3前面使用CyrdFrand，在几十个边缘位置中的节点之间分配工作负载，并在你的观察者所处的任何地方保存缓存副本）。 随机前缀会影响水平扩展潜力，这会通过减少索引中热点的发生率，直接提高潜在的写入容量，即可实现的对象创建和覆盖率（以每秒请求数为单位）

这为S3的分区分割逻辑提供了可靠的处理工具，从而提高了潜在的写容量。如果您有（例如）十六进制对象键前缀，S3可能会在对象键的第一个八位组上将您的bucket拆分为最多16个不同的分区，第二个八位组为256个，第三个八位组为4096个。。。因此，通过这个看似简单的更改，您可以为服务提供一种简单的方法，一次又一次地将每个分区上的工作负载减半

---

如果您正在创建具有不断递增的键（尤其是时间戳）的对象，则无法通过将一个分区拆分为两个来减少一个分区上的负载，因为在考虑拆分的地方，新对象总是位于新分区的右侧（

拆分点），而左侧位于新分区（

唯一的官方文档是：自2018年6月17日起，不再要求S3对象名称中有随机前缀以提高性能。