Как узлы выполнять операции чтения одновременно?

Question

Я экспериментирую с Cassandra 3.0.2 на кластере из 6 узлов и обнаружил «неинтуитивные» шаблоны считывания/масштабирования.

Запрос:

select count(*) from dvds 

где DVD имеет 280K записей.

С настройками по умолчанию vnode (num_tokens: 256) я обнаружил, что увеличение количества узлов от 1 до 2 улучшает производительность чтения примерно на 35%, но каждый дополнительный узел за пределами 2 узлов снижает производительность примерно на 30%.

С отключением vnode (num_tokens: 1 и initial_token-s вручную) кластер из 6 узлов работает примерно на 35% лучше, чем с num_tokens: 256, но следующий шаблон явно наблюдается: потребление процессора координатором узла составляет либо около 50% (от общей емкости ядра ЦП), либо около 110-120%, тогда как другие узлы потребляют либо около 0%, либо 60-70% в процентах от одного ядра. Неинтуитивная часть такова: когда один узел занят, остальные узлы простаивают. (Когда потребление процессора координатором составляет 110-120%, все остальные узлы довольно простаивают. Когда процессор координатора составляет 50%, один из других узлов занят.)

Самая сильная гипотеза, которую я мог бы придумать заключалось в том, что кластер неспособен обрабатывать сетевой трафик, но сетевой трафик координатора (где, я полагаю, проблема с масштабируемостью сети больше всего пострадала), по-видимому, не превышала 1 Мбит/с в любой момент времени. (Пропускная способность сетевых интерфейсов на узлах составляет 10/100 Мбит/с.) Кроме того, с проблемой масштабируемости сети я ожидал бы, что установка «num_tokens: 1» будет отображать изначально высокую загрузку ЦП на всех узлах (за исключением координатора) - или, по крайней мере, с равномерно распределенной одновременной нагрузкой.

Пожалуйста, может кто-нибудь пролить свет на это?

Answer 1

счет (*) имеет свое место, но очень дорого. Координатор по существу должен вытащить все из всех узлов, объединить и посчитать их. Единственное, что он предоставляет для «чтения всего» и подсчета их локально, - это снижение нагрузки на сеть между координатором и вашим приложением.

Если вам нужна эта метрика регулярно, я бы рекомендовал использовать счетчик или lwt, чтобы счетчик выполнял одну операцию чтения (создайте модель данных вокруг запросов, а не абстракции данных). Если понадобится это один раз, или редко, hasoop/spark - отличный вариант. Также вы можете получить достойную оценку из метрики EstimatedPartitionSize (за каждый узел) в зависимости от вашей модели данных.