прекрасно, так и сделаю

Всем привет! А в clickhouse как-то можно сделать оконную функция суммы sum(field) over ()? Ну кроме как подзапрос + запрос с тоталом в селекте

Всем привет. Вопрос - по mutations, может ли их частое выполнение негативно повлиять на производительностью clickhouse? Предполагается периодическое сканирование данных, собранных за последний час и удаление (так же за период данных за этот час) с последующей заменой их insertами. В % от основного объема данных это меньше 0.5%. Какие проблемы могут возникнуть?

1 абзац
какую проблему решаете?

Мутации не предназначены для того, что бы быть частью  ETL

будет перезаписываться каждый парт... т.е. будете вкладывать в глобальное потепление...

select gr, arrayJoin(ar), s from ( select gr, groupArray(value) ar,  arraySum(groupArray(value)) s from (select number%3 gr, number value from numbers(10)) group by gr)

Спасибо!

На старте мобильного приложения  нет доступа к некоторым параметрам(например - не проинициализированы некоторые SDK). Ждать полной инициализации мы не можем себе позволить, т.к. речь идет про первые секунды запуска и эти данные очень важны особенно когда мы выясняем причины не загрузок. Конечно с помощью подзапросов можно решить эту ситуацию, но не во всех вариантах получается хорошая производительность.  
Совсем частный случай - на старте приложения не доступен рекламный идентификатор пользователя, который у нас используется как primary key. Мы также генерируем свой идентификатор и по нему мы можем соотнести из будущих данных и дополнить. Использовать же свой идентификатор в  качестве primary key совсем не оптимально, т.к. все другие источники данных с которыми выполняются join дают только рекламный идентификатор и неплохо иметь именно его в качестве primary key.
Варианты решения конечно есть разной степени не удобства, поэтому интересовался возможностью просто выполнить update

join  ? primary key? В каком смысле join ?

Primary key имеется ввиду, что он является ключом как в order_by так и что более важно - ключем для distributed

Под update подразумевается что я конечно делаю все мутации на уровне локальных таблиц через delete и insert уже в distributed.

collapsingMT или другой движок который умеет схлопывать в 0 (summingMT)

т.е. отменяем запись со своим id, вставляем вообще другой (уже реальный id)

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

Подскажите, а при создании первичного ключа, есть ли принципиальная разница между ORDER BY (CounterID, CreatedAt) и ORDER BY (CreatedAt, CounterID)?

Спасибо, буду экспериментировать!