Уроки — materialized views

Реальные примеры materialized views, проблемы и решения

Это руководство входит в подборку выводов и наблюдений, собранных на встречах сообщества. Больше практических решений и полезных наблюдений можно найти, перейдя к материалам по конкретным проблемам. Слишком много частей тормозят вашу базу данных? Ознакомьтесь с руководством сообщества Too Many Parts. Узнайте больше о Materialized Views.

​

Антипаттерн 10x в хранении

Реальная проблема в продакшене: “У нас была materialized view. Таблица сырых логов занимала около 20 ГБ, но materialized view, построенная на этой таблице логов, разрослась до 190 ГБ — почти в 10 раз больше исходной таблицы. Это произошло потому, что мы создавали одну строку на каждый атрибут, а у каждого лога может быть по 10 атрибутов.”

Правило: Если ваш GROUP BY создает больше строк, чем убирает, значит, вы строите дорогой индекс, а не materialized view.

​

Проверка состояния materialized view в продакшене

Этот запрос помогает заранее оценить, будет ли materialized view сжимать данные или, наоборот, раздувать их, прежде чем вы её создадите. Выполните его для своей реальной таблицы и столбцов, чтобы избежать сценария «раздувания до 190 ГБ».

Что он показывает:

• Низкая степень агрегации (<10%) = Хорошая MV, значительное сжатие
• Высокая степень агрегации (>70%) = Плохая MV, риск резкого роста объёма хранилища
• Множитель хранилища = Насколько больше или меньше будет ваша MV

-- Замените на вашу реальную таблицу и столбцы
SELECT 
    count() as total_rows,
    uniq(your_group_by_columns) as unique_combinations,
    round(uniq(your_group_by_columns) / count() * 100, 2) as aggregation_ratio
FROM your_table
WHERE your_filter_conditions;

-- Если aggregation_ratio > 70%, пересмотрите дизайн вашего MV
-- Если aggregation_ratio < 10%, вы получите хорошее сжатие

​

Когда materialized views становятся проблемой

Тревожные признаки, за которыми стоит следить:

• Увеличивается задержка при вставке (запросы, которые раньше занимали 10 мс, теперь занимают 100+ мс)
• Ошибки “Too many parts” появляются чаще
• Пики загрузки CPU во время операций вставки
• Появляются тайм-ауты при вставке, которых раньше не было

Вы можете сравнить производительность вставки до и после добавления MV, используя system.query_log для отслеживания изменений в длительности запросов.

​

Источники видео

• ClickHouse at CommonRoom - Kirill Sapchuk - Видео с разбором кейса о «чрезмерном увлечении materialized view» и «взрыве 20GB→190GB»