Cassandra num_tokens — это действительно num_token_partitions?

Я новичок в Кассандре. Я читаю о параметре num_tokens для виртуальных узлов в файле cassandra.yml. Я не думаю, что совсем понимаю, что это делает или как назначаются токены/разделы. Что здесь происходит на самом деле?

Значение по умолчанию 256 не имеет никакого смысла, если мы действительно говорим о количестве токенов/узла. Является ли num_tokens действительно num_token_partitions/node?

Давайте для начала выберем 2 узла A и B, добавим третий узел C, а затем попробуем объяснить, как все работает. Для начала каждый узел настроен с num_tokens равным 256. Теперь, когда появляются A и B

  1. Сколько токенов получают A и B, присоединяясь к кластеру? Какие диапазоны разделов получают A и B и как это решается?
  2. Какие метаданные хранятся в Cassandra, чтобы узнать, какие диапазоны разделов A и B несут.
  3. Что происходит, когда C присоединяется сейчас? Как Cassandra решает, какие диапазоны разделов получит C? Сколько разделов надо поставить на С?
  4. Как определяется диапазон разделов для A и B, когда C присоединяется?

Кто-нибудь достаточно любезен, чтобы разъяснить подробно для всеобщего блага?


person sat    schedule 15.11.2013    source источник


Ответы (3)


4) Диапазоны разделов определяются путем предоставления каждому узлу диапазона от их доступных токенов до следующего указанного токена.

2) Обмен данными осуществляется посредством сплетен, в которых подробно описывается, какие узлы имеют какие токены. Эти метаданные позволяют каждому узлу узнать, какие узлы отвечают за какие диапазоны. Настройки Keyspace/Replication также изменяют место фактического сохранения данных.

ПРИМЕР: 1) A получает 256 диапазонов B получает 256 диапазонов. Но для простоты давайте дадим им по 2 жетона и представим, что диапазон токенов составляет от 0 до 30.

Данные токены: A 10,15 и B 3,11 Узлы отвечают за следующие диапазоны

(3-9:B)(10:A)(11-14:B)(15-30,0-2:A)

3) Если C присоединяется также с 2 токенами, 20,5 узлов теперь будут нести ответственность за следующие диапазоны

(3-4:B)(5-9:C)(10:A)(11-14:B)(15-19:A)(20-30,0-2:C)

Vnodes являются мощными, потому что теперь, когда C присоединяется к кластеру, он получает свои данные от нескольких узлов (5-9 от B и 20-30,0-2 от A), распределяя нагрузку между этими машинами. В этом игрушечном примере вы можете видеть, что наличие всего 2 токенов позволяет некоторым узлам размещать большую часть данных, в то время как другие почти ничего не получают. По мере увеличения количества Vnodes баланс между узлами увеличивается, поскольку диапазоны все больше и больше делятся случайным образом. При 256 узлах вы, скорее всего, распределяете четный объем данных на каждый узел в кластере.

Для получения дополнительной информации о виртуальных узлах: http://www.datastax.com/dev/blog/virtual-nodes-in-cassandra-1-2

person RussS    schedule 15.11.2013
comment
Действительно хороший ответ. Огромное спасибо! - person sat; 16.11.2013
comment
Почему при запуске диапазоны распределяются неравномерно? Например, что-то вроде этого: (0-7:A)(8-15:B)(16-23:A)(24-30:B). Благодарю вас! - person kn000x; 12.11.2014
comment
Может быть, лучше дать более широкий ответ в новом вопросе. Но основная причина, почему нет, заключается в том, что для равномерного распределения виртуальных узлов требуется знание того, сколько узлов будет в кластере. Кроме того, вы затем возвращаете множество проблем, связанных с наличием одного токена, т. е. трудно увеличить емкость без удвоения узлов, поскольку добавление одного узла вызовет серьезную перебалансировку. - person RussS; 12.11.2014

Также ответ RussS правильный, я думаю, что его трудно понять.

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

Что важно, так это фактор репликации и кольцо, чтобы понять, что это значит.

Репликация работает путем копирования данных узла на два следующих узла. Поэтому, если вы находитесь на узле A, данные, назначенные A, реплицируются на B и C. Данные, назначенные B, реплицируются на C и D и так далее.

Если у вас всего 3 узла и 3 репликации, это не имеет никакого значения.

Если у вас есть 100 узлов, репликация 3 и num_tokens: 1, то ровно 3 узла реплицируют назначенные им данные, и это всегда весь набор данных узла. В нашем примере выше это означает, что все данные, назначенные A, могут быть прочитаны из A, B или C и только из этих трех узлов. Поэтому, если вы пытаетесь часто загружать эти конкретные данные, а остальные не так часто, ваш кластер будет довольно несбалансированным.

При использовании v-узлов данные разбиваются на подразделы. Один компьютер представляет собой множество виртуальных узлов. Таким образом, старый компьютер A теперь может представлять A, D, G, J, M, предполагая num_tokens: 5.

Дальше у нас кольцо. При построении кольца компьютеры будут подключаться друг к другу таким образом, что один и тот же компьютер не подключается сам к себе (A не будет напрямую разговаривать с D и наоборот).

Теперь это означает, что один физический компьютер будет подключен к num_tokens × replication_factor - 1 другим компьютерам. Таким образом, с num_tokens, установленным на 5, и репликацией на 3, вы будете подключены к 10 другим компьютерам. Это означает, что нагрузка будет распределяться между 10 компьютерами вместо 3 (как в противном случае подразумевал бы коэффициент репликации).

Таким образом, с 16 узлами, num_tokens: 256 и replication: 3, это была бы странная установка, поскольку это означало бы, что все узлы соединены друг с другом 512 раз. При этом необходимость изменить num_tokens позже может занять некоторое время, пока кластер приспособится к новому значению. Особенно, если у вас большая установка. Поэтому, если вы планируете иметь большое количество узлов, с самого начала хорошей идеей будет довольно большое num_tokens.

В качестве побочного эффекта он также будет распределять данные между различными таблицами (файлами) на каждом узле. Это также может помочь быстрее находить данные. На самом деле рекомендуется использовать большее количество экземпляров (от 16 до 64) всякий раз, когда вы создаете кластер Elassandra, чтобы упростить поиск.

person Alexis Wilke    schedule 27.12.2018

При 256 узлах вы, скорее всего, распределите четный объем данных на каждый узел в кластере.

Если конечно это не так. Случайное распределение диапазона токенов Vnode не имеет ничего общего со сбалансированной нагрузкой. Сбалансированная нагрузка — это диапазон токенов, РАЗРАБОТАННЫЙ для балансировки, а не угадывания.

Кроме того, есть ошибки в распределении диапазона токенов CASSANDRA-6388 и CASSANDRA-7032, ни одна из которых не исправлена ​​ни в одном кластере, работающем сегодня в производственной среде. Кроме того, есть серьезные проблемы с 256 кластерами VNODE и попыткой их перестроить или создать резервную копию, что буквально невозможно.

Перестроение и восстановление занимают НЕДЕЛИ. И просто попробуйте запустить hadoop против vnodes в продакшене. Откажитесь от сконструированного кластера диапазона токенов для VNODE, радуйтесь, на свой страх и риск.

person Mark J    schedule 22.10.2015