Обновить данные в ClickHouse без UPDATE: кейс IBS

[RouR]

Посмотрев на код запросов, у меня сложилось впечатление что их автор умеет в Sql но плохо знает Clickhouse.

Оставлю Вам эту ссылку - https://clickhouse.com/docs/ru/sql-reference/aggregate-functions/reference/argmax

[dovbysh]

CollapsingMergeTree ( https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/collapsingmergetree/ )не помог бы решить задачу?

[anton_jan]

Какую задачу Вы имеете ввиду? Для задачи в целом нет. Если под задачей понимать какую-либо часть обработки в "конвейере", то его можно использовать для уменьшения количества записей. Собственно, мы его аналог используем в таблице metrics_agg.

[btyshkevich]

Вы запускали это под нагрузкой? У меня никогда не получалось делать тяжелые join в рамках MV, инициированные Kafka Engine. В конечном счете шли ошибки и все останавливалось. Пришлось сделать внешний планировщик, который запускал insert select

[anton_jan]

Нагрузочное тестирование проводили. Конечно, если в таблицах будет много записей, порядка 1 млрд., вставка больших пачек, скажем 1 млн., будет занимать минуты. И всё будет зависеть от того, устраивает Вас это или нет. У нас не так много новых записей, в сутки до 10 млн., поэтому join-ы не такие тяжёлые, потому что join будет с таблицей в которое количество записей такое, какую пачку выбрал консюмер из Kafka. К тому же сортировку в таблицах мы подбирали так, чтобы join-ы выполнялись как можно более быстро. Разница в скорости в итоге от первого варианта до итогового была ощутимая, если правильно помню около 1.5 раз.
В любом случае как общий подход наше решение советовать не стану, нужно исходить из Ваших конкретных условий. Нагрузка, железо и прочее.

[btyshkevich]

select metrics_dirty.RecId,
               metrics_dirty.Time,
               metrics_dirty.Sign,               
               row_number() over(partition by metrics_dirty.RecId,
                                              metrics_dirty.Sign
                                     order by metrics_dirty.Time desc) as rn
          from metrics_dirty –-Таблица-источник с грязными данными
          left join metrics_uniq –-Таблица-приёмник с уникальными записями
            on metrics_uniq.RecId = metrics_dirty.RecId
           and metrics_uniq.Sign = metrics_dirty.Sign
         where coalesce(metrics_uniq.RecId, '') = '' –-Добавляем, если ещё нет в приёмнике

Вот ваш джойн. Тут правая таблица, которая полезет в память это metrics_uniq, которая большая. Блок вставки - это metrics_dirty, она маленькая, но это уже неважно. Такой join не должен работать в рамках kafka loop processing

[anton_jan]

Вы, возможно, не обратили внимание на мою оговорку в статье насчёт тяжёлых join, я этот момент затронул. Выходом для нас стало использование with (хотя можно из без него). То что вы говорите верно, если не учесть этот момент, и мы его учли, за счёт чего join для нас стал приемлемым.

[btyshkevich]

Не обратил. Да, так можно. В весьма ограниченных рамках, при низкой интенсивности потока данных.
И очень странно сформулировано (почему with, а не подзапрос?). Очень странно что нет примера на SQL, а приведен неправильный код, который по сути не работает. Вы бы дописали в статью финальную версию.

[anton_jan]

У нас много полей, c with получался более лаконичный код, но можно и без него, конечно.
Про неправильный код Вы зря, всё таки схема рабочая, а про with и особенность join я упомянул, не захотел писать только чтоб статью сильно не раздувать деталями, хотя может Вы и правы, стоило.

[btyshkevich]

with прекрасен, его надо использовать и даже больше чем у вас в коде. Я про другое. Тот трюк про который вы упомянули (и не описали). Называется подзапрос. with, а более правильнее CTE - это понятие синтаксиса SQL, а не сути того что вы делаете.

Что касается схемы - нет, она нерабочая. Так делать нельзя. Нельзя в рамках kafka loop в общем случае делать такие джойны. Если хотите так сделать - указывайте настройки Kafka Engine, где вы исскуственно ограничиваете размер блока и расширяете временной интервал, так чтобы у вас все работало.

Но я бы так не делал никогда. Вы закладываете мину замедленного действия. Рано или поздно у заказчика увеличится поток данных или просто кафка остановится на сутки, и вы огребете поток, который не сможете отработать должным образом.

[btyshkevich]

Если эта тема вам интереса, то вот мой вариант как это надо делать - https://github.com/bvt123/SCH
Я оторвал кусок от реального проекта и выложил в opensource. И даже что-то описал. Но пока идет тяжело. Если интересно - читайте и задавайте вопросы, может быть это меня простимулирует дописать статью для хабра. А то пока есть ощущение, что это все никому не нужно.