Що означає нове оголошення "Підвищена ефективність запиту S3"

17 липня 2018 року відбулося офіційне повідомлення AWS, в якому пояснювалося, що більше немає необхідності рандомізувати перші символи кожної клавіші об'єкта S3 для досягнення максимальної продуктивності: https://aws.amazon.com/about-aws/whats-new / 2018/07 / amazon-s3-анонси-підвищення-запит-швидкість-ефективність /

Amazon S3 оголошує про підвищену ефективність запиту

Опубліковано: 17 липня 2018 року

Тепер Amazon S3 забезпечує підвищену продуктивність для підтримки принаймні 3500 запитів в секунду для додавання даних та 5500 запитів за секунду для отримання даних, що дозволяє заощадити значний час обробки без додаткової оплати. Кожен префікс S3 може підтримувати ці показники запиту, спрощуючи значно підвищити продуктивність.

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

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

Це чудово, але це також заплутано. В ньому йдеться про те, що кожен префікс S3 може підтримувати ці ставки запитів, спрощуючи значно підвищити продуктивність

Але оскільки префікси та роздільники є лише аргументами GET Bucket (List Objects)API при переліку вмісту відра, то як може бути сенсом говорити про ефективність пошуку об’єктів "за префіксом". Кожен виклик GET Bucket (List Objects)може вибрати будь-який префікс і роздільник, який він хоче, тому префікси не є заздалегідь визначеною сутністю.

Наприклад, якщо у моєму відрі є такі об'єкти:

a1/b-2
a1/c-3

Тоді я можу вибрати "/" або "-" в якості роздільника кожного разу, коли я перелічу вміст відра, тому я можу вважати свої префікси як

a1/ 

або

a1/b-
a1/c-

Але оскільки GET ObjectAPI використовує весь ключ, поняття певного префікса чи роздільника не існує для пошуку об’єктів. Тож чи можу я очікувати, що на 5500 рек / с увімкнено a1/або на 5500 рек / с у a1/b-та на 5500 на a1/c-?

То чи може хтось пояснити, що мається на увазі під оголошенням, коли він пропонує певний рівень продуктивності (наприклад, +5 500 запитів за секунду для отримання даних) для "кожного s3 префікса"?

Те, що насправді називається префіксом, представляється надмірним спрощенням, яке дійсно стосується кожного розділу індексу ковша. Індекс є лексичним, тому розбиття відбуваються на основі провідних символів в об'єктному ключі. Отже, це називається префіксом .

S3 управляє розділами індексу автоматично та прозоро, тому точне визначення «префікса» тут насправді дещо неточне: це «все, що S3 вирішить, необхідне для підтримки навантаження вашого відра». S3 розбиває розділи індексу у відповідь на навантаження, тому два об'єкти, які сьогодні можуть мати однаковий "префікс", можуть завтра мати різні префікси, і все це робиться у фоновому режимі.

Зараз a1 / a -... і a1 / b -... і a1 / c -... все може бути одним префіксом. Але кинути достатньо трафіку на відро, і S3 може вирішити, що розділ слід розділити, так що завтра a1 / a- і a1 / b- можуть бути в одному префіксі, тоді як a1 / c- може бути у власному префіксі. (Тобто, ключі <a1 / c- знаходяться в одному розділі, тоді як ключі> = a1 / c- зараз в іншому розділі).

Де і коли і конкретно, який поріг викликає поділ поведінки, не зафіксовано, але, мабуть, це стосується лише кількості запитів, а не кількості чи розміру об'єктів. Раніше ці розділи обмежувались кількома сотнями запитів в секунду, і це було значно збільшено.