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

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

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

Анти-шаблон хранения 10x​

Истинная проблема в производстве: "У нас было материализованное представление. Объем таблицы сырых логов составлял около 20 гигабайт, но объем представления из этой таблицы логов взорвался до 190 гигабайт, что почти в 10 раз больше размера таблицы сырого лога. Это произошло потому, что мы создавали одну строку на каждый атрибут, а каждый лог может иметь 10 атрибутов."

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

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

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

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

  • Низкое отношение агрегации (<10%) = Хорошее MV, значительное сжатие
  • Высокое отношение агрегации (>70%) = Плохое MV, риск взрыва хранилища
  • Множитель хранения = На сколько больше/меньше будет ваше MV
-- Replace with your actual table and columns
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;

-- If aggregation_ratio > 70%, reconsider your MV design
-- If aggregation_ratio < 10%, you'll get good compression

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

Признаки, на которые стоит обратить внимание:

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

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

Видео-источники​

  • ClickHouse на CommonRoom - Кирилл Сапчук - Источник исследования "слишком восторженным в отношении материализованных представлений" и случая "20ГБ→190ГБ взрыв"