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

Использование материализованных представлений

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

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

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

Материализованные представления

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

Схема обновляемого материализованного представления

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

Когда использовать инкрементные материализованные представления

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

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

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

Примеры инкрементных материализованных представлений см. здесь.

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

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

Они наиболее полезны, когда производительность запроса критична (например, требуются субмиллисекундные задержки), а небольшая «залежалость» результатов допустима. Поскольку запрос каждый раз выполняется целиком, обновляемые представления лучше всего подходят для запросов, которые либо относительно быстро считаются, либо могут выполняться с редкой периодичностью (например, раз в час), таких как кеширование результатов вида «top N» или таблиц соответствий (lookup-таблиц).

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

Резюме

Подводя итог, используйте обновляемые материализованные представления, когда:

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

Примеры обновляемых материализованных представлений см. здесь.

Режимы APPEND и REPLACE

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

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

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

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

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

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

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

Пользователи могут применить режим APPEND при построении архитектуры Medallion.