Clickhouse Kafka Engine: материализованный Посмотреть преимущества

В документации показан способ использования материализованного представления, получаемого из KafkaEngine, отправляющего данные в семейную таблицу * MergeTree.

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

Однако, если вы не применяете к нему логику (например, преобразование типов полей), имеет ли смысл использовать материализованное представление в качестве пункта назначения, применяя механизм * MergeTree? т.е. удаление части TO table и отправка запросов в материализованное представление.

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

Я не вижу разницы в двух описанных вами сценариях. Можете ли вы уточнить примеры?

Amos 24.08.2018 06:40
Построение конвейеров данных в реальном времени с Apache Kafka: Руководство по Python
Построение конвейеров данных в реальном времени с Apache Kafka: Руководство по Python
Apache Kafka - популярная платформа распределенной потоковой передачи данных, которую можно использовать для построения конвейеров данных в реальном...
0
1
422
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я бы сказал, что это в основном то же самое.

Единственное отличие состоит в том, что без предложения TO <table> ClickHouse создает таблицу .inner.<mv name> и сохраняет в ней данные, а не в <table>. В противном случае поведение такое же AFAIK.

Подводя итог, я полагаю, что лучше использовать предложение TO <table>, потому что у вас есть лучший контроль над созданной таблицей. Также MV в ClickHouse - это не представления и не таблицы, а триггеры. Поэтому я предпочитаю обращаться с ними именно так и не ожидаю, что они будут использоваться для чтения данных из них.

Другие вопросы по теме