Создание префиксов в S3 для паралелизационного чтения и повышения производительности

Question

Я провожу некоторые исследования и читаю эту страницу https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html

Там написано

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

Я не уверен, что означает последний бит.Насколько я понимаю, для имени файла «Australia / NSW / Sydney» префикс «Australia / NSW».Правильно?

Как создание 10 из них повышает производительность чтения?Вы создаете, например, Australia / NSW1 /, Australia / NSW2 /, Australia / NSW3 /, а затем каким-то образом сопоставляете их с балансировщиком нагрузки?

Answer 1

S3 разработан как Hashtable / HashMap в Java.Префикс формирует хэш для хэш-корзины ... и фактические файлы хранятся в группах в этих корзинах ...

Для поиска конкретного файла необходимо сравнить все файлы в хэш-корзине.... тогда как получение хеш-памяти происходит мгновенно (с постоянным временем).

Таким образом, чем более описательными являются ключи, тем больше хеш-блоков, следовательно, меньше элементов в этих корзинах ... что ускоряет поиск...

Например: корзина с подробной информацией о туристических достопримечательностях для всех стран мира
Bucket1: placeName.jpg (все файлы в корзине без префикса)
Bucket2: countryName / state / placeName.jpg

теперь, если вы ищете Sydney.info в Австралии / NSW ... поиск будет быстрее во втором сегменте.

Answer 2

Нет, S3 никогда не подключается к LB. Эта статья охватывает эту тему, но важные моменты:

(...) ключи в S3 разделены префиксом

(...)

Разделы разделены либо из-за постоянной высокой частоты запросов, либо из-за того, что они содержат большое количество ключей (что может замедлить поиск в разделе).Перемещение ключей во вновь создаваемые разделы сопряжено с дополнительными затратами, но при низкой частоте запросов и без особых хитростей мы можем поддерживать достаточно высокую производительность даже во время операций разделения разделов.Эта операция разделения происходит десятки раз в день по всему S3 и просто остается незамеченной с точки зрения производительности пользователя.Однако, когда частота запросов значительно увеличивается в одном разделе, разделение на разделы ухудшает производительность запроса.Как же тогда эти тяжелые рабочие нагрузки работают со временем?Умное именование самих ключей!

Таким образом, Australia/NSW/ можно читать из того же раздела, в то время как Australia/NSW1/, а Australia/NSW2/ можно читать из двух других.Так не должно быть, но все же префиксы дают возможность некоторого контроля над тем, как разделить данные, потому что вы лучше понимаете, какие операции чтения вы будете выполнять на нем.Вы должны стремиться к тому, чтобы чтения распределялись равномерно по префиксам.