Amazon AWS S3 Glacier: есть ли файловая иерархия

Поддерживает ли 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 и т. Д.).

В качестве побочного примечания: будьте осторожны с .tar.gz в Glacier, особенно если вы говорите об (1) очень большом архиве (2), который состоит из большого количества небольших отдельных файлов (3), к которым вы, возможно, захотите получить доступ индивидуально. .

Если эти условия соблюдены (а, по моему опыту, они часто встречаются в реальных сценариях), то использование .tar.gz часто приводит к чрезмерным затратам при извлечении данных.

Причина в том, что вы платите за количество запросов, а также за размер запроса. Таким образом, хотя наличие одного огромного .tar.gz файла может снизить ваши затраты с точки зрения количества запросов, тот факт, что gzip использует DEFLATE, который является алгоритмом сжатия без разделения, означает, что вам придется получить весь .tar.gz архив, распаковать его, и, наконец, получите тот файл, который вам действительно нужен.

Альтернативный подход, который решает проблему, которую я описал выше - и которая, в то же время, относится к вашему вопросу и моему ответу - состоит в том, чтобы сначала сжимать отдельные файлы, а затем объединять их в архив. Причина, по которой это решает проблему, заключается в том, что когда вы объединяете файлы вместе, отдельные файлы фактически имеют четкие границы внутри tarball. А затем, когда вы запрашиваете извлечение из ледника, вы можете запросить только диапазон архива. Например, вы можете сказать: «Ледник, дайте мне байты от 105 до 115 МБ в архиве X». Таким образом вы можете (1) уменьшить общее количество запросов (поскольку у вас есть один файл tar) и (2) уменьшить общий размер запросов и хранилища (поскольку у вас есть сжатые данные).

Теперь, чтобы знать, какой диапазон вам нужно получить, вам нужно где-то хранить метаданные - обычно в том же месте, где вы будете хранить свою иерархию! (как я уже упоминал выше, RDS, DynamoDB, Elasticsearch и т. д.).

В любом случае, просто оптимизация, которая могла бы сэкономить огромную сумму денег в будущем (и я работал с множеством клиентов, которые зря потратили много денег, потому что не знали об этом).