Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs
49.6kGet Started

Уроки — materialized views

View as MarkdownEdit this pageReport an issueSet up docs MCP

Это руководство входит в подборку выводов и наблюдений, собранных на встречах сообщества. Больше практических решений и полезных наблюдений можно найти, перейдя к материалам по конкретным проблемам. Слишком много частей тормозят вашу базу данных? Ознакомьтесь с руководством сообщества 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 для отслеживания изменений в длительности запросов.

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

Navigation