Когда бы вы хотели сделать s3 объектные ключи похожими - PullRequest
0 голосов
/ 11 мая 2018

Таким образом, S3 использует ключ объекта при разбиении данных, и что вы должны создавать свои ключи с некоторой случайностью для распределения рабочих нагрузок по нескольким разделам.Мой вопрос: есть ли сценарии, в которых вы хотели бы иметь подобные ключи?И если нет, то зачем тогда AWS использовать ключ для разделения ваших данных вместо случайного разделения самих данных?

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

Ответы [ 2 ]

0 голосов
/ 11 мая 2018

Таким образом, S3 использует ключ объекта для разделения данных

Подождите. Ваш вопрос кажется основанным на этом предположении, но это не правильно.

S3 не использует объектный ключ для разделения данных . Это действительно, как вы предлагаете, очень «странный дизайн» (или хуже).

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

В случае с аналогичными ключами вы можете найти объекты с общим префиксом (в той же «папке») по запросу. Хранение файлов журнала - простой пример, yyyy/mm/dd/.... Обратите внимание, что когда различные службы хранят для вас файлы журналов в бочках (журналы S3, CloudFront, ELB), ключи объектов выполняются следующим образом, потому что дата и время находятся в ключе объекта.

Когда S3 выполняет разбиение раздела, разделяется только индекс. Данные уже надежно хранятся и не перемещаются. Потенциальные соображения производительности связаны с производительностью индекса, а не с фактическим хранением данных объекта.

0 голосов
/ 11 мая 2018

Похоже, вы ссылаетесь на Частота запросов и производительность - Amazon Simple Storage Service , которая гласит:

Рекомендации по оптимальной практике Amazon S3 в этом разделе применимы, только если вы регулярно обрабатываете 100 или более запросов в секунду. Если ваша типичная рабочая нагрузка включает только случайные пакеты по 100 запросов в секунду и менее 800 запросов в секунду, вам не нужно следовать этим рекомендациям.

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

AWS не объяснила , почему они разработали Amazon S3 таким образом.

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