Amazon web services S3-前缀到底是什么？适用的税率限制是什么？

我想知道是否有人知道s3前缀到底是什么，以及它与amazon的交互方式：

AmazonS3自动扩展到高请求率。例如 您的应用程序至少可以实现3500个PUT/POST/DELETE和5500个 获取bucket中每个前缀每秒的请求数。没有限制 一个存储桶中前缀的数目

虽然这很清楚，但我不太确定前缀是什么

前缀是否需要分隔符

如果我们有一个存储桶，将所有文件存储在“根”级别（完全平坦，没有任何前缀/删除符），那么该存储桶是否算作单个“前缀”，是否受上述速率限制的约束

我解释的方式向我表明，情况就是这样，平面结构将被视为一个“前缀”。（即以上述公布的利率限额为准）

假设您的bucket（admin创建的）有四个具有 以下对象键：

开发/项目1.xls

财务/报表1.pdf

Private/taxdocument.pdf

s3-dg.pdf

s3-dg.pdf密钥没有前缀，因此它的对象出现 直接位于铲斗的根部。如果你打开开发/ 文件夹中的Projects.xlsx对象

在上述示例中，s3-dg.pdf是否会受到与其他前缀（开发/金融/私人）不同的速率限制（5500 GET请求/秒）

---

---

更让人困惑的是，我读过几篇关于amazon使用前N个字节作为分区键的博客，并鼓励使用高基数前缀，我只是不确定它如何与具有“平面文件结构”的bucket交互。

为了让AWS每秒处理数十亿个请求，他们需要对数据进行切分，以便优化吞吐量。为此，他们根据对象键的前6到8个字符将数据分割成多个分区。请记住，S3不是一个分层文件系统，它只是一个键值存储，尽管键值通常被用作组织数据的文件路径，前缀+文件名

现在，如果您期望每秒的请求少于100个，那么这不是一个问题，但是如果您对此有严格的要求，那么您需要考虑命名

最大并行吞吐量，你应该考虑你的数据是如何被消耗的，并且使用你的密钥的最变化的字符，或者甚至为密钥的前8个字符生成8个随机字符。 e、 g.假设前6个字符定义分区：

files/user/bob

将是坏的，因为所有对象将位于一个分区

files/

2018-09-21/files/bob

如果只是今天从分区

2018-0

读取数据的话，情况几乎一样糟糕。但是如果这些对象是从过去几年中读取的，则会稍微好一些

bob/users/files

如果不同的用户可能同时使用来自分区

bob/us

的数据，那么它将非常好。但如果Bob是目前为止最忙的用户，情况就不太好了

3B6EA902/files/users/bob

对于性能而言是最佳的，但对于引用来说更具挑战性，如果第一部分是随机字符串，则分布将相当均匀

根据您的数据，您需要考虑任何一个时间点，谁在读取什么，并确保键开始时有足够的变化，以便进行适当的分区

---

对于您的示例，假设分区取自密钥的前6个字符：

对于键

Development/Projects1.xls

分区键将是

Development

对于键

Finance/statement1.pdf

分区键将是

Financ

对于密钥

Private/taxdocument.pdf

分区密钥将是

Privat

---

对于键

s3dg.pdf

分区键应该是

s3dg。

这看起来像是在amazon发布通信中被模糊地寻址

性能按前缀进行缩放，因此您可以使用任意数量的前缀 需要并行实现所需的吞吐量。没有 限制前缀的数量

S3请求速率性能的提高消除了以前的任何问题 随机对象前缀以实现更快性能的指南。 这意味着您现在可以在S3中使用逻辑或顺序命名模式 没有任何性能影响的对象命名。这一改进 现在可在所有AWS地区使用。有关更多信息，请访问 AmazonS3开发者指南

---

你说得对，这个声明似乎自相矛盾。只是写得不正确，但信息是正确的。简言之：

每个前缀每秒最多可实现3500/5500个请求，因此在许多情况下，假设不需要使用多个前缀

前缀被认为是对象位置的整个路径（直到最后一个“/”），并且不再仅由前6-8个字符进行散列。因此，只要在任意两个“文件夹”之间分割数据就足够了，以实现每秒x2个最大请求。（如果请求在两者之间平均分配）

以下是AWS支持部门对我的澄清请求的回复，仅供参考：

你好，奥伦

感谢您联系AWS支持

我知道你们读过AWS关于S3请求速率性能的帖子 正在增加，您对此还有其他问题 公告

在这次升级之前，S3支持每个用户100个PUT/LIST/DELETE请求 每秒和每秒300个GET请求。为了实现更高的绩效， 必须实现随机哈希/前缀模式。从去年开始 请求