возможности update,и для этого придуманы коллапсирующие движки типа VersionedCollapsingMergeTree
А как быть, если надо предыдущую версию записи сохранить для аудита (в другой таблице). Update бывают редко, для отчетов всегда нужна последяя версия, но предыдущие версии нужны просто для посмотреть в UI. В идеале в другую таблицу их сохранять.
Данные - показания счетчиков электроэнергии. они идут плотным потоком, не всегда в строгой последовательности по времени.
Кто как выкручивается?
Две таблицы, одна для последнего состояния, вторая для истории с обычным движком mergeTree соединены через Materialized VIEW
Спасибо. Перевариваю. А первая получается типа VersionedCollapsingMergeTree? и вставляем сразу в две таблицы? Что то пока не могу ухватить идею.
CollapsingMergeTree нужен в 90% случаев для задачи подсчета sum и count агрегатов, только для этого есть толк в строках и антистроках. Для остальных видов запросов есть ReplacingMergeTree
>вставляем сразу в две таблицы для этого есть MATERALIZED VIEW, они работают аналогично insert trigger в других базах
это осознал. Спасибо. Там действительно нет задачи подсчета агрегатов, надо просто перезаписать значение.
ага, я по Oracle знаю, что такое MView, думаю в КХ аналогично. Но если я использую ReplaceMergeTree то как я узнаю, что уже такой ключ там есть? или делаем так 1. делаем insert очередной пачки записей в таблицу "A" (MergeTree) 2. из таблицы с конечными значеними "B" (ReplaceMergeTree) переписываем в таблицу "V" записи которые есть в таблице "A". то есть что то типа insert into V select from A if exists in B 3. переношу все записи из A в B (и все что нужно зареплейсится).
Не совсем, в кх MV работают как insert trigger, те нет возможности пересчитывать их по расписанию и тд. > Но если я использую ReplacingMergeTree то как я узнаю, что уже такой ключ там есть? Никак, просто пихаете все записи в ReplacingMergeTree, таким образом что бы при схлопывании всех записей по ORDER BY у вас оставалась только одна нужная. Потом пишете запросы к ReplacingMergeTree определенным образом(схлопывая все записи в последнее состояние)
покурить это надо. Не ухватываю мысль. Попробую вот так: была запись X версии1 в ReplacingMergeTree Я вставляю X версии2 в ReplacingMergeTree. Хочу, что бы в таблице осталась X версии2 но Xверсии1 а) не пропала без следа б) не мешалась.
Нужно две таблицы, MergeTree которая будет хранить всю историю ReplacingMergeTree которая будет схлопывать дубликаты во время мержей. Но это же означает, что в произвольный момент времени дубликаты будут находится в таблице и вам нужно будет писать запросы специальным образом, что бы они вам не мешали
Обсуждают сегодня