Есть ли у amazon s3 ограничение на количество создаваемых вами вложенных папок?

#amazon-web-services #amazon-s3

#amazon-веб-сервисы #amazon-s3

Вопрос:

Я подумываю об использовании Amazon s3 для реализации моего собственного решения для резервного копирования. Идея состоит в том, чтобы иметь скрипт, который принимает каталог и рекурсивно загружает все файлы под этим каталогом в s3. Однако я не уверен, что это сработает по следующим причинам.

  • у s3, по-видимому, нет папок.
  • s3 накладывает ограничение на размер имени объектов (1024 символа).

Я полагаю, это означает, что если объект, идентифицированный как «/foo/bar/baz.txt «, тогда часть «/ foo /bar /» этого «пути к файлу» на самом деле является частью имени объекта и учитывается при ограничении символов в именах объектов. Если это правда, то я мог видеть, что это становится проблемой при загрузке глубоко вложенных файлов с длинными путями к файлам (хотя 1024 символа кажутся довольно щедрыми).

Правильно ли я все понимаю?

Комментарии:

1. Хотя я уже ответил на этот вопрос, мне не следовало этого делать, поскольку речь идет не о программировании и, следовательно, не по теме. В идеале он должен быть перенесен на суперпользователя или что-то в этом роде…

Ответ №1:

Да, это точно.

S3 — это хранилище ключей / значений, а не файловая система, хотя резервное копирование — это, безусловно, то, для чего его авторы ожидают, что оно будет использоваться (о чем свидетельствует выбор в документации примеров ключей, в основном являющихся путями к файлам!). Если на вашем компьютере структура каталогов и имена файлов настолько длинные и глубоко вложенные, что весь их путь превышает тысячу символов, я бы настоятельно рекомендовал реорганизовать ваш жесткий диск!

Если вы не можете этого сделать и у вас много длинных путей, вы можете попробовать что-то другое, кроме попытки однозначного сопоставления между этими двумя вещами. Например, вы можете хранить большие двоичные объекты данных (содержимое файла) с ключом, который является некоторым идентификатором GUID. Имейте отдельное хранилище ключей / значений, которое сопоставляет идентификаторы GUID с путями к файлам. Хотя это не поможет вам с обратным поиском. В основном делайте то же самое, что вы бы сделали, если бы пытались эффективно структурировать это в коде, используя алгоритмы и структуры данных. Потому что, на самом деле, это то, что вы делаете здесь тоже!

Отложив резервные копии в сторону и говоря в более общем плане, если вы использовали подкаталоги на диске только как своего рода метаданные, для этого в S3 можно использовать другие свойства метаданных. Но ваши ключи объектов все равно должны быть уникальными для всего набора данных.

Подробнее об объектах S3 можно прочитать в документации AWS.

Комментарии:

1. В дополнение к этой идее, если программа резервного копирования намеревается сохранить несколько версий файла (например, если файл был изменен, должна ли она сохранить предыдущую версию?), Это нарушает соответствие 1: 1 исходного имени файла целевому имени файла и добавляет больше причин для использования блога данных с идентификатором GUID.

2. Очень хороший момент, хотя у S3 есть идентификатор версии для каждого объекта.