спасибо! идея понятна. схлопывать все пары состояний +1/-1, чтобы оставить только последнюю запись... такой ручной мерджинг а-ля FINAL.
звучит, и правда, странно. но попробую сравнить, что получится : )

звучит достаточно затратно в плане потребляемой памяти на хранение всех колонок в хешмапе для групбая
или рискнуть и делать GROUP BY cityHash64(id,value,value) тогда меньше занимает, но колизии, да

вообще возможно если есть допустим timestamp, то попробовать что то вроде argMax
либо ORDER BY id, timestamp DESC LIMIT 1 BY id
возможно будет быстрее

да, спасибо, тоже думал про argMax.
но тогда проще сразу в ReplacingMergeTree - там агрегация через version в виде того же timestamp.

вариант с LIMIT BY интересный, попробую тоже.

да, если есть возможность заменить на ReplacingMergeTree, то тоже вариант.

Другое дело, что тебе всеравно придется писать запросы, как будто дубликаты могут быть

у вас условие явно не используется правильно

да, группировка никуда не уйдет.

вообще нужно сразу двух зайцев убить.
с одной стороны дергать плоский список уникальных записей с последними актуальными состояниями (тут удобнее Replacing).
с другой - нужны отчеты/сводки. тут не сильно удобнее, но зато быстрее Collapsing.

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

а что именно не так?

если бы сработал partition elimination, то не сканировалась бы вся таблица
было бы неск млрд записей просканировано

partition by по End_time ?

да

PARTITION BY (toDate(END_TIME), RULEBASE)

вообще нет ничего плохого хранить данные дважды-трижды-сколько нужно раз

т.е. в условие RULEBASE   добавить?

у меня одна таблица хранится дважды, просто для разных ORDER BY

попробутйе условие без toDate Where END_TIME >= and END_TIME <=

а это разве не равнозначно что в условии будет  RULEBASE LIKE '%%'

rulebase тут не причем