Ребаланс Кассандры

Я использую Apache Cassandra 2.1.1, и при использовании состояния nodetool Нагрузка для одного из моих узлов составляет примерно половину размера двух других, в то время как Собственность почти одинакова на всех узлах. Я новичок в Кассандре и не знаю, стоит ли мне беспокоиться об этом или нет. Я пытался использовать восстановление и очистку после перезапуска всех узлов, но они все равно выглядят несбалансированными. Я использую GossipingPropertyFileSnitch с каждым узлом, сконфигурированным как dc=DC1 и стеллажом=RAC1, указанным в cassandra-rackdc.properties. Я также использую Murmur3Partitioner с NetworkTopologyStrategy, где мое пространство ключей определено как

CREATE KEYSPACE awl WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': '2'}  AND durable_writes = true;

Я считаю, что проблема связана с пространством ключей awl, поскольку размер папки data/awl совпадает с размером, указанным в статусе nodetool. Мой вывод для состояния nodetool ниже. Любая помощь приветствуется.

Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID                               Rack
UN  10.1.1.152  3.56 GB    256     68.4%             d42945cc-59eb-41de-9872-1fa252762797  RAC1
UN  10.1.1.153  6.8 GB     256     67.2%             065c471d-5025-4bf1-854d-52d579f2a6d3  RAC1
UN  10.1.1.154  6.31 GB    256     64.4%             46f05522-29cc-491c-ab65-334b205fc415  RAC1

load-balancing cassandra-2.0
person Rick Chronister    schedule 02.01.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

person Jim Meyer    schedule 04.01.2015
comment
Это интересно; Я даже не рассматривал свой ключ раздела. Я использую кольцо Cassandra с VNodes с определенным первичным ключом: PRIMARY KEY (mac, logtime). Таким образом, мой ключ раздела будет MAC-адресом, который определяет, на каком узле будут правильно храниться данные? В настоящее время мы храним информацию только о 18 разных mac-адресах в целях тестирования. В будущем у нас должны быть тысячи MAC-адресов, о которых мы храним информацию. Как вы думаете, хранение большего количества адресов Mac в конечном итоге приведет к более сбалансированному кластеру? - person Rick Chronister; 05.01.2015
comment
Да, 18 — это очень низкая мощность для ключа раздела, учитывая диапазон всех возможных MAC-адресов, так что это, вероятно, причина дисбаланса ваших данных. У вас все равно может возникнуть проблема с тысячами MAC-адресов, если они предназначены для машин одного производителя, поскольку все они могут иметь одинаковые MAC-адреса, а не действительно случайные. При необходимости вы можете увеличить мощность ключа вашего раздела, используя составной ключ раздела (т. е. соединить MAC-адрес с каким-либо другим значением, таким как почтовый индекс или что-то еще, чтобы добавить больше случайности для распространения данных на ваших узлах). - person Jim Meyer; 06.01.2015