17 июля 2018 года было официальное объявление AWS, в котором объяснялось, что больше нет необходимости рандомизировать первые символы каждого ключа объекта S3 для достижения максимальной производительности: https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/
Amazon S3 объявляет об увеличении скорости запросов
Размещено: 17 июля 2018 г.
Amazon S3 теперь обеспечивает повышенную производительность для поддержки не менее 3500 запросов в секунду для добавления данных и 5 500 запросов в секунду для извлечения данных, что позволяет сэкономить значительное время обработки без дополнительной оплаты. Каждый префикс 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 Object API использует весь ключ, концепция конкретного префикса или разделителя не существует для поиска объекта. Так можно ли ожидать 5500 запросов / сек на a1/ или, альтернативно, 5,500 запросов / сек на a1/b- и 5 500 на 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- теперь находятся в другом разделе).
Где и когда и какой конкретно порог запускает поведение разделения, не задокументировано, но похоже, что это связано только с количеством запросов, а не с количеством или размером объектов. Ранее эти разделы были ограничены несколькими сотнями запросов в секунду каждый, и это было значительно увеличено.