Классическая Кассандра и Координация

Меня интересует координация в классической Cassandra. Я прочитал статью на Facebook, написанную Авинашем Лакшманом и Прашантом Маликом под названием Cassandra — A Децентрализованная структурированная система хранения.

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

Меня интересует последний узел в кольце, тот, который указывает на 1-й узел в кольце, и какой диапазон он координирует?

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

Я пытаюсь визуализировать схему координации так:

введите здесь описание изображения

Вопрос

Не уверен, как каждый узел может быть координатором, если, согласно описанию, каждый узел отвечает за себя и предшествующий ему узел, потому что тогда координаторы будут перекрываться. Так что на моем скриншоте 180 302, 502 и 771 перекрывались бы, если бы они были еще и координаторами.


cassandra consistent-hashing coordination
person Slinky    schedule 10.04.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Координатором на самом деле является тот, кому вы отправляете запрос. Многие стратегии для драйверов сохраняют кольцевые данные и отправляют запрос на одну из реплик, таким образом, если уровень согласованности установлен на ОДИН, он может делать все это на этом одном хосте и устранять задержку другого сетевого перехода из запроса. На самом деле вы можете отправить запрос любому узлу в кольце, и это будет просто означать дополнительный сетевой переход (который может потребоваться в любом случае при использовании более строгой согласованности).

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

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

Кольцо — это визуализация. Фактическая реализация больше похожа на список токенов. Считать:

[(a, 4), (b, 10), (c, 35), (d, 40)]

для диапазона 1-50. Найдите в списке первый токен, который больше вашего токена, а затем продолжайте вниз по списку, пока у вас не будет достаточно реплик, чтобы удовлетворить коэффициент репликации. С RF, равным 3, и токеном, равным 6, вы начинаете с b, так как первый из них больше, а затем включаете следующие 2, чтобы ваши реплики были [b, c, d]. Ни одна реплика не важнее других и не имеет особого контроля над данными (кроме ремонта). «Обтекание» в конце списка просто означает, что токен 41 переходит к [a, b, c].

person Chris Lohfink    schedule 10.04.2018
comment
Спасибо. Я обновил свой вопрос и изображение, чтобы быть более ясным. - person Slinky; 11.04.2018
comment
включен пример, чтобы увидеть, помогает ли это - person Chris Lohfink; 11.04.2018