Балансировка нагрузки Cassandra с помощью упорядоченного разделителя?

Question

Итак, я вижу здесь, что у Cassandra нет автоматической балансировки нагрузки, которая появляется в поле зрения при использовании упорядоченного разделителя (определенный общий диапазон значений группы строк будет храниться на относительно небольшом числе машин, которые затем будут обслуживать большинство запросы).
What's The Best Practice In Designing A Cassandra Data Model?

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

Answer 1

Я думаю, что этот вопрос лучше всего использовать в списке рассылки cassandra-user; вот где люди.

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

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

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

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

я буду использовать термин «раздел» здесь для обозначения части ключа вы не хотите, чтобы диапазон сканирования

function makeWholeKey(partition, key) { 
    return concat(make_hash(partition), partition, key); 
} 

Теперь, если вы хотите, чтобы диапазон сканирования клавиш в пределах данного раздела , вы можете варьировать сканирование между makeWholeKey (p, start) и makeWholeKey (p, end)

Но если вы хотите отсканировать разделы, вам не повезло.

Но вы можете сделать свои узлы маркерами, которые равномерно распределены по диапазону вывода make_hash(), и вы получите равномерно распределенные данные (при условии, что у вас есть разделы ENOUGH, которые не все объединяются на одном или два значения хеширования)

Answer 2

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

Это описано в http://wiki.apache.org/cassandra/Operations

Answer 3

разбиения данных по кластеру контролируется параметром partitioner в cassandra.yaml:

partitioner: org.apache.cassandra.dht.Murmur3Partitioner 

Использования Murmur3Partitioner будет генерировать случайные хэш-код для строки ключа и выполнять выравнивание нагрузки.

С Cassandra 2.0 вы можете хранить несколько токенов (256) на одном сервере, что также поможет в балансировке нагрузки. Не рекомендуется использовать OrderPreservingPartitioner и устарела.