S3 - Що саме таке префікс? А що застосовують Ratelimits?

Мені було цікаво, чи хтось знає, що таке префікс s3 і як він взаємодіє з опублікованими обмеженнями швидкості s3 Amazon :

Amazon S3 автоматично масштабується до високих частот запитів. Наприклад, ваша програма може отримати щонайменше 3500 запитів PUT / POST / DELETE та 5500 запитів GET за секунду за префікс у відрі. Кількість префіксів у відрі не обмежена.

Хоча це насправді зрозуміло, я не зовсім впевнений, що таке префікс?

Префікс вимагає роздільника?

Якщо у нас є сегмент, де ми зберігаємо всі файли на "кореневому" рівні (повністю рівномірно, без будь-яких префіксів / роздільників), чи вважається це одним "префіксом" і чи поширюється на нього обмеження швидкості, розміщені вище?

Те, як я трактую документацію Amazon, підказує мені, що це ІС, і що плоска структура вважатиметься єдиним "префіксом". (тобто на нього поширюватимуться опубліковані обмеження ставок вище)

Припустимо, що у вашому сегменті (створеному адміністратором) є чотири об'єкти з такими ключами об'єктів:

Розробка / Проекти1.xls

Фінанси / звіт1.pdf

Приватний / податковий документ.pdf

s3-dg.pdf

Ключ s3-dg.pdf не має префікса, тому його об'єкт відображається безпосередньо на кореневому рівні сегмента. Якщо відкрити папку Розробка /, ви побачите в ній об’єкт Projects.xlsx.

У наведеному вище прикладі для s3-dg.pdf застосовуватимуться інші обмеження швидкості (5500 запитів GET / секунду), ніж для кожного з інших префіксів (Розробка / Фінанси / Приватне)?

Що ще більш заплутане, я прочитав кілька блогів про Amazon, використовуючи перші N байт як розділовий ключ, і заохочуючи використовувати префікси високої потужності, я просто не впевнений, як це взаємодіє з сегментом із "плоскою структурою файлу" .

Ви праві, повідомлення, здається, суперечить самому собі. Просто це написано неправильно, але інформація правильна. Коротко:

1. Кожен префікс може досягти до 3500/5500 запитів на секунду, тому для багатьох цілей припускають , що вам не потрібно було б використовувати кілька префіксів.
2. Префіксами вважається весь шлях (до останнього '/') розташування об'єкта, і вони більше не хешуються лише першими 6-8 символами. Тому було б достатньо просто розподілити дані між будь-якими двома "папками", щоб отримати максимум x2 запитів в секунду. (якщо запити розподілені між ними рівномірно)

Для довідки, ось відповідь від служби підтримки AWS на мій запит на роз’яснення:

Привіт Орен,

Дякуємо за звернення до служби підтримки AWS.

Я розумію, що ви прочитали допис AWS про підвищення швидкості запитів S3, і у вас виникли додаткові запитання щодо цього оголошення.

До цього оновлення S3 підтримував 100 запитів PUT / LIST / DELETE в секунду та 300 запитів GET в секунду. Для досягнення більш високої продуктивності слід було застосувати схему випадкового хешу / префіксу. З минулого року обмеження швидкості запитів зросли до 3500 PUT / POST / DELETE та 5500 запитів GET на секунду. Цього збільшення часто достатньо для того, щоб додатки пом'якшували помилки 503 SlowDown без необхідності рандомізації префіксів.

Однак, якщо нових обмежень недостатньо, потрібно буде використовувати префікси. Префікс не має фіксованої кількості символів. Це будь-який рядок між ім'ям сегмента та ім'ям об'єкта, наприклад:

• відро / папка1 / під1 / файл
• відро / папка1 / під2 / файл
• відро / 1 / файл
• відро / 2 / файл

Префікси «файл» об'єкт буде: /folder1/sub1/, /folder1/sub2/, /1/, /2/. У цьому прикладі, якщо ви розподіляєте читання по всіх чотирьох префіксах рівномірно, ви можете досягти 22000 запитів на секунду.

Схоже, це неясно розглядається у повідомленні про випуск Amazon

https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

Шкала продуктивності на префікс, тому ви можете використовувати стільки префіксів, скільки вам потрібно паралельно для досягнення необхідної пропускної здатності. Кількість префіксів обмежена.

Це підвищення продуктивності швидкості запиту S3 усуває будь-які попередні вказівки щодо рандомізації префіксів об’єктів для досягнення швидшої продуктивності. Це означає, що тепер ви можете використовувати логічні або послідовні шаблони імен у іменуванні об’єктів S3 без жодних наслідків для продуктивності. Зараз це вдосконалення доступне у всіх регіонах AWS. Для отримання додаткової інформації відвідайте посібник розробника Amazon S3.

