Используйте materialized views

Страница с описанием materialized views

ClickHouse поддерживает два типа materialized views: incremental и refreshable. Хотя оба типа предназначены для ускорения запросов за счет предварительного вычисления и хранения результатов, они существенно различаются тем, как и когда выполняются лежащие в их основе запросы, для каких рабочих нагрузок они подходят и как обеспечивается актуальность данных.

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

Incremental materialized views обновляются в реальном времени. Когда новые данные вставляются в исходную таблицу, ClickHouse автоматически применяет запрос materialized view к новому блоку данных и записывает результаты в отдельную целевую таблицу. Со временем ClickHouse объединяет эти частичные результаты, формируя полное и актуальное представление. Такой подход очень эффективен, поскольку переносит вычислительные затраты на момент вставки и обрабатывает только новые данные. В результате запросы SELECT к целевой таблице выполняются быстро и с минимальными затратами ресурсов. Incremental views поддерживают все функции агрегации и хорошо масштабируются — вплоть до PB данных, — поскольку каждый запрос работает с небольшим свежим подмножеством вставляемого набора данных.

Refreshable materialized views, напротив, обновляются по расписанию. Эти views периодически заново выполняют полный запрос и перезаписывают результат в целевой таблице. Это похоже на materialized views в традиционных OLTP-базах данных, таких как Postgres.

Выбор между incremental и refreshable materialized views во многом зависит от характера запроса, частоты изменения данных и того, должны ли обновления view отражать каждую строку по мере ее вставки или допустимо периодическое обновление. Понимание этих компромиссов — ключ к проектированию производительных и масштабируемых materialized views в ClickHouse.

​

Когда использовать incremental materialized views

Incremental materialized views обычно предпочтительнее, поскольку они автоматически обновляются в реальном времени при поступлении новых данных в исходные таблицы. Они поддерживают все функции агрегации и особенно эффективны для агрегаций по одной таблице. Благодаря инкрементальному вычислению результатов во время вставки запросы выполняются по значительно меньшим подмножествам данных, что позволяет этим представлениям легко масштабироваться вплоть до PB данных. В большинстве случаев они не оказывают заметного влияния на общую производительность кластера.

Используйте incremental materialized views, когда:

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

Примеры incremental materialized views см. здесь.

​

Когда использовать refreshable materialized views

Refreshable materialized views выполняют запросы периодически, а не инкрементально, сохраняя результирующий набор для быстрого доступа.

Они особенно полезны, когда критически важна производительность запросов (например, задержка менее миллисекунды) и допустимы слегка устаревшие результаты. Поскольку запрос каждый раз выполняется полностью, refreshable views лучше всего подходят для запросов, которые либо вычисляются относительно быстро, либо запускаются через достаточно большие интервалы (например, раз в час), — например, для кэширования результатов “top N” или справочных таблиц.

Частоту выполнения следует подбирать тщательно, чтобы избежать избыточной нагрузки на систему. Очень сложные запросы, потребляющие значительные ресурсы, следует планировать с осторожностью: они могут ухудшить общую производительность кластера, влияя на кэши и расходуя CPU и память. Запрос должен выполняться достаточно быстро по сравнению с интервалом обновления, чтобы не перегружать кластер. Например, не следует обновлять представление каждые 10 секунд, если самому запросу на вычисление требуется не менее 10 секунд.

​

Итоги

Итак, используйте refreshable materialized views, когда:

• Вам нужны кэшированные результаты запросов, доступные мгновенно, и допустима небольшая задержка в актуальности данных.
• Вам нужен top N для результирующего набора запроса.
• Размер результирующего набора со временем не растет без ограничений. Иначе производительность целевого представления будет снижаться.
• Вы выполняете сложные JOIN или денормализацию с участием нескольких таблиц, где обновления нужны при изменении любой исходной таблицы.
• Вы строите батч-процессы, задачи денормализации или создаете зависимости между представлениями, аналогичные DAG в DBT.

Примеры refreshable materialized views см. здесь.

​

Режимы APPEND и REPLACE

Refreshable materialized views поддерживают два режима записи данных в целевую таблицу: APPEND и REPLACE. Эти режимы определяют, как результат запроса представления записывается при его обновлении.

REPLACE — режим по умолчанию. При каждом обновлении представления предыдущее содержимое целевой таблицы полностью перезаписывается последним результатом запроса. Это подходит для сценариев, в которых представление всегда должно отражать актуальное состояние, например для кэширования результирующего набора.

APPEND, напротив, позволяет добавлять новые строки в конец целевой таблицы вместо замены её содержимого. Это открывает дополнительные сценарии использования, например сохранение периодических снимков. APPEND особенно полезен, когда каждое обновление соответствует отдельному моменту времени или когда требуется накапливать результаты за прошлые периоды.

Выбирайте режим APPEND, когда:

• Вы хотите сохранять историю предыдущих обновлений.
• Вы создаёте периодические снимки или отчёты.
• Вам нужно постепенно накапливать обновлённые результаты с течением времени.

Выбирайте режим REPLACE, когда:

• Вам нужен только самый актуальный результат.
• Устаревшие данные должны полностью отбрасываться.
• Представление отражает текущее состояние или используется для поиска по ключу.

Пример применения функциональности APPEND можно найти при построении Medallion architecture.