Если последовательный хэш эффективен, почему люди не используют его везде? - PullRequest
3 голосов
/ 28 июня 2011

Меня спросили о некоторых недостатках согласованного хэша . Но я думаю, что это стоит немного больше, чем традиционный хеш% N хеш. Как уже упоминалось в заголовке, если согласованный хэш очень хорош, почему бы нам просто не использовать его?

Ты знаешь больше? Кто может сказать мне немного?

Ответы [ 3 ]

2 голосов
/ 26 апреля 2012

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

Технически, согласованное хеширование потребляет немного больше ресурсов процессора; просмотр отсортированного списка, чтобы определить, на какой сервер сопоставить объект, - это операция O (log n), где n - это количество серверов X, количество слотов на сервер, а простое хеширование - O (1).

Однако на практике O (log n) настолько быстр, что это не имеет значения. (Например, 8 серверов X 1024 слота на сервер = 8192 элемента, log2 (8192) = не более 13 сравнений в худшем случае.) Авторы оригинала проверили это и обнаружили, что вычисление сервера кэша с использованием согласованного хеширования занимает всего 20 микросекунд. настроить. Аналогично, согласованное хеширование требует места для хранения отсортированного списка серверных слотов, в то время как простое хеширование не занимает места, но требуемый объем является незначительным, порядка килобайта.

Почему это не известно лучше? Если бы мне пришлось угадывать, я бы сказал, что только потому, что академическим идеям может потребоваться время для распространения в промышленности. (Оригинал статьи был написан в 1997 году.)

2 голосов
/ 28 июня 2011

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

0 голосов
/ 15 января 2015

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

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

Таким образом, с точки зрения согласованного хеширования, мы не просто добавляем узел;мы удваиваем количество узлов.Это означает, что так или иначе, в лучшем случае, мы перемещаем половину элементов.Конечно, последовательная техника хэширования может сократить ходы и попытаться приблизиться к этому идеалу, но лучшее улучшение случая - это только постоянный коэффициент 2x, который не меняет нашу общую сложность.

Подход сс другой стороны, хеш-таблицы в большинстве приложений полностью зависят от производительности кэша.Весь интерес в том, чтобы заставить их работать быстрее, заключается в том, чтобы как можно быстрее вычислить материал, затрагивая как можно меньше памяти.Добавление последовательного хеширования, вероятно, будет более чем в 2 раза медленнее, независимо от того, как вы на это смотрите;в конечном счете, последовательное хеширование будет ухудшаться.

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

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

...