В документации показан способ использования материализованного представления, получаемого из KafkaEngine, отправляющего данные в семейную таблицу * MergeTree.
Это дает преимущество, в случае изменения логики преобразования, отсоединение таблицы, внесение изменений и повторное присоединение.
Однако, если вы не применяете к нему логику (например, преобразование типов полей), имеет ли смысл использовать материализованное представление в качестве пункта назначения, применяя механизм * MergeTree? т.е. удаление части TO table
и отправка запросов в материализованное представление.
Однако я нигде не вижу такого подхода. Я вижу потерю гибкости, но есть ли вообще смысл в таком подходе? и каковы ограничения этого подхода?
Я бы сказал, что это в основном то же самое.
Единственное отличие состоит в том, что без предложения TO <table>
ClickHouse создает таблицу .inner.<mv name>
и сохраняет в ней данные, а не в <table>
. В противном случае поведение такое же AFAIK.
Подводя итог, я полагаю, что лучше использовать предложение TO <table>
, потому что у вас есть лучший контроль над созданной таблицей. Также MV в ClickHouse - это не представления и не таблицы, а триггеры. Поэтому я предпочитаю обращаться с ними именно так и не ожидаю, что они будут использоваться для чтения данных из них.
Я не вижу разницы в двух описанных вами сценариях. Можете ли вы уточнить примеры?