S3 - Что является префиксом? И что такое Ratelimits?

Мне было интересно, знает ли кто-нибудь, что такое префикс s3 и как он взаимодействует с опубликованными в amazon ограничениями скорости s3:

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

Хотя это действительно ясно, я не совсем уверен, что такое префикс?

Требуется ли для префикса разделитель?

Если у нас есть корзина, в которой мы храним все файлы на "корневом" уровне (полностью плоский, без префиксов/разделителей), считается ли это единым "префиксом" и подчиняется ли он указанным выше ограничениям скорости?

То, как я интерпретирую документацию amazon, подсказывает мне, что это так, и что плоская структура будет рассматриваться как один "префикс". (т.е. на него будут распространяться указанные выше ограничения скорости)

Предположим, что ваше ведро (созданное администратором) имеет четыре объекта с следующие ключи объекта:

Development/Projects1.xls

Finance/statement1.pdf

Private/taxdocument.pdf

s3-dg.pdf

Ключ s3-dg.pdf не имеет префикса, поэтому его объект отображается прямо на корневом уровне ведра. Если вы откроете разработку/ В этой папке вы видите объект Projects.xlsx.

В приведенном выше примере s3-dg.pdf будет подчиняться другому ограничению скорости (5500 запросов GET в секунду), чем каждому из других префиксов (Development/Finance/Private)?

Что еще более запутанно, я читал пару блогов о том, что amazon использует первые N байтов в качестве ключа раздела и поощряет использование префиксов с высокой мощностью, я просто не уверен, как это взаимодействует с корзиной с "плоской файловой структурой" ,

Ответы

Ответ 1

Вы правы, объявление кажется противоречивым. Это просто не правильно написано, но информация верна. Короче:

  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 без рандомизации префиксов.

Однако, если новых пределов недостаточно, необходимо использовать префиксы. Префикс не имеет фиксированного количества символов. Это любая строка между именем сегмента и именем объекта, например:

  • Ковш/folder1/sub1/файл
  • Ковш/folder1/sub2/файл
  • Ковш/1/файл
  • Ковш/2/файл

Префиксами объекта 'file' будут: /folder1/sub1/, /folder1/sub2/, /1/, /2/. В этом примере, если вы равномерно распределите чтение по всем четырем префиксам, вы сможете выполнить 22 000 запросов в секунду.

Ответ 2

Похоже, это неясно решено в сообщении релиза Амазонки

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

Производительность зависит от префикса, поэтому вы можете использовать столько префиксов, сколько вам нужно параллельно для достижения требуемой пропускной способности. Нет ограничений на количество префиксов.

Это повышение производительности по частоте запросов S3 устраняет все предыдущие рекомендации по рандомизации префиксов объектов для достижения более высокой производительности. Это означает, что теперь вы можете использовать логические или последовательные шаблоны именования в именовании объектов S3 без каких-либо последствий для производительности. Это улучшение теперь доступно во всех регионах AWS. Для получения дополнительной информации посетите руководство разработчика Amazon S3.

Ответ 3

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

Теперь это не проблема, если вы ожидаете менее 100 запросов в секунду, но если у вас есть серьезные требования к этому, тогда вам нужно подумать об именовании.

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

например, если первые 6 символов определяют раздел:

files/user/bob были бы плохими, поскольку все объекты были бы на одном files/ раздела 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.

Ответ 4

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