Как кассандра находит node, который содержит данные?

Я прочитал довольно много статей и много вопросов/ответов о SO о Cassandra, но я до сих пор не могу понять, как Cassandra решает, к какому node (s) следует при чтении данных.

Во-первых, некоторые предположения о мнимом кластере:

Стратегия репликации = простая
Использование Random Partitioner
Кластер из 10 узлов
Коэффициент репликации 5

Здесь мое понимание того, как пишет работа, основанная на различных статьях Datastax и других сообщениях в блоге, которые я читал:

Клиент отправляет данные в случайный node
"random" node определяется на основе хеша MD5 первичного ключа.
Данные записываются в файл commit_log и memtable, а затем разворачиваются 4 раза (с RF = 5).
Затем выбираются 4 следующих узла в кольце, и данные сохраняются в них.

До сих пор так хорошо.

Теперь возникает вопрос, когда клиент отправляет в кластер запрос на чтение (скажем, CL = 3), как Кассандра знает, какие узлы (5 из 10 как худший сценарий) ему нужно связаться, чтобы получить это данные? Разумеется, это не будет для всех 10 узлов, поскольку это будет неэффективно.

Правильно ли я полагаю, что Cassandra снова выполнит хэш MD5 первичного ключа (запроса) и выберет node в соответствии с этим, а затем ходит по кольцу?

Также, как работает сетевая топология? если у меня несколько центров обработки данных, как Кассандра знает, какие узлы в каждой DC/Rack содержат данные? Из того, что я понимаю, только первый node является очевидным (поскольку хэш первичного ключа привел к тому, что node явно).

Извините, если вопрос не очень ясен и, пожалуйста, добавьте комментарий, если вам нужна более подробная информация о моем вопросе.

Большое спасибо,

Ответ 1

Клиент отправляет данные в случайный node

Это может показаться таким, но на самом деле есть неслучайный способ, с которым ваш драйвер выбирает node. Этот node называется "координатором node" и обычно выбирается исходя из того, что имеет наименьшее (ближайшее) "сетевое расстояние". Запросы клиентов действительно могут быть отправлены на любой node, и сначала они будут отправлены на узлы, о которых знает ваш драйвер. Но как только он связывает и понимает топологию вашего кластера, он может измениться на "более близкого" координатора.

Узлы в вашем кластере обмениваются информацией топологии друг с другом с помощью протокола сплетен. Сплетник запускается каждую секунду и гарантирует, что все узлы будут поддерживаться с данными из Snitch, которые вы настроили. Snitch отслеживает, какие дата-центры и стойки принадлежат каждому node.

Таким образом, координатор node также имеет данные о том, какие узлы отвечают за каждый диапазон токенов. Вы можете увидеть эту информацию, запустив nodetool ring из командной строки. Хотя, если вы используете vnodes, это будет сложнее выяснить, так как данные на всех 256 (по умолчанию) виртуальных узлах будут быстро мигать на экране.

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

SELECT token(firstname),firstname, id, lastname 
FROM usersbyfirstname  WHERE firstname='Mal';

... возвращает эту строку:

 token(firstname)     | firstname | id | lastname
----------------------+-----------+----+-----------
  4016264465811926804 |       Mal |  2 |  Reynolds

Запустив nodetool ring, я вижу, какой node отвечает за этот токен:

192.168.1.22  rack1       Up     Normal  348.31 KB   3976595151390728557                         
192.168.1.22  rack1       Up     Normal  348.31 KB   4142666302960897745

Или даже проще, я могу использовать nodetool getendpoints, чтобы увидеть эти данные:

$ nodetool getendpoints stackoverflow usersbyfirstname Mal
Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar 
192.168.1.22

Для получения дополнительной информации ознакомьтесь с некоторыми из приведенных выше элементов или попробуйте запустить nodetool gossipinfo.

Ответ 2

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

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

Когда приходит запрос на чтение, контакт node становится координатором для чтения. Он вычислит, какие узлы имеют реплики для запрошенного раздела, а затем выберите необходимое количество узлов для соответствия уровню согласованности. Затем он отправит запросы этим узлам и дождитесь их ответов и объединит результаты на основе временных меток столбцов, прежде чем отправить результат обратно клиенту.

Ответ 3

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

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

В случае нескольких центров обработки данных все ключи будут отображаться на всех контроллерах домена на тот же самый токен, определенный секционированием. Кассандра попытается написать каждому DC и каждому реплику DC.