我想知道是否有人知道s3前缀到底是什么以及它如何与亚马逊published s3 rate limits相互作用：
Amazon S3自动扩展到高请求率。例如， 您的应用程序至少可以实现3500个PUT / POST / DELETE和5500个 桶中每个前缀每秒获取GET请求的数量。没有限制 存储桶中的前缀数。
虽然很清楚，我不确定前缀是什么？
前缀是否需要定界符？
如果我们有一个存储桶，可以将所有文件存储在“根”级别（完全平坦，没有任何前缀/斜线），那么这是否算作一个“前缀”，并且受上面发布的速率限制的约束吗？
我解释amazon's documentation的方式向我暗示情况就是如此，并且扁平结构将被视为单个“前缀”。 （即受上面公布的费率限制）
假设您的存储桶（由管理员创建）具有四个对象， 以下对象键：
Development / Projects1.xls
财务/声明1.pdf
私人/taxdocument.pdf
s3-dg.pdf
s3-dg.pdf键没有前缀，因此其对象出现 直接在存储桶的根级。如果您打开开发/ 文件夹，您会在其中看到Projects.xlsx对象。
更令人困惑的是，我读过一些关于亚马逊的博客，这些博客使用前N个字节作为分区键，并鼓励使用高基数前缀，但我不确定它如何与带有“平文件结构”。
答案 0 :(得分：5)
为了使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.
答案 1 :(得分：4)
在亚马逊发布通讯中似乎无法解决
性能按前缀扩展，因此您可以使用尽可能多的前缀 需要并行实现所需的吞吐量。没有 限制前缀数量。
此S3请求率性能提高消除了以前的任何情况 随机分配对象前缀以实现更快性能的指南。 这意味着您现在可以在S3中使用逻辑或顺序命名模式 对象命名，对性能没有任何影响。这项改善 现在在所有AWS区域中都可用。有关更多信息，请访问 Amazon S3开发人员指南。
答案 2 :(得分：4)
在此问题上被否决的答案对我来说有点误导。 如果这些是路径
存储桶/文件夹1 /子1 /文件
桶/文件夹1 /子2 /文件
桶/ 1 /文件
bucket / 2 /文件
您文件的前缀实际上是
folder1 / sub1 /
文件夹1 /子2 /
1 /文件
2 /文件
https://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysHierarchy.html 请检查文档。尝试使用气流s3hook列出键时，前导'/'出现问题。
答案 3 :(得分：4)
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存储桶。
答案 4 :(得分：2)
您是对的，该声明似乎与自己矛盾。只是写的不正确，但是信息是正确的。简而言之：
作为参考，以下是AWS支持人员对我的澄清请求的答复：
你好奥伦，
感谢您联系AWS支持。
我了解您阅读了有关S3请求率性能的AWS帖子 增加，您对此还有其他疑问 公告。
在此升级之前，S3每秒钟支持100个PUT / LIST / DELETE请求 秒和每秒300个GET请求。为了获得更高的性能， 必须实现随机哈希/前缀模式。从去年开始 请求速率限制增加到3500 PUT / POST / DELETE和5500 每秒GET请求。这种增加通常足以 减少503 SlowDown错误的应用程序，而不必 随机化前缀。
但是，如果新限制还不够，则需要使用前缀 使用。前缀没有固定数量的字符。它是任何字符串 存储桶名称和对象名称之间的值，例如：
存储桶/文件夹1 /子1 /文件存储桶/文件夹1 /子2 /文件存储桶/ 1 /文件 bucket / 2 /文件
对象'file'的前缀为：'/ folder1 / sub1 /'， '/ folder1 / sub2 /'，'/ 1 /'，'/ 2 /'。在此示例中，如果您分散阅读 均匀地分布在所有四个前缀中，每个可以实现22,000个请求 第二。
答案 5 :(得分：0)
如果您使用Athena，EMR / Hive或Redshift Spectrum查询S3，则增加前缀数量可能意味着添加更多分区（因为分区ID是前缀的一部分）。如果将日期时间用作您的分区密钥之一，则分区（和前缀）的数目将随着新数据的添加而自动增长，并且每秒最大S3 GET总数也将增长。