Comments 8
Из статьи не все понял.
Если делать вставку message в мат view с индексом (message) - то она схлопнется - это описывается как потери данных?
Воспроизведется ли проблема, если у нас в orderby указаны (message, message_id)?
1) Схлопывание реальных дублей движком ReplacingMergeTree по тому ключу, который в секции order by - это правильная работа, специально нацеленная на дедупликацию. Сама по себе мат вьюха в клике ничего не схлопывает, все зависит от движка таблицы под капотом.
2) Я так и не сумел наиграть реальный воспроизводимый кейс. Ловил на проде потери данных мат вьюхами (а вот таблицами - нет), много экспериментировал, но сумел лишь исправить проблему, и описать причины (дедупликация + особенности вставки + еще куча окружающих вещей), по которым данные могут теряться.
3) Если же вы столкнулись с реальной потерей данных мат вьюхой - понаблюдайте за ней пару дней, соберите немного статистики (как часто теряет, сколько и т.д.). Затем добавьте в config.xml настройку deduplicate_blocks_in_dependent_materialized_views = 1. Ну и наблюдайте, что потери прекратились.
В доке про deduplicate_blocks_in_dependent_materialized_views (и судя по доке она наоборот должна работать) речь идёт про Replicated* (например, ReplicatedMergeTree). Вы уверены что в том виде что вы указали эта проблема есть? Ибо тогда это выглядит как баг.
Забудьте о документации на русском, она устарела/не обновляется уже на столько, что кардинально может отличаться от того, как клик работает - читайте на английском(это самое актуальное).
Кажется должно также решаться буферным движком перед вставкой в ReplacingMergeTree
вот вы и попались в капкан) - ClickHouse не тормозит, но теряет данные. Часть 2 — от буферных таблиц к Kafka Engine / Хабр
Всплыло из памяти PTSD из 90х, юниксовая поговорка про NFS: yes, it corrupts your data, but look how fast it is (оно портит ваши данные, но как быстро!)
ClickHouse не тормозит, но теряет данные. Часть 1 — дедупликация