S3中每个目录的最大文件数
如果我有一百万的图像，最好将它们存储在某个文件夹/子文件夹层次结构中，或者将它们全部直接转储到一个存储桶中（没有任何文件夹）？
将所有的图像倾倒到一个层次较less的桶减慢列表操作？
在dynamic创build文件夹和子文件夹并设置其ACL（以编程方式）时是否存在很大的开销？
S3不尊重层次结构的命名空间。 每个桶只包含许多从键到对象的映射（以及相关的元数据，ACL等）。
即使您的对象的键可能包含“/”，S3会将该path视为纯string，并将所有对象放在一个平面名称空间中。
根据我的经验，随着对象数量的增加，LIST操作的时间会更长（线性），但这可能是Amazon服务器上所需的I / O增加的症状，并且可能会导致客户端的连接断开。
然而，查找时间似乎并没有随着对象数量的增加而增加 – 它们最可能是某种O（1）哈希表的实现 – 所以同一个桶中的许多对象应该和正常使用的小桶一样不是LISTs）。
至于ACL，可以在桶和每个单独的对象上设置授权。 由于没有层次结构，他们是你唯一的两个select。 显然，如果你拥有数百万个文件，那么设置尽可能多的全额授权将大大减lesspipe理员的头痛问题，但是要记住，你只能授予权限，不能撤销它们，所以整个桶的授权应该是所有ACL的最大子集其内容。
我build议分成以下单独的桶：
- 完全不同的内容 – 具有独立的图像，声音和其他数据桶使得更健全的架构
- 明显不同的ACL – 如果可以有一个存储桶，每个对象接收特定的ACL，或者两个存储桶使用不同的ACL并且没有对象特定的ACL，则可以使用两个存储桶。
回答原来的问题：“S3中每个目录的最大文件数”是：UNLIMITED。 另请参阅S3限制存储桶中的对象 。
我没有数据，但我的猜测是，水桶将有所帮助。
按顺序search列表是O（n）。 如果水桶可以帮助减less你必须search的文件的数量，我看不出他们如何受到伤害。 开销似乎是一个小的代价。
我用一个根目录结构，然后至less有一个子目录。 我经常使用“文档导入date”作为根目录下的目录。 这可以使pipe理备份更容易一些。 无论你使用的是什么文件系统，你最终都会达到文件数量限制（即使不是物理限制）。 你也可以考虑支持多个根。
