Перейти к основному содержанию
Перейти к основному содержанию

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

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

Антипаттерн хранения с 10-кратным ростом​

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

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

Проверка состояния материализованного представления в продакшене​

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

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

  • Низкий коэффициент агрегации (<10%) = хорошее материализованное представление, значительное сжатие
  • Высокий коэффициент агрегации (>70%) = плохое материализованное представление, риск взрывного роста объёма хранения
  • Множитель хранения = во сколько раз больше/меньше будет занимать место ваше материализованное представление
-- Замените на вашу фактическую таблицу и столбцы
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%, пересмотрите схему вашего материализованного представления
-- Если aggregation_ratio < 10%, вы получите хорошую степень сжатия

Когда материализованные представления становятся проблемой​

Предупреждающие признаки, за которыми стоит следить:

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

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

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

  • ClickHouse at CommonRoom - Kirill Sapchuk — источник кейса о «чрезмерном энтузиазме вокруг материализованных представлений» и «раздувании объёма данных с 20 GB до 190 GB»