S3 - 前缀究竟是什么？什么Ratelimits适用？

Question

我想知道是否有人知道s3前缀是什么以及它如何与亚马逊发布的s3速率限制相互作用:

Amazon S3会自动扩展到高请求率.例如,您的应用程序可以在一个存储桶中实现每个前缀每秒至少3,500个PUT/POST/DELETE和5,500个GET请求.存储桶中的前缀数量没有限制.

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

前缀是否需要分隔符？

如果我们有一个存储桶,我们将所有文件存储在"根"级别(完全平坦,没有任何前缀/分隔符),这是否算作单个"前缀"并且是否受上面公布的速率限制的约束？

我正在解释亚马逊的文档的方式告诉我,情况就是这样,并且扁平结构将被视为单个"前缀".(即它将受上述公布的费率限制)

假设您的存储桶(admin-created)有四个对象,其中包含以下对象键:

开发/ Projects1.xls

财务/ statement1.pdf

私人/ taxdocument.pdf

S3-dg.pdf

s3-dg.pdf密钥没有前缀,因此其对象直接显示在存储桶的根级别.如果打开Development /文件夹,则会在其中看到Projects.xlsx对象.

在上面的例子中,s3-dg.pdf是否会受到与其他每个前缀(开发/财务/私人)不同的5500 GET请求/秒速率限制？

更令人困惑的是,我已经阅读了几篇关于亚马逊的博客,使用前N个字节作为分区键并鼓励使用高基数前缀,我只是不确定它是如何与具有"平面文件结构"的桶交互的.

Answer 1

没错，该公告似乎与自己矛盾。只是写的不正确，但是信息是正确的。简而言之：

1. 每个前缀每秒最多可以实现3,500 / 5,500个请求，因此出于许多目的，假设您不需要使用多个前缀。
2. 前缀被视为对象位置的整个路径（直到最后一个“ /”），并且不再仅由前6-8个字符进行哈希处理。因此，仅在任何两个“文件夹”之间拆分数据就足以实现每秒最多x2个请求。（如果请求在两者之间平均分配）

作为参考，以下是AWS支持人员对我的澄清请求的回复：

你好奥伦，

感谢您联系AWS支持。

我了解您阅读了有关提高S3请求率性能的AWS帖子，并且对本公告还有其他疑问。

在此升级之前，S3支持每秒100个PUT / LIST / DELETE请求和每秒300个GET请求。为了获得更高的性能，必须实现随机哈希/前缀架构。从去年开始，请求速率限制增加到每秒3500个PUT / POST / DELETE和5500个GET请求。这种增加通常足以使应用程序减轻503 SlowDown错误，而不必随机化前缀。

但是，如果新的限制还不够，则需要使用前缀。前缀没有固定数量的字符。它是存储区名称和对象名称之间的任何字符串，例如：

• 桶/文件夹1 /子1 /文件
• 桶/文件夹1 /子2 /文件
• 桶/ 1 /文件
• 桶/ 2 /文件

对象“文件”的前缀是： /folder1/sub1/， /folder1/sub2/，/1/，/2/。在此示例中，如果将读取平均分布在所有四个前缀中，则每秒可以实现22,000个请求。

Answer 2

亚马逊发布通讯中似乎模糊地解决了这个问题

https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

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

S3请求速率性能的提高消除了任何先前的指南，即可以随机化对象前缀以实现更快的性能。这意味着您现在可以在S3对象命名中使用逻辑或顺序命名模式，而不会影响性能。现在，所有AWS区域都可以使用此改进。有关更多信息，请访问Amazon S3开发人员指南。

Answer 3

S3前缀过去是由前6-8个字符决定的；

这在 2018 年年中发生了变化 - 请参阅公告 https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

但那是半真半假。实际上前缀（在旧定义中）仍然很重要。

S3 不是传统的“存储”——每个目录/文件名都是键/值对象存储中的一个单独对象。而且数据必须被分区/分片以扩展到数以亿计的对象。所以是的，这个新的分片有点“自动”，但如果你创建了一个新进程，它以疯狂的并行性向不同的子目录写入它，就不是真的。在 S3 从新的访问模式中学习之前，您可能会遇到 S3 节流，然后才会相应地重新分片/重新分区数据。

学习新的访问模式需要时间。数据的重新分区需要时间。

事情在 2018 年年中确实有所改善（对于没有统计数据的新存储桶，吞吐量约为 10 倍），但如果数据分区正确，情况仍然不是这样。尽管公平地说，如果您没有大量数据，或者您访问数据的模式不是非常并行（例如，在 S3 中的许多 Tbs 数据上运行 Hadoop/Spark 集群，其中数百+并行访问同一存储桶的任务）。

TLDR :

“旧前缀”仍然很重要。将数据写入存储桶的根目录，那里的一级目录将确定“前缀”（例如使其随机）

“新前缀”确实有效，但最初无效。需要时间来适应加载。

附注。另一种方法 - 如果您预计很快就会有大量数据涌入，您可以联系您的 AWS TAM（如果您有的话）并要求他们对新的 S3 存储桶进行预分区。

Answer 4

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

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

为了获得最大的并行吞吐量，您应该考虑如何使用数据，并在密钥的开头使用变化最大的字符，甚至对于密钥的前8个字符生成8个随机字符。

例如，假设前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，分区键将是Develo

对于键Finance/statement1.pdf，分区键将是Financ

对于键Private/taxdocument.pdf，分区键将是Privat

对于键s3-dg.pdf，分区键将是s3-dg.

Answer 5

对此的赞成答案对我来说有点误导。如果这些是路径

存储桶/文件夹1/子1/文件
存储桶/文件夹1/子2/文件
存储桶/1/文件
存储桶/2/文件

您的文件前缀实际上是
folder1/sub1/
folder1/sub2/
1/file
2/file

https://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysHierarchy.html 请参阅文档。当我尝试使用气流 s3hook 列出键时，我遇到了前导“/”的问题。