S3 - 究竟什么是前缀？什么速率限制适用？答案

【问题标题】：S3 - What Exactly Is A Prefix? And what Ratelimits apply?S3 - 究竟什么是前缀？什么速率限制适用？
【发布时间】：2019-02-25 20:53:07
【问题描述】：

我想知道是否有人知道 s3 前缀到底是什么以及它如何与亚马逊的 published s3 rate limits 交互：

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

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

前缀是否需要分隔符？

如果我们有一个存储桶，我们将所有文件存储在“根”级别（完全平坦，没有任何前缀/分隔符），这是否算作单个“前缀”，是否受上面发布的速率限制？

我解释amazon's documentation 的方式向我表明情况就是这样，扁平结构将被视为单个“前缀”。（即受上述公布的速率限制）

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

开发/Projects1.xls

财务/statement1.pdf

私人/taxdocument.pdf

s3-dg.pdf

s3-dg.pdf 键没有前缀，所以出现了它的对象直接在存储桶的根级别。如果您打开开发/ 文件夹，您会在其中看到 Projects.xlsx 对象。

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

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

【问题讨论】：

对于键 s3-dg.pdf，分区键将是 s3-dg.，请参阅下面的扩展答案。
为了增加混淆，请考虑来自 documentation 的以下语句：“Amazon S3 自动扩展以响应持续的新请求率，动态优化性能。而 Amazon S3 在内部针对新的请求率，您将暂时收到 HTTP 503 请求响应，直到优化完成。在 Amazon S3 内部针对新的请求率优化性能后，所有请求通常都会得到处理而无需重试。”

标签： amazon-web-services amazon-s3

【解决方案1】：

S3 前缀过去由前 6-8 个字符确定；

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

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

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

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

情况在 2018 年年中确实有所改善（对于没有统计信息的新存储桶而言，吞吐量约为 10 倍），但如果数据正确分区，情况仍然不理想。虽然公平地说，如果您没有大量数据，或者您访问数据的模式不是高度并行的（例如，在 S3 中的许多 Tbs 数据上运行一个 Hadoop/Spark 集群，具有数百个以上的数据），这可能不适用于您并行访问同一存储桶的任务数）。

TLDR：

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

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

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

【讨论】：

关于旧前缀的相关信息从何而来？经验？只是为了理解。我在“新”更改、限制请求方面遇到问题，但在重构所有系统之前我需要更多信息。
@MicheleGargiulo，有与客户合作的经验。

【解决方案2】：

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

bucket/folder1/sub1/file
桶/文件夹1/sub2/文件
桶/1/文件
桶/2/文件

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

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

【讨论】：

我认为您示例中的最后两条路径不应以 /file 结尾。

【解决方案3】：

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

【讨论】：

【解决方案4】：

你说得对，公告似乎自相矛盾。只是写得不对，但信息是正确的。简而言之：

每个前缀每秒最多可以实现 3,500/5,500 个请求，因此对于许多用途，假设是您不需要使用多个前缀。
前缀被认为是对象位置的整个路径（直到最后一个“/”），不再仅按前 6-8 个字符进行散列。因此，只需在任意两个“文件夹”之间拆分数据以实现每秒 x2 的最大请求数就足够了。（如果请求在两者之间平均分配）

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

你好奥伦，

感谢您联系 AWS Support。

我了解到您阅读了有关 S3 请求率性能的 AWS 帖子正在增加，您对此还有其他问题公告。

在此升级之前，S3 支持每人 100 个 PUT/LIST/DELETE 请求秒和每秒 300 个 GET 请求。为了获得更高的性能，必须实施随机散列/前缀模式。从去年开始请求速率限制增加到 3,500 PUT/POST/DELETE 和 5,500 每秒获取请求数。这种增加通常足以应用程序来缓解 503 SlowDown 错误，而无需随机化前缀。

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

bucket/folder1/sub1/file

bucket/folder1/sub2/file

bucket/1/file

bucket/2/file

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

【讨论】：

谁能提供一个完整的代码sn-p，利用前缀在单个桶上可靠地实现超过3500个PUT/POST/DELETE和超过5500个GET请求？我已经尝试了很长时间，但没有成功。
对于 SES S3 操作，“对象键前缀”不需要有前导斜杠：folder1/sub1/
这似乎与the presenter for STG343 相矛盾，the presenter for STG343 说斜杠被视为任何其他字符并且分区是自动的。
与official AWS documentation 矛盾。
@Chris 我很乐意用新信息更新答案，但该链接听起来与其他关于该主题的 AWS 通信一样模糊（如果不是更糟的话）。 - “文件夹结构可能不一定表明什么是支持请求率的分区前缀”。我逐字发布的支持答案与我得到的可靠回应一样接近。

【解决方案5】：

这看起来像是在亚马逊发布通讯中模糊地解决了

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

每个前缀的性能缩放，因此您可以使用尽可能多的前缀需要并行实现所需的吞吐量。没有前缀数量的限制。

此 S3 请求率性能提升消除了之前的任何指导随机化对象前缀以实现更快的性能。这意味着您现在可以在 S3 中使用逻辑或顺序命名模式对象命名没有任何性能影响。这种改进现已在所有 AWS 区域推出。欲了解更多信息，请访问 Amazon S3 开发人员指南。

【讨论】：

这只会引发更多问题！哈哈。这些说法似乎相反。该报价似乎是说限制取决于前缀，但前缀不再重要......？但限制仍然适用于前缀。但前缀不再重要（猜测它们在内部散列以获得真正的分区？）。：困惑：
@CoryMawhorter 如果您了解（或确实）了这一点，请告诉我们。我也会这样做。
@Lo-Tan 可以。我只是要自己玩鸵鸟，并假设它确实是无限的，至少就我的目的/吞吐量而言。
我认为通过前缀，您现在应该只阅读“文件夹”，即使文件夹在技术上不是存储桶中的东西。我认为关于随机化的注释是因为之前前缀基于存储桶键的前 8 个字符，而现在它们基于完整的“文件夹”路径。

【解决方案6】：

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

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

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

例如假设前 6 个字符定义了分区：

files/user/bob 将是 bad，因为所有对象都将位于一个分区 files/。

如果仅从分区 2018-0 读取今天的数据，

2018-09-21/files/bob 将几乎一样糟糕。但是稍微好一点如果这些对象是从过去几年中读取的。

如果不同的用户可能同时使用分区 bob/us 中的数据，

bob/users/files 会相当不错。但如果 Bob 是迄今为止最忙的用户，那就不是很好了。

3B6EA902/files/users/bob 对于性能来说是最佳，但参考起来更具挑战性，因为第一部分是随机字符串，这将是相当均匀的分布。

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

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

对于键 Development/Projects1.xls，分区键将是 Develo

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

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

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

【讨论】：

前缀实际上只是文件名之前的密钥位。实际上，它是用于形成分区结构的整个密钥。
3,500 PUT/POST/DELETE and 5,500 GET requests per second per prefix 指的是分区。您不确定为您的数据创建了多少个分区，但通过充分改变前几个字符，您可以获得最大的请求吞吐量。
本指南已过时。现在是否放置随机前缀都没有关系，因为 S3 现在将在内部对其进行哈希处理：aws.amazon.com/about-aws/whats-new/2018/07/…“此 S3 请求速率性能提升消除了任何先前用于随机化对象前缀以实现更快性能的指导。这意味着您现在可以使用S3 对象命名中的逻辑或顺序命名模式，没有任何性能影响。"
我们不确定该公告的含义，它是矛盾的......“性能按前缀扩展，因此您可以并行使用尽可能多的前缀来实现所需的吞吐量。”和“此 S3 请求率性能提升消除了之前的任何指导，以随机化对象前缀以实现更快的性能。”。那么如何添加更多前缀呢？寻找实践经验。
据我了解，这意味着完整路径（没有文件名）是“前缀”，所以我们应该尽量不要使用相同的前缀：/bob/users - 而是 /bob/users/ 21rlkfjrijRandom/file.jpg