您想要什么时候使s3对象键类似？

Question

因此，S3在对数据进行分区时使用对象键，并且您应该使您的密钥具有一定的随机性，以便在多个分区之间分配工作负载。我的问题是，在哪些情况下，您希望拥有类似的密钥？如果不是，那么为什么AWS要使用键来划分数据而不是随机地分割数据本身呢？

我之所以这样问，是因为我认为这是一种奇怪的设计，因为如果开发人员生成具有模式的键，那么他们很容易在分区中出错，但它也会阻止开发人员以逻辑的方式创建密钥，因为这无疑会导致模式和数据被错误地划分。

Answer 1

您似乎指的是请求速率和性能考虑- Amazon简单存储服务，它指出：

本主题中的Amazon最佳实践指南仅适用于常规每秒处理100个或更多请求的情况。如果您的典型工作负载只涉及每秒100个请求的偶尔突发，而少于每秒800个请求，则不需要遵循这些指导原则。

这不太可能影响大多数应用程序，但如果应用程序具有如此高的通信量，那么在键名空间传播请求可以提高性能。

AWS没有解释为什么他们会以这种方式设计亚马逊S3。

Answer 2

因此，S3使用对象键对数据进行分区。

等。你的问题似乎以这个假设为前提，但它是不正确的。

S3不使用对象键对数据进行分区。正如你所建议的那样，这确实是一个非常“奇怪的设计”(或者更糟)。

S3使用对象键来划分桶中对象的索引 --否则对象索引将按不支持按排序顺序枚举对象键的顺序存储，这也将消除按前缀列出对象或使用分隔符标识常见前缀的能力--或者需要一个辅助索引，它只会使潜在的缩放问题更加复杂，并将同样的问题移到一个级别上。

当您想在需要时找到具有公共前缀(在同一个“文件夹”中)的对象时，需要使用类似的键。存储日志文件是一个简单的例子，yyyy/mm/dd/...。注意，当各种服务为您在桶中存储日志文件(S3日志、CloudFront、ELB)时，对象键按如下顺序排列，因为日期和时间在对象键中。

当S3执行分区拆分时，只有索引被拆分。数据已经被持久地存储，并且不会移动。潜在的性能考虑因素与索引的性能有关，而不是对象数据的实际存储性能。