S3-前缀到底是什么？什么速率限制适用？

Question 1

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

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

虽然这很明显，但我不确定前缀是什么？

前缀是否需要定界符？

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

我解释亚马逊文档的方式向我暗示了这种情况，并且扁平结构将被视为单个“前缀”。（即受上面公布的费率限制）

假设您的存储桶（由管理员创建）具有四个带有以下对象键的对象：

开发/项目1.xls

财务/声明1.pdf

私人/taxdocument.pdf

s3-dg.pdf

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

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

更令人困惑的是，我读过一些有关使用前N个字节作为分区键的亚马逊博客，并鼓励使用高基数前缀，但我不确定该如何与具有“平面文件结构”的存储桶进行交互。

Question 2

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

每个前缀每秒最多可以实现3,500 / 5,500个请求，因此出于许多目的，假设您不需要使用多个前缀。
前缀被视为对象位置的整个路径（直到最后一个“ /”），并且不再仅由前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个请求。

Question 3

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

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

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

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

Question 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.

Question 5

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

bucket / folder1 / sub1 / file
bucket / folder1 / sub2 / file
bucket / 1 / file
bucket / 2 / file

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

https://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysHierarchy.html 请参阅文档。尝试使用气流s3hook列出键时，前导'/'出现问题。

Question 6

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中的大量Tb数据上运行Hadoop / Spark集群，并且有数百个以上的数据），则可能不适用于您并行访问同一存储桶的任务）。

TLDR：

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

“新前缀”确实有效，但最初并不起作用。加载需要花费时间。

PS。另一种方法-如果您希望大量数据即将泛滥，可以联系AWS TAM（如果有），并要求他们预先分区一个新的S3存储桶。

Question 7

如果您使用Athena，EMR / Hive或Redshift Spectrum查询S3，则增加前缀数量可能意味着添加更多分区（因为分区ID是前缀的一部分）。如果将日期时间用作您的分区密钥之一，则分区（和前缀）的数目将随着新数据的添加而自动增长，并且每秒最大S3 GET总数也将增长。