select sum(subscriber) subscribers, sum(unsubscriber) unsubscribers, sum(spammer) spammers, sum(unsub_fr_sub) unsub_fr_subs
from (
   select user_id, 
       max(action_type_id=1) subscriber,
       max(action_type_id=0) unsubscriber,  
       length(arrayFilter(i,j -> abs(i.1-j.1)<60 and i.2<>j.2, arrayPopBack(arraySort(groupArray((date,action_type_id))) as d) ,arrayPopFront(d)))>=1 spammer,
       (subscriber and unsubscriber) unsub_fr_sub
   from Z group by user_id
)

через массивы будет быстрее?

нет, и скорее всего по памяти sequencematch  лучше

subscriber and unsubscriber

а если он сначала отпишется а потом подпишется?

ну это легко учесть если надо, можно все сделать через массивы

Можно ли делать alter materialised view для aggregation merge tree?
И можно ли делать ее backup?

Alert! Ripple XRP Alerts/News Feed is a known spammer and is CAS banned. Ban is strongly recommended.

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

Происходит инсерт в таблицу A, на ней MV1 которое делает типа group by day и пишет в aggregating. Если сделать MV2 select from MV1 оно будет видеть результат того group by day и можно сделать group by week например.

>И можно ли делать ее backup?
можно, какая разница, format native умеет стейты, freeze-у вообще все равно, это просто файлы.

Не понял почему мало смысла?
Мне нужно чтобы в mv сохранилось то, что уже есть, а дальше начало делаться тоже самое + некоторые изменения.
Ну то есть не хочется потерять то, что уже есть

>Мне нужно чтобы в mv сохранилось то, что уже есть
MV это обычная таблица, туда просто надо банально вставить insert-м то что вам нужно и когда вам нужно. Populate сильно вредная бессмысленная фигня, которой невозможно пользоваться на проде.

Я используя freeze пересоздаю огромные MV, которые перезаливаются часами, не прерывая вставку в таблицу, очевидно что populate этого ничего не позволяет.

Может я туплю, я прошу прощения.
Но...у меня есть mv aggregation merge tree, в которую вставляются данные по заранее заложенному алгоритму (фактически запросу). С завтрашнего дня, я хочу добавить ещё одну колонку в этот mv. Соответственно, у меня вопрос: могу ли поменять условия вставки данных в этот mv так, чтобы не потерялись уже имеющиеся данные в этом mv?

конечно MV можно изменять, alter-м и менять select.

Какая версия CH у вас?

Не готов сейчас назвать точную...но одна из последних 19.х...

Есть два варианта -- неявный сторадж у MV (MV без TO) и явный (таблица созданная заранее) (MV с TO).
И я давно не пользуюсь MV без TO. Так намного очевиднее и удобнее тупо дропать MV и создавать новое.

# Таблица в которой MV хранит данные создана неявно (самой MV -- .inner)
1. останавливаем заливку
2. detach table MVX
3. alter table `.inner.MVX` add column ..... 
4. attach MATERIALIZED VIEW MVX as select новый_select
5. запускаем заливку

# Таблица в которой MV хранит данные создана явно (MV с TO)
1. останавливаем заливку
2. alter table to_таблица add column .....
3. drop MVX; create MVX to ... as 
4. запускаем заливку

# как переделать неявно созданнаю стор таблицу в явно (TO)
1. останавливаем заливку
2. detach table MVX
3. rename table `.inner.MVX` to MVX_store;
4. create table `.inner.MVX` as MVX_store engine=TinyLog;
5. attach table MVX
6. drop table MVX
7. rename table MVX_store to MVX
8. create materialized view MVX_mv to MVX as select ....
9. запускаем заливку

Если у таблицы надо расширить первичный ключ, это делается с помощью одновременного добавления колонки и modify в одном alter.
alter table xxx add column b String, modify order by (a, b);

Привет всем, только начинаю работать с ch, тут вместо auto_increment id я так понимаю надо generateUUIDv4 () использовать?

Правильно сделать id UInt64 DEFAULT generateUUIDv4()
?

uuid 128 бит, int64 явно не достаточно. Есть тип UUID https://clickhouse.yandex/docs/en/data_types/uuid/

А, ну это да, а так функция в DEFAULT, вообще использование uuid как primary key ок?

Коллизии как?

Ну так 128 бит. Сами оцените вероятность