Проблемы с производительностью Cassandra MaterializedViews

Question

Мы создали кластер кассандры с 9 узлами. Каждый из них оснащен 4 ядрами и 16G RAM. Мы пишем 15-25 миллионов записей с 28 столбцами.

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

CREATE TABLE main_table(
col1 ... col28,
PRIMARY KEY((col1,col2),col_date,col_with_some_seq_number))
WITH CLUSTERING ORDER BY (col_date DESC,col_with_some_seq_number desc) AND  default_time_to_live = 5270400;

CREATE MATERIALIZED VIEW mv_for_main_table AS
SELECT [col1.. col11],
FROM main_table 
WHERE col1 IS NOT NULL AND col2 IS NOT NULL AND col_date IS NOT NULL AND col_with_some_seq_number IS NOT NULL
PRIMARY KEY ((col1),col2, col_date, col_with_some_seq_number)
WITH CLUSTERING ORDER BY (col_date DESC, col_with_some_seq_number DESC, col2 DESC); 

Просто переместите один из ключей раздела в ключ кластеризации в материализованном виде.

Мы загружаем данные из спарк и не модифицируем никакие конфигурации, связанные с кассандрой.

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

Есть ли проблемы с производительностью материализованных представлений? или определение, которое я использовал, не эффективно.?

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

Мы провели достаточное количество тестов, чтобы сделать вывод, что только после включения материализованного представления записи замедляются с огромным запасом и мутации сбрасываются.

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

Answer 1

Одно место для глубокого понимания материализованных взглядов (MV): http://www.doanduyhai.com/blog/?p=1930

Существует блокировка раздела базовой таблицы при наличии MV. Эта локальная блокировка имеет свою стоимость (см. В моем блоге)

У меня также есть еще одно замечание относительно размера вашего оборудования: 4CPU ниже официальной рекомендации, которая составляет 8 процессоров: http://cassandra.apache.org/doc/latest/operating/hardware.html

Запись рабочей нагрузки в Cassandra связана с процессором. В вашем случае ваш процессор также используется Spark, что может объяснить ваше узкое место.

Пожалуйста, оставьте здесь снимок экрана dstat а также htop

Answer 2

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

На мой взгляд, проблема производительности связана с перегрузкой одного конкретного узла. В самом деле, когда вы понижаете один из столбцов PARTITION KEY до столбца CLUSTERING KEY, предполагая, что один и тот же шаблон приема данных (это предположение явно выполняется, поскольку каждая запись "отражается" в другой таблице), вы собираетесь создавать горячие точки, потому что больше данных, как правило, лежат в одном разделе. Это приводит к более длительному сжатию и восстановлению чтения и большей нагрузке на кластер в целом (например, потому что каждый узел должен сортировать больше данных для каждого раздела).