Последовательное хеширование как способ масштабирования записей

Question

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

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

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

Я что-то упустил? Может ли это быть кластер бедняков?

Answer 1

Существует две причины использования нескольких узлов в кластере:

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

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

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

Моя реализация основана на том, чтобы клиент выбрал один из следующих вариантов:64k блоков для хэша и таблицы, которая отображает этот блок на узел.Первоначально все отображаются на узел № 1.

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