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

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

Резюме ключевых различий

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

Аспект	Материализованные представления	Проекции
Хранение данных и расположение	Хранят свои результаты в отдельной, явной целевой таблице, действуя как триггеры вставки при вставке в исходную таблицу.	Проекции создают оптимизированные макеты данных, которые физически хранятся вместе с данными основной таблицы и невидимы для пользователя.
Механизм обновления	Работают синхронно при INSERT в исходную таблицу (для инкрементных материализованных представлений). Примечание: их также можно планировать с использованием обновляемых материализованных представлений.	Асинхронные обновления происходят в фоновом режиме при INSERT в основную таблицу.
Взаимодействие с запросами	Работа с материализованными представлениями требует выполнения запросов к целевой таблице напрямую, что означает, что пользователи должны быть осведомлены о наличии материализованных представлений при написании запросов.	Проекции автоматически выбираются оптимизатором запросов ClickHouse и являются прозрачными в том смысле, что пользователю не нужно изменять свои запросы к таблице с проекцией, чтобы использовать её. Начиная с версии 25.6 также можно фильтровать по нескольким проекциям.
Обработка UPDATE / DELETE	Не реагируют автоматически на операции UPDATE или DELETE в исходной таблице, так как материализованные представления не имеют информации об исходной таблице, действуя только как триггеры вставки в исходную таблицу. Это может привести к потенциальному устареванию данных между исходными и целевыми таблицами и требует обходных путей или периодического полного обновления (с помощью обновляемого материализованного представления).	По умолчанию не совместимы с DELETED строками (особенно легковесными удалениями). Можно включить совместимость с помощью lightweight_mutation_projection_mode (v24.7+).
Поддержка JOIN	Да. Обновляемые материализованные представления могут использоваться для сложной денормализации. Инкрементные материализованные представления срабатывают только на вставках в крайние таблицы слева.	Нет. В определениях проекций операции JOIN не поддерживаются для фильтрации материализованных данных.
Условие WHERE в определении	Да. Включение условий WHERE возможно для фильтрации данных перед материализацией.	Нет. Условия WHERE не поддерживаются в определениях проекций для фильтрации материализованных данных.
Возможности цепочки	Да, целевая таблица одного материализованного представления может быть источником для другого материализованного представления, что позволяет создавать многоступенчатые конвейеры.	Нет. Проекции не могут быть связаны в цепочку.
Применимые движки таблиц	Могут использоваться с различными движками исходных таблиц, но целевые таблицы обычно относятся к семейству MergeTree.	Доступны только для движков таблиц семейства MergeTree.
Обработка ошибок	Ошибка во время вставки данных означает, что данные теряются в целевой таблице, что приводит к потенциальной несогласованности.	Ошибки обрабатываются тихо в фоновом режиме. Запросы могут беспрепятственно смешивать материализованные и нематериализованные части.
Операционные затраты	Требует явного создания целевой таблицы и часто ручного заполнения. Управление согласованностью с UPDATE/DELETE увеличивает сложность.	Проекции автоматически поддерживаются и синхронизируются, что, как правило, снижает операционные нагрузки.
Совместимость с FINAL запросами	Обычно совместимы, но часто требуют GROUP BY в целевой таблице.	Не работают с FINAL запросами.
Ленивое материализованиe	Да.	Следите за проблемами совместимости проекций при использовании функций материализации. Возможно, вам потребуется установить query_plan_optimize_lazy_materialization = false
Параллельные реплики	Да.	Нет.
optimize_read_in_order	Да.	Да.
Легковесные обновления и удаления	Да.	Нет.

Сравнение материализованных представлений и проекций

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

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

• Работа с реальным ETL и многоступенчатыми конвейерами данных: Необходимо выполнять сложные преобразования, агрегации или маршрутизацию данных по мере их поступления, возможно, через несколько этапов, связывая представления.
• Требуется сложная денормализация: Необходимо предварительно объединить данные из нескольких источников (таблиц, подзапросов или словарей) в одну таблицу, оптимизированную для запросов, особенно если периодические полные обновления с использованием обновляемых материализованных представлений приемлемы.
• Вам нужен явный контроль схемы: Необходима отдельная, отличная целевая таблица с собственной схемой и движком для предварительно вычисленных результатов, что предоставляет больше гибкости для моделирования данных.
• Вы хотите фильтровать при приеме: Необходимо фильтровать данные до их материализации, снижая объем данных, записываемых в целевую таблицу.

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

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

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

Когда выбирать проекции

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

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

Когда избегать использование проекций

Вы должны рассмотреть возможность избегать использование проекций, когда:

• Требуются сложные преобразования данных или многоступенчатый ETL: Проекции не поддерживают операции JOIN в своих определениях, не могут быть изменены для построения многоступенчатых конвейеров и не могут обрабатывать некоторые функции SQL, такие как оконные функции или сложные операторы CASE. Поэтому они не подходят для сложных преобразований данных.
• Необходимо явное фильтрование материализованных данных: Проекции не поддерживают условия WHERE в своем определении для фильтрации данных, которые передаются в материализацию в саму проекцию.
• Используются движки таблиц, отличные от MergeTree: Проекции доступны исключительно для таблиц, использующих семейство движков MergeTree.
• Если необходимы FINAL запросы: Проекции не работают с FINAL запросами, которые иногда используются для дедупликации.
• Вам нужны параллельные реплики, так как они не поддерживаются с проекциями.

Резюме

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

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

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