S3 - Что такое префикс?И какие ставки применяются? - PullRequest
0 голосов
/ 21 сентября 2018

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

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

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

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

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

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

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

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

Финансы / ведомость1.pdf

Личное / taxdocument.pdf

s3-dg.pdf

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

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


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

Ответы [ 3 ]

0 голосов
/ 22 сентября 2018

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

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

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

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

0 голосов
/ 15 мая 2019

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

  1. Каждый префикс может выполнять до 3500/5500 запросов в секунду, поэтому для многих целей предполагает, что не нужно использовать несколько префиксов.
  2. Префиксы считаются целым путем (до последнего '/') местоположения объекта и больше не хэшируются только первыми 6-8 символами.Поэтому было бы достаточно просто разделить данные между любыми двумя «папками», чтобы получить максимальное число запросов x2 в секунду.(если запросы делятся поровну между двумя)

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

Hello Oren,

Благодарим Вас за обращение в службу поддержки AWS.

Я понимаю, что вы прочитали сообщение AWS об увеличении производительности запросов S3 и у вас есть дополнительные вопросы относительно этого объявления.

Перед этим обновлением S3 поддерживал100 запросов PUT / LIST / DELETE в секунду и 300 запросов GET в секунду.Чтобы достичь более высокой производительности, должна быть реализована схема случайного хэша / префикса.С прошлого года ограничения на количество запросов увеличились до 3500 запросов PUT / POST / DELETE и 5500 запросов GET в секунду.Это увеличение часто достаточно для того, чтобы приложения могли смягчить ошибки 503 SlowDown без рандомизации префиксов.

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

  • bucket / folder1 / sub1 / file
  • bucket / folder1 / sub2 / file
  • bucket / 1 / file
  • bucket / 2 / file

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

0 голосов
/ 21 сентября 2018

Для того чтобы 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.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...