Поддерживает ли Amazon AWS S3 Glacier некое подобие иерархии файлов внутри Vault for Archives?
Нет, нет другой иерархии, кроме «архивы существуют внутри хранилища».
Например, в AWS S3 объектам задается иерархия через /. Например: all_logs / some_sub_category / log.txt
На самом деле это неверно.
S3 не имеет внутренней иерархии. Символ / абсолютно не отличается от любого другого символа, действительного для ключа объекта S3.
Консоль S3 - и большинство клиентских инструментов S3, включая CLI AWS - обрабатывают / характер особым образом. Но обратите внимание, что это на стороне клиента. Клиент позаботится о том, чтобы список происходил таким образом, что / ведет себя , как большинство людей ожидает , то есть как «разделитель иерархии».
Если Иерархия файлов внутри S3 Glacier возможна, не могли бы вы дать краткие инструкции, как это сделать?
Вам нужно отслеживать свою иерархию отдельно. Например, когда вы храните архив в Glacier, вы можете записать метаданные об этом архиве в базу данных (RDS, DynamoDB, и т. Д. c).
В качестве примечания: будьте осторожны с .tar.gz в Glacier, особенно если вы говорите об (1) очень большом архиве (2), который состоит из большого количества небольших отдельных файлов (3), к которым вы, возможно, захотите получить доступ индивидуально.
Если эти условия соблюдены (а по моему опыту они часто встречаются в реальном сценарии ios), то использование .tar.gz часто приводит к чрезмерным затратам при извлечении данных.
Причина в том, что вы платите по количеству запросов, а также по размеру запроса. Таким образом, хотя наличие одного огромного файла .tar.gz может снизить ваши затраты с точки зрения количества запросов, тот факт, что gzip использует DEFLATE, который является алгоритмом сжатия без разделения, означает, что вам придется получить весь архив .tar.gz , распакуйте его и, наконец, получите тот файл, который вам действительно нужен.
Альтернативный подход, который решает проблему, которую я описал выше - и которая, в то же время, относится к вашему вопросу и моему ответу - это чтобы сначала сжать отдельные файлы, а затем объединить их в архив. Причина, по которой это решает проблему, заключается в том, что когда вы объединяете файлы вместе, отдельные файлы фактически имеют четкие границы внутри tarball. И затем, когда вы запрашиваете извлечение из ледника, вы можете запросить только диапазон архива. Например, вы могли бы сказать: «Ледник, дайте мне байты от 105 до 115 МБ архива X» . Таким образом вы можете (1) уменьшить общее количество запросов (поскольку у вас есть один файл tar) и (2) уменьшить общий размер запросов и хранилища (поскольку у вас есть сжатые данные).
Теперь, чтобы знать, какой диапазон вам нужно получить, вам нужно где-то хранить метаданные - обычно в том же месте, где вы будете хранить свою иерархию! (как я уже упоминал выше, RDS, DynamoDB, Elasticsearch и т. д. c).
В любом случае, просто оптимизация, которая могла бы сэкономить огромную сумму денег в будущем (а я работал с тонной клиентов, которые потратили кучу денег, потому что не знали об этом).