Кассандра вводит реплики

Question

Настройка контекста: Cassandra в настоящее время реализует vnodes.256 по умолчанию, который настраивается в файле cassandra.yaml. Vnodes, как я понимаю, являются токен-диапазонами / хэш-диапазонами.Например.(x ... y], где y - номер токена vnode. Каждому физическому узлу в Cassandra назначены случайные 256 токенов, и каждый из этих токенов является граничным значением диапазона хеша / токена. Назначенные токены находятся в пределахдиапазон от 2 ^ -63 до 2 ^ 63-1 (диапазон хеш-чисел, который может генерировать murmur3 с разделителем). Пока все хорошо.

Вопрос: 1. Является ли диапазон токенов (vnode) является фиксированным диапазоном. После установки этот диапазон токенов будет скопирован на другие узлы Cassandra для удовлетворения фактору репликации, например диапазон токенов (vnode), являющийся фундаментальным фрагментом данных (токенов), которые объединяются вместе. Только в случае начальной загрузкинового узла в кластере, этот диапазон токенов (vnode) может разойтись, чтобы быть назначенным другому узлу.

На последнем предложении (скажем, последнее предложение верно).Тогда vnode должен содержать только токены, которые принадлежат данному пространству ключей.Потому что каждое пространство ключей (контейнер семейства столбцов / таблиц) имеет определенную стратегию репликации и коэффициент репликации.И весьма вероятно, что коэффициент репликации пространств ключей в кластере Cassandra будет различным.Рассмотрим пример.Пространство ключей "system_schema" имеет RF 1, тогда как я создал пространство ключей "test_ks" с RF 3. Если строка пространства ключей system_schema имеет токен номер 2 (скажем), а строка моего test_ks имеет токен номер 5 (скажем).эти 2 токена не могут быть помещены в один и тот же диапазон токенов (vnode).Если vnode - это согласованный кусок диапазонов токенов, скажем, токены 2 и 5 принадлежат vnode с токеном № 10. поэтому vnode 10 должен быть размещен на 3 разных физических узлах, чтобы удовлетворить RF = 3 для test_ks, но нам не нужно размещать токен2 на 3 разных узлах, чей RF должен быть 1.

Правильно ли это утверждение, что vnode выделен только для данного пространства ключей?который сводится к 256 токенам на физическом узле ... 20 (скажем) vnodes в настоящее время принадлежат "системному" пространству клавиш, 80 vnodes (скажем) принадлежат test_ks.

Опять-таки, исходя из вышеизложенного, это означает, что каждый узел должен иметь информацию о ключ-виртуальных узлах, доступных в данный момент в кластере.Таким образом, когда для Keyspace приходит новая запись, узел-координатор находит все vnode в кластере для этого пространства ключей и назначает новой строке номер токена, который попадает в диапазон токенов этих пространств ключей.В таком случае я могу знать, сколько vnode в настоящее время принадлежит пространству ключей во всем кластере / или в данном узле.

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

https://www.scribd.com/document/253239514/Virtual-Nodes-Strategies-for-Apache-Cassandra

https://www.youtube.com/watch?v=GddZ3pXiDys&t=11s

Заранее спасибо

Answer 1

Не существует фиксированного диапазона токенов, токены генерируются случайным образом. Это одна из причин того, что vnodes были реализованы - идея заключается в том, что если имеется больше токенов, более вероятно, что результирующие диапазоны токенов будут более равномерно распределены по узлам.

Генерация токенов была недавно улучшена в 3.0, что позволило Cassandra размещать новые токены немного более разумно (см. CASSANDRA-7032 ). Вы также можете вручную настроить токены (см. initial_token ), хотя может быть сложно сохранить баланс, когда наступит время расширения кластера, если вы не планируете удвоить количество узлов.

Общее количество токенов в кластере - это количество узлов в кластере, умноженное на количество vnodes на узел.

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

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

Например, предположим, что у нас есть 3 узла, каждый из которых имеет один токен: node1: 10, node2: 20 & node3: 30. Если мы записываем запись, чей ключ раздела хэширует в 22, в пространство ключей с RF3, то первая копия отправляется на узел 2, вторая - на узел 3, а третья - на узел 1. Обратите внимание, что каждая реплика одинаково действительна - в «первой» реплике нет ничего особенного, кроме того, что она хранится в «первом» узле реплики.

Vnodes не изменяют этот процесс, они просто разделяют диапазоны токенов каждого узла, позволяя каждому узлу иметь более одного токена. Например, если в нашем кластере теперь есть 2 vnode для каждого узла, он может выглядеть следующим образом: node1: 10, 25, node2: 20, 3 & node3: 30, 21. Теперь наша запись, хэшированная до 22, переходит к node3 (поскольку ей принадлежит диапазон от 21-24), а копии переходят к node1 и node2.