Хеш-таблица оптимизирована для полной итерации + замена ключа - PullRequest
15 голосов
/ 12 мая 2011

У меня есть хеш-таблица, в которой подавляющее большинство обращений во время выполнения выполняется по одному из следующих шаблонов:

  • Итерация по всем парам ключ / значение.(Скорость этой операции имеет решающее значение.)
  • Изменить ключи (т.е. удалить пару ключ / значение и добавить другую с тем же значением, но другим ключом. Определить дубликаты ключей и объединить значения, если необходимо.) Этовыполняется в цикле, затрагивая многие тысячи ключей, но не вмешиваясь в другие операции.

Я также хотел бы, чтобы он занимал как можно меньше памяти.

Другие стандартные операции должныбыть доступными, хотя они используются реже, например

  • Вставить новую пару ключ / значение
  • По заданному ключу найдите соответствующее значение
  • Изменитезначение, связанное с существующим ключом

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

Проблемы с распространенными реализациями:

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

Схемы, которые работают, но не идеальны:

  • Отдельное сцепление с массивом (вместо связанного списка) для каждой корзины:
    Плохая локальность ссылок, возникающая из-за фрагментации памяти, поскольку небольшие массивы перераспределяются много раз
  • Линейное зондирование / квадратичное хеширование /двойное хеширование (с изменением Брента или без него):
    Таблица быстро заполняется маркерами удаления
  • Хеширование кукушки
    Работает только при <50% коэффициенте загрузки, и я хочу, чтобы высокий LF сохранял память иускорить итерацию. </li>

Существует ли специальная схема хеширования, которая будет хорошо работать в этом случае?


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

Ответы [ 3 ]

2 голосов
/ 15 мая 2011

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

1 голос
/ 29 июля 2011

Вы можете сделать намного лучше, чем коэффициент загрузки 50% с хэшированием кукушки.

Две хэш-функции с четырьмя элементами позволят вам получить более 90% без особых усилий.См. Эту статью:

http://www.ru.is/faculty/ulfar/CuckooHash.pdf

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

1 голос
/ 13 мая 2011

Исходя из того, как вы обращаетесь к данным, имеет ли смысл вообще использовать хеш-таблицу?

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

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

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