Равномерное распределение данных в Кассандре

Question

Я новичок в Кассандре, и я застрял в одной точке.

Предположим, у меня есть кластер из 5 узлов с RF = 1 (для простоты)

Token Ranges 
==============
N1 : 1-100
N2 : 101-200
N3 : 201-300
N4 : 301-400
N5 : 401-500

У меня есть пространство ключей с 10 ключами разделения:

ID (PartitionKey) | Name
------------------------
1                 Joe
2                 Sarah
3                 Eric
4                 Lisa
5                 Kate
6                 Agnus
7                 Lily
8                 Angela
9                 Rodger
10                Chris

10 ключей разделения ==> подразумевает ==> 10 га sh значения

partitionkey ==> token generated
=================================
1                 289 (goes on N3)
2                 56 (goes on N1)
3                 78 (goes on N1)
4                 499 (goes on N5)
5                 376 (goes on N4)
6                 276 (goes on N3)
7                 2 (goes on N1)
8                 34 (goes on N1)
9                 190 (goes on N2)
10                68 (goes on N1)

Если это так, то :

N1 has the partition keys : 2,3,7,8,10
N2 has the partition keys : 9
N3 has the partition keys : 1,6
N4 has the partition keys : 5
N5 has the partition keys : 4

Итак, мы видим, что N1 загружен по сравнению с другими, другими узлами (согласно моему пониманию).

Пожалуйста, помогите мне понять, как данные равномерно распределяются в Cassandra, относительно Разделители и последовательное хеширование.

Answer 1

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

Например, в кластере из 10 узлов выбор состояния определенной страны c в качестве ключа раздела может быть не идеальным, поскольку существует очень высокая вероятность создания горячих точек, особенно когда само количество записей может не быть даже в разных штатах. Принимая во внимание, что выбор чего-то вроде почтового индекса может быть лучше или даже лучше, чем, например, имя клиента или номер заказа. Вы можете изучить наличие составного ключа раздела, если это поможет вашему варианту использования.

Answer 2

В том, что вы здесь публикуете, есть доля правды, в основном потому, что распределение данных с помощью хеширования сложно с меньшими числами. Но давайте добавим одно предположение ... Допустим, мы используем vNodes с num_tokens: 4*, установленным в cassandra.yaml.

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

  Token Ranges
  ==============
  N1 :    1-25, 126-150, 251-275, 376-400
  N2 :   26-50, 151-175, 276-300, 401-425
  N3 :   51-75, 176-200, 301-325, 426-450
  N4 :  76-100, 201-225, 326-350, 451-475
  N5 : 101-125, 226-250, 351-375, 476-500

Учитывая это распределение, ваши ключи теперь расположены следующим образом:

  N1 has the partition keys : 5, 7
  N2 has the partition keys : 1, 6, 8
  N3 has the partition keys : 2, 9, 10
  N4 has the partition keys : 3
  N5 has the partition keys : 4

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

Как и во всех наборах данных, числа становятся лучше с увеличением объема данных. Я уверен, что вы увидите лучшее распределение с 1000 ключами разделов по сравнению с 10.

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

* Примечание. Использование vNodes с num_tokens: 4 многими экспертами Cassandra считается оптимальная настройка производства. С новым алгоритмом по умолчанию 256 токенов довольно высоки.

Answer 3

В Cassandra данные распределяются на основе алгоритма разделения и хеширования. У нас есть много других параметров для настройки распределения и репликации данных, таких как коэффициент репликации, стратегия репликации, Snitch et c. Ниже приведен стандартный рекомендуемый документ. https://docs.datastax.com/en/cassandra-oss/2.2/cassandra/architecture/archDataDistributeAbout.html