Якби у мене було мільйон зображень, чи було б краще зберігати їх у якійсь ієрархії папок / підпапок або просто скидати їх усі прямо у відро (без будь-яких папок)?
Чи скидання всіх зображень у відро без ієрархії уповільнить операції LIST?
Чи є значні накладні витрати на створення папок та підпапок на льоту та налаштування їх ACL (програмно кажучи)?
Відповіді:
S3 не поважає ієрархічні простори імен. Кожне сегмент просто містить кілька зіставлення від ключа до об'єкта (разом із пов'язаними метаданими, списками контролю доступу тощо).
Незважаючи на те, що ключ вашого об'єкта може містити '/', S3 трактує шлях як простий рядок і розміщує всі об'єкти в плоскому просторі імен.
На моєму досвіді, операції LIST займають (лінійно) довше, оскільки кількість об’єктів збільшується, але це, мабуть, є симптомом підвищеного вводу-виводу, необхідного на серверах Amazon, і передачі даних до вашого клієнта.
Однак, здається, час пошуку не збільшується із підрахунком об'єктів - це, швидше за все, якась реалізація хеш-таблиці O (1) на їх кінці - тому наявність багатьох об'єктів в одному сегменті має бути настільки ж продуктивним, як і невеликі сегменти для звичайного використання (тобто не СПИСКИ).
Що стосується ACL, гранти можна встановлювати на сегмент та на кожен окремий об'єкт. Оскільки ієрархії немає, вони єдині два варіанти. Очевидно, що встановлення якомога більшої кількості сегментних грантів суттєво зменшить головний біль адміністратора, якщо у вас є мільйони файлів, але пам’ятайте, що ви можете надавати дозволи, а не відкликати їх, тому гранти на рівні сегмента повинні бути максимальною підмножиною списку контролю доступу для всіх його зміст.
Я б рекомендував розділити на окремі сегменти для:
Відповідь на вихідне запитання "Максимальна кількість файлів на каталог у S3" така: НЕОГРАНІЧЕНО. Див. Також обмеження S3 для об’єктів у відрі .
Я використовую структуру каталогів з коренем, а принаймні один підкаталог. Я часто використовую "дату імпорту документа" як каталог під коренем. Це може трохи полегшити управління резервними копіями. Незалежно від файлової системи, яку ви використовуєте, ви з часом зобов’язані досягти межі кількості файлів (практична, якщо не фізична). Ви можете подумати і про підтримку декількох коренів.