我正在从静态文件系统向亚马逊s3移动大量的jpgs（数十万）。
在旧的filesytem上，我将文件分组到子文件夹中，以保持文件/文件夹的总数可管理。
例如，文件
4aca29c7c0a76c1cbaad40b2693e6bef.jpg
将保存到：
/4a/ca/29/4aca29c7c0a76c1cbaad40b2693e6bef.jpg
据我所知，s3不尊重层次结构名称空间。因此，如果我在s3上使用“文件夹”，那么对象（包括/的s）实际上只是一个扁平的名称。
仍然，根据the docs，亚马逊建议在使用s3时模仿结构化文件系统。
所以我想知道：使用上面的文件夹结构来组织s3上的文件有什么好处吗？或者在这种情况下，我最好只将文件添加到s3，而不使用任何“文件夹”结构。
答案 0 :(得分：1)
使用（或不使用）文件夹 不受影响。
某些系统可以使用文件夹来更轻松地导航文件。例如，Amazon Athena可以在查询数据时扫描特定的子目录，而不必阅读每个文件。
如果您的存储桶用于特定目的，则没有理由使用文件夹。但是，如果它包含不同类型的数据，那么您可以考虑至少使用顶级文件夹来保持数据分离。
使用文件夹的另一个潜在原因是安全性。存储桶策略可以根据前缀（文件夹名称）授予对存储桶的访问权限。但是，这可能与您的用例无关。
答案 1 :(得分：0)
使用＆＃34;文件夹＆＃34;无论如何，对S3没有性能影响。它不会使它变得更快，并且它不会使它变慢。
使用Observable分隔对象键的价值在组织中，既适合机器使用，又适合人性化。
如果您正在通过控制台中的水桶进行拖钓，故障排除，那些无意义的充满噪音的按键很难分开，一次只有几十个。
控制台会根据/分隔符自动将对象分组到虚构文件夹中，因此如果只需单击{{{}}，就可以找到要检查它的对象（检查标题，元数据等）。 1}}然后/然后4a。
S3 ListObjects API支持请求具有特定键前缀的所有对象，但它们也支持在下一个分隔符之前查找所有公共前缀，因此您可以使用分隔符{{}向列表前缀ca发送API请求。 1}}它将仅返回＆＃34;文件夹＆＃34;一级深，它称为＆＃34;公共前缀。＆＃34;
如果您的对象键完全不透明并且不再传达有关对象的信息，那么这不太有意义，而不是使用29和4a/ca/以及/等关键字符。
作为管理员并使用S3工作了很多年，并且使用了由不同团队设计的关键命名方案的存储桶，我肯定会建议使用一些images/分隔符来进行组织。没有它们的水桶随着时间的推移变得更加麻烦。
请注意，控制台确实允许您创建文件夹，＆＃34;但这更多的是幻觉 - 除非你手动装载水桶，否则没有必要真正做到这一点。在控制台中创建文件夹时，它只会在末尾创建一个带有thumbnails/的空对象。