(Я предрежу этот вопрос, сказав, что я думаю, что практически нет никакого способа, которым UUID4 был бы спроектирован , чтобы не быть равномерно распределенным, но мне не хватает математических навыков и крипто-знаний, чтобы доказать это.)
При потоковой передаче данных в кинезис мы сталкиваемся с проблемой, когда один осколок, осколок № 4, очень горячий, а остальные семь осколков недогружены.Kinesis распределяет данные по своим шардам с помощью ключа раздела , который представляет собой строку в юникоде, которую он преобразует в хэш md5.
По умолчанию сегменты являются последовательными, поэтому, если у вас есть один шард, он будетесть все ключи разделов от 0 до 2 ^ 128 в нем.У нас есть восемь осколков, поэтому ведра ограничены с шагом 2 ^ 125.Конец каждого диапазона шардов в шестнадцатеричном виде:
0x20000000000000000000000000000000
0x40000000000000000000000000000000
0x60000000000000000000000000000000
0x80000000000000000000000000000000
0xa0000000000000000000000000000000
0xc0000000000000000000000000000000
0xe0000000000000000000000000000000
0x100000000000000000000000000000000
Мы делим на основе UUID 4. Мы предполагали, что это будет равномерно распределено по вышеуказанному адресному пространству, но с этим «горячим шардом»проблема, я начинаю задумываться.UUID4 имеют размер 2 ^ 128 бит, но они резервируют шесть битов для детерминированной информации , оставляя 2 ^ 122 значения, которые могут быть случайными.Это те шесть битов, которые дают мне паузу.
Тривиально, если я уберу шесть самых значимых бит, мое самое большое возможное значение будет 2 ^ 122, которое непременно попадет в первый или второй сегмент, все время,Но в действительности эти шесть цифр не являются наиболее значимыми в пространстве UUID4, так как они влияют на распределение?Если я использую UUID4 для ключа шардинга, будут ли мои данные равномерно распределены по шардам?