Я считаю, что объяснение здесь, с той же страницы:
В этом примере показать, как Amazon S3 может использовать первый символ имени ключа для распределения, но при очень больших нагрузках (более 2000 запросов в секундах или для ведра, содержащего миллиарды объектов), Amazon S3 может использовать больше символов для схемы разбиения. Amazon S3 может автоматически разделять эти разделы дальше по мере увеличения количества ключей и запросов с течением времени.
Импликация (который все мы действительно можем идти дальше, так как внутренности S3 не являются публичной информацией) является то, что, в случае необходимости, S3 будет автоматически разбивать разделы индекса в зависимости от рабочей нагрузки, в целях уменьшить горячие точки ... но если вы не обеспечите очевидную логическую «точку разделения» - такую как введение некоторой псевдослучайности в данной точке в пространстве ключей, алгоритм не будет иметь ничего, на котором можно было бы основать такой раскол ,
Любое значение времени прирастает несколько монотонно, алгоритм не может сделать, чтобы вырезать один раздел на два, чтобы каждый из них видел примерно эквивалентные рабочие нагрузки для записи, когда объекты создавались или почти в порядке клавиш.
Случайность в фиксированной точке дает алгоритму гораздо более ясную цель для разделения, и, по-видимому, эта точка может быть там, где она должна находиться в ключе, а не только в начале.
И наоборот, с помощью этого примера вы предоставляете легкую и очевидную точку разделения между анимациями и видео ... первая точка раздела может быть прямо там на первом символе, и этого может быть достаточно ... но если нет, то в конце анимации/или видео/... или в обоих случаях появляются очевидные точки разделения. Затем любой из этих разделов можно впоследствии разделить, если необходимо, чтобы разместить объем трафика, который вы предлагаете.
Я бы предположил, что это в значительной степени академическая дискуссия, если вы не планируете рабочие нагрузки сотен запросов в секунду, поддерживаются. Храните свои объекты с ключами, созданными с помощью полезного и содержательного соглашения, давая соответствующие, но не чрезмерные соображения, эти рекомендации.
спасибо, но похоже, что вы не читали мой вопрос :) Я понимаю все, что вы сказали, но я привел пример из документа amazon (его даже те же ссылки, которые вы дали), и они дают этот пример как хороший, поэтому я пытаюсь понять, почему это хорошо –
ваш пример не соответствует рекомендациям, приведенным на этой странице. у вас все еще есть префикс видео или анимации перед вашей случайной последовательностью. Эта случайная последовательность должна быть первой. Причина в том, что они балансируют между узлами хранения s3 по алфавиту. поэтому видео/1 видео/2 видео/3 будут сразу попадать на один и тот же узел хранения. – lcerezo
спасибо, я понимаю, пожалуйста, если вы можете нажать на ссылку https://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html нажмите ctrl + f и serach для: examplebucket/анимации/232a-2013-26-05-15-00-00/cust1234234/animation1.obj немного прокрутите, и вы увидите, что они дали этот пример, и они дали ему как хороший –