Amazon AWS S3 Glacier是否支持在Vault for Archives中某种程度上的文件层次结构？
例如，在AWS S3中，对象通过/进行层次结构分配。例如：all_logs/some_sub_category/log.txt
我正在存储多个.tar.gz文件，并希望：
我在任何地方都找不到如何做的记录。如果可以在S3 Glacier内部进行文件分层，您能否提供有关这样做的简要说明？
Amazon AWS S3 Glacier是否支持在Vault for Archives中某种程度上的文件层次结构？
不，除了“库中存在档案”之外，没有其他层次。
例如，在AWS S3中，通过/为对象指定层次结构。例如：all_logs / some_sub_category / log.txt
这实际上是不正确的。
S3没有任何固有的层次结构。字符/绝对与对S3对象的键有效的任何其他字符相同。
S3控制台-和大多数S3客户端工具，包括AWS的CLI-以特殊方式对待/字符。但是请注意，这是客户端的事情。客户将确保列表以[/表现正如大多数人期望的那样]的方式发生，即作为“层次分隔符”。
如果可以在S3 Glacier内部建立文件层次结构，那么您能否提供有关这样做的简要说明？
您需要分别跟踪层次结构。例如，当您将档案存储在Glacier中时，可以在数据库（RDS，DynamoDB等）中写入有关该档案的元数据。
[作为旁注，请注意Glacier中的.tar.gz，尤其是当您在谈论（1）很大的档案库（2），它由大量小的单个文件（3）组成时，希望单独访问。
如果满足这些条件（以我的经验，它们通常是在现实世界中的场景，那么使用.tar.gz通常会在检索数据时导致过多的成本。
原因是因为您按请求数和请求大小付费。因此，尽管拥有一个巨大的.tar.gz文件可能会减少请求数量的成本，但gzip使用DEFLATE（这是一种不可拆分的压缩算法）这一事实意味着您必须检索整个.tar.gz存档，将其解压缩，最后得到您真正想要的一个文件。
解决上述问题的另一种方法，同时又涉及到您的问题和我的答案，实际上是先对各个文件进行gzip压缩，然后将它们压缩在一起。解决此问题的原因是，当您将文件一起压缩时，单个文件实际上在压缩包中有明确的界限。然后，当您请求从冰川进行检索时，您只能请求档案的range
。例如，您可以说，“冰川，请给我在X档案X的105MB到115MB之间的字节”。这样，您可以（1）减少请求的总数（因为只有一个tar文件），并且（2）减少请求和存储的总数（因为有了压缩数据）。现在，要知道需要检索的范围，您需要将元数据存储在某个地方，通常是您将保持层次结构的位置！ （就像我上面提到的RDS，DynamoDB，Elasticsearch等）。
无论如何，只是一项优化，将来可以节省大量金钱（而且我与大量的客户合作，他们浪费了很多钱，因为他们对此一无所知。）]]