Для того, щоб AWS обробляв мільярди запитів в секунду, їм потрібно обробляти дані, щоб він міг оптимізувати пропускну здатність. Для цього вони розділяють дані на розділи на основі перших 6 - 8 символів ключа об’єкта. Пам'ятайте, S3 не є ієрархічною файловою системою, це лише сховище ключ-значення, хоча ключ часто використовується як шлях до файлу для впорядкування даних, префікс + ім'я файлу.

Зараз це не проблема, якщо ви очікуєте менше 100 запитів на секунду, але якщо у вас є серйозні вимоги до цього, то вам слід подумати про іменування.

Для максимальної паралельної пропускної здатності слід врахувати, як споживаються ваші дані, і використовувати найрізноманітніші символи на початку ключа, або навіть генерувати 8 випадкових символів для перших 8 символів ключа.

наприклад, припускаючи, що перші 6 символів визначають розділ:

files/user/bob було б погано, оскільки всі об’єкти були б в одному розділі files/.

2018-09-21/files/bobбуло б майже так само погано, якби лише сьогоднішні дані читалися з розділу2018-0 . Але трохи краще, якщо предмети читатимуться за минулі роки.

bob/users/files було б непогано, якщо різні користувачі, ймовірно, одночасно використовують дані з розділу bob/us. Але не все так добре, якщо Боб є найзайнятішим користувачем.

3B6EA902/files/users/bob було б найкращим для продуктивності, але більш складним для посилання, коли перша частина є випадковим рядком, це було б рівномірно розподілено.

Залежно від ваших даних, вам потрібно продумати будь-який момент часу, хто що читає, і переконатися, що клавіші починаються з достатньою кількістю варіацій, щоб розділити належним чином.

Для вашого прикладу припустимо, що розділ взято з перших 6 символів ключа:

для ключа Development/Projects1.xlsбуде розділовим ключемDevelo

для ключа Finance/statement1.pdfбуде розділовим ключемFinanc

для ключа Private/taxdocument.pdfбуде розділовим ключемPrivat

для ключа s3-dg.pdfбуде розділовим ключемs3-dg.

Проголосована відповідь на це була для мене дещо оманливою. Якщо це шляхи

відро / папка1 / під1 / файл
відро / папка1 / під2 /
відро файлу / 1 / файл
відро / 2 / файл

Вашим префіксом для файлу буде насправді
folder1
/ sub1 / folder1 / sub2 /
1 / file
2 / file

https://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysHierarchy.html Будь ласка, перегляньте документи. У мене були проблеми з провідним знаком «/» при спробі перерахувати ключі за допомогою потоку повітря s3hook.

Префікси S3 раніше визначалися першими 6-8 символами;

Це змінилося в середині 2018 року - див. Оголошення https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

Але це напівправда . Насправді префікси (у старому визначенні) все ще мають значення.

S3 не є традиційним “сховищем” - кожен каталог / ім’я файлу є окремим об’єктом у сховищі об’єктів ключ / значення. А також дані повинні бути розділені / шардовані для масштабування до квазільйонів об'єктів. Так що так, це нове шардінг є якось “автоматичним”, але насправді, якщо ви створили новий процес, який пише в нього із шаленим паралелізмом у різні підкаталоги. Перш ніж S3 дізнається про новий шаблон доступу, ви можете зіткнутися з регулюванням S3, перш ніж він відповідно перерозділить / переділить дані.

Вивчення нових моделей доступу вимагає часу. Перерозподіл даних вимагає часу.

В середині 2018 року ситуація покращилася (~ 10 разів пропускна здатність для нового сегмента без статистичних даних), але це все ще не те, що могло б бути, якщо дані правильно розділені. Хоча справедливості заради, це може не застосовуватися до вас, якщо у вас немає тонни даних або шаблон доступу до даних не є надзвичайно паралельним (наприклад, запуск кластера Hadoop / Spark на багатьох Tbs даних у S3 із сотнями + завдань, що мають паралельний доступ до одного сегмента).

TLDR :

«Старі префікси» все ще мають значення. Запишіть дані до кореня вашого сегмента, і каталог першого рівня там визначить "префікс" (наприклад, зробіть його випадковим)

"Нові префікси" працюють, але спочатку не. Потрібен час, щоб пристосуватись для завантаження.

PS. Інший підхід - ви можете зв’язатися зі своїм AWS TAM (якщо він у вас є) і попросити їх попередньо розділити новий сегмент S3, якщо ви очікуєте, що незабаром тонна даних заповнить його.

У випадку, якщо ви запитуєте S3 за допомогою Athena, EMR / Hive або Redshift Spectrum, збільшення кількості префіксів може означати додавання більшої кількості розділів (оскільки ідентифікатор розділу є частиною префікса). Якщо ви використовуєте datetime як (одну з) ваших клавіш розділу, кількість розділів (і префіксів) автоматично зростатиме, оскільки з часом додаються нові дані, а також зростає загальна максимальна кількість SET GET в секунду.