0
votes

In the documentation it shows a way to use a materialized view consuming from a KafkaEngine sending the data to a *MergeTree family table.

This has the benefit of, in case of changing of transformation logic, detach the table, make changes, and reattach.

However, if you're not applying logic to it (e.g. field type conversions) , does it make more sense to use the materialized view as destination, applying *MergeTree engine? i.e. removing the TO table part and sending queries to the materialized view.

I don't see this approach anywhere, though. I can see the loss in the flexibility, however, does this approach make sense at all? and what are the limitations of this approach?

1
I fail to see the difference of the two scenarios you described. Can you elaborate with examples? - Amos

1 Answers

0
votes

I'd say that it is basicaly the same.

The only difference is that without TO <table> clause, ClickHouse creates table .inner.<mv name> and stores data there instead of storing it in <table>. Otherwise the behavior is the same AFAIK.

So to sum it up, I suppose it's better to use TO <table> clause because you have better control over that table created. Also MVs in ClickHouse are not views nor tables but triggers. So I prefer to treat them that way and not expect them to be used to read data from them.