Согласованное хеширование как способ масштабирования операций записи

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

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

Что делать, если узел выходит из строя? Теоретически его ключи теперь принадлежат другим узлам. На практике у них не будет данных. Он потерян, верно? То же самое с добавлением/удалением узлов.

Я упускаю какую-то фундаментальную вещь? Может это скопление бедняка?


redis hash consistent-hashing
person Sergio Tulentsev    schedule 12.04.2011    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Есть две причины использовать несколько узлов в кластере:

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

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

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

Моя реализация основана на том, что клиент выбирает один из 64-тысячных сегментов для хэша и имеет таблицу, которая сопоставляет этот сегмент с узлом. Изначально все сопоставляется с узлом №1.

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

person Tom Clarkson    schedule 13.04.2011
comment
Это умно! Спасибо за понимание :-) - person Sergio Tulentsev; 13.04.2011
comment
Спустя почти 10 лет это все еще актуально. Всякий раз, когда в любом хранилище данных упоминается согласованное хеширование, они должны простыми словами объяснять, как данные перемещаются в случае выхода из строя/добавления узла. - person Gopal; 27.06.2020