Существует ли гарантированный честный вариант последовательного хеширования?

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

Редактировать. В моем конкретном случае набор ключей известен заранее (и "небольшой"). Именно эти ключи всегда будут присутствовать и должны быть назначены ровно одному узлу каждый в любой заданный момент времени.


person SoftMemes    schedule 12.06.2012    source источник
comment
+1, мне кажется вполне разумным вопрос: существует ли известный алгоритм со всеми свойствами алгоритма X плюс дополнительное свойство Y? Очевидно, что спрашивающий уже провел достаточно исследований в одиночку, чтобы найти алгоритм X.   -  person Steve Jessop    schedule 12.06.2012
comment
я даже не вижу никаких требований для исследования в часто задаваемых вопросах - я думаю, что есть воображаемый часто задаваемые вопросы, который существует в умах людей, чрезмерно озабоченных домашними заданиями, которые загрязняют все остальное. некоторые из нас очень рады быть научным сотрудником по интересным вопросам.   -  person andrew cooke    schedule 12.06.2012
comment
Я не думаю, что то, о чем вы просите, практически достижимо. При наличии n узлов существует n^2 возможных сценариев доступности; Я сомневаюсь, что можно разработать алгоритм, справедливо распределяющий обязанности во всех этих сценариях.   -  person Nick Johnson    schedule 14.06.2012
comment
@Ник, делать это честно и детерминированно - не проблема, просто перебирай узлы по кругу, и все готово. Однако сделать это, сохраняя при этом то свойство, что движения клавиш должны быть минимальными, когда узлы входят или выходят, намного сложнее.   -  person SoftMemes    schedule 14.06.2012


Ответы (2)


Мне кажется, вы ищете минимальный идеальный хеш.

person Jim Mischel    schedule 12.06.2012
comment
Не совсем. В моем случае мне нужны коллизии (несколько ключей, выделяемых одним и тем же узлам), и у меня есть особые требования к тому, что должно происходить при изменении количества узлов. - person SoftMemes; 13.06.2012

не только в среднем для случайных ключей

Это не точное описание гарантий, обеспечиваемых последовательным хэшированием. Во-первых, «в среднем» не отражает того факта, что при случайном размещении большого количества виртуальных узлов на круге и хорошем семействе хеш-функций (например, независимом от логарифмического уровня) дисбаланс нагрузки серьезно возрастает. вряд ли будет большим (я считаю, что обычный дисбаланс должен быть порядка квадратного корня из числа клавиш, назначенных конкретной машине). Во-вторых, ключи не обязательно должны быть случайными, если они не зависят от случайно выбранной хеш-функции (незаметный противник).

Поскольку вы хотите, чтобы хэширование было всегда честным, рандомизация не поможет, поскольку результаты ГСЧ могут быть неотличимы от этот. Ни один детерминированный алгоритм не может статически назначать предпочтения узла ключам без возможности дисбаланса, если только ключи не известны в автономном режиме.

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

person magic    schedule 12.06.2012
comment
вариация (стандартное отклонение) в ячейке представляет собой квадратный корень из числа значений в этой ячейке (предполагая случайную - пуассоновскую - статистику). - person andrew cooke; 12.06.2012
comment
Однако согласен с описанием последовательного хеширования - в этом случае мне нужны еще более сильные гарантии, хотя я все же предпочел бы не иметь явного общего состояния (но иметь возможность получать распределение только из бинов и данных). В моем случае набор ключей на самом деле известен заранее, я должен был включить это в свой исходный вопрос (будет обновляться). - person SoftMemes; 12.06.2012