так - стоп. При чем здесь плагиат : )) Посчитайте хэш суммы каждой строки и если это массив - решение что я привел/ Если это последовательность упорядоченных строк - https://clickhouse.tech/docs/ru/sql-reference/functions/other-functions/#runningdifferencex

SELECT
    [1, 2, 2, 2, 2, 2, 4, 2, 2, 2, 2, 3] AS a,
    arraySplit((x, y) -> (y != 0), a, arrayDifference(a)) AS d,
    arrayFilter(x -> (x != 0), arrayMap(x -> countEqual(x, 2), d)) AS v

Query id: 0d09384e-b8bf-4863-87e3-bb22abad52e4

┌─a─────────────────────────┬─d───────────────────────────────────┬─v─────┐
│ [1,2,2,2,2,2,4,2,2,2,2,3] │ [[1],[2,2,2,2,2],[4],[2,2,2,2],[3]] │ [5,4] │
└───────────────────────────┴─────────────────────────────────────┴───────┘

красиво, не поспоришь

я бы даже так не сделал (

на самом деле ваша задача в итоге сводится к массивам как раз https://youtu.be/KumFUCRQnGY?list=PLO3lfQbpDVI-hyw4MyqxEk3rDHw95SzxJ https://youtu.be/3dI4D2wve00?list=PLO3lfQbpDVI-hyw4MyqxEk3rDHw95SzxJ
в каком-то из этих видео, что-то подобное

Столкнулся с удивительной (или нет?) проблемой. Упрощенно:

У меня есть ReplicatedSummingMergeTree. Там есть ключ user_id и поле profit UInt64. Ну и event_time там есть еще.

1. Я вставляю user_id: 20 и profit: 100.
2. SELECT sum(profit) FROM table; // все отлично, выводится 100
3. Я еще раз вставляю user_id: 20 и profit: 100.
4. SELECT sum(profit) FROM table; // все равно выводится 100
5. Я вставляю user_id: 20 и profit: 101.
5. SELECT sum(profit) FROM table; // Выводится 201

Короче говоря, повторный инсерт с теми же данными в SummingMergeTree игнорируется. Меня то ли поплавило окончательно под ночь, то ли он в какой-то момент считает profit ключем (?!), то ли я внезапно перестал понимать, как работает SummingMergeTree

> Короче говоря, повторный инсерт с теми же данными в SummingMergeTree игнорируется.

Добро пожаловать дедубликация инсертов при вставке

Наверное, стоит добавить, что колонка profit была добавлена после. В system.columns выглядит точно так же, как и те, что успешно суммировались.

Кх хранит хеш суммы от последних 100 блоков вставок, если какая то из них повторяется, то инсерт тихо скипается

🙁

Спасибо.

Да, это первое мое столкновение с реплицированными аггрегатами. А ведь когда-то я смотрел, как Миловидов именно про это рассказывал.

Еще раз спасибо, теперь все хорошо.

В реальной жизни это не приводит к проблемам, потому что инсерты никогда не повторяются до бита из-за большого кол-ва строк, или из-за того что SummingMergeTree в MV и дедупликация MV делается дедупликацией основной широкой таблицы.

можно добавить дополнительное поле insertid, заполнять чем-нибудь на клиенте, и если не включать это поле в order by , то SummingMergeTree будет коллапсировать это поле ANY( )

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

Ну в реальной жизни видимо и не будет. Проблема по сути была только в том, что я тестировал вручную новую колонку.

Да, в общем все понятно, еще раз спасибо.

после обновления кликхауса перестал отрабатывать запрос
ALTER TABLE event_log DELETE where (today() - date) > 125
ошибка
DB::Exception: ALTER UPDATE/ALTER DELETE statements must use only deterministic functions! Function 'today' is non-deterministic.

Подскажите как его теперь переписать правильно.

today() заменить на дату

ALTER TABLE event_log DELETE where date < '2020-11-12'