Есть рекламный сервис, хотим переезжать на clickhouse, уже поиграли на тестовом кластере, впечатлились, но пока не очень понятно как его правильно приминить у нас. В частности, у нас такая специфика, что бывают хиты без кликов. Т.е. сначала идет хит (решаем какую рекламу показать), а потом может быть клик. Понятное дело, что потом на освное этих кликов существует много репортов. Вот как это правильно подружить с КХ?

Есть рекламный сервис, хотим переезжать на clickhouse, уже поиграли на тестовом кластере, впечатлились, но пока не очень понятно как его правильно приминить у нас. В частности, у нас такая специфика, что бывают хиты без кликов. Т.е. сначала идет хит (решаем какую рекламу показать), а потом может быть клик. Понятное дело, что потом на освное этих кликов существует много репортов. Вот как это правильно подружить с КХ?

добавить колонку "event_type" ENUM Hit, Click ?

Есть рекламный сервис, хотим переезжать на clickhouse, уже поиграли на тестовом кластере, впечатлились, но пока не очень понятно как его правильно приминить у нас. В частности, у нас такая специфика, что бывают хиты без кликов. Т.е. сначала идет хит (решаем какую рекламу показать), а потом может быть клик. Понятное дело, что потом на освное этих кликов существует много репортов. Вот как это правильно подружить с КХ?

У нас примерно та же история, и две отдельные таблицы под показы и клики. В репортах джоин, на 1тб данных и двух репликах работает норм.

джоин по hit_id?

Да, по нему родимому

а первичный ключ при этом другой, типа user_id?

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

Но при желании можно сделать матвью, если сильно хочется всех на всех

понял, будем крутить этот момент дальше

и такой вопрос: как вообще можно удалить старое? Нам нет нужды хранить все за годы - 3х месяцев достаточно, а распухания базы конечно хотелось бы избежать

https://clickhouse.yandex/docs/en/query_language/queries.html#manipulations-with-partitions-and-parts

? спсб

У нас примерно та же история, и две отдельные таблицы под показы и клики. В репортах джоин, на 1тб данных и двух репликах работает норм.

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

не совсем понял, как это помгло избежать join on hit_id

А что делать, если между показом и кликом проходит полчаса? Это надо как-то события буферизовать

В основной таблице события хранятся несколько месяцев, а не несколько минут :)

правильно понимаю, что это как @feriat выже предложил с ENUM hit/click?

не совсем понял, как это помгло избежать join on hit_id

Для каких отчетов нужен такой джойн? У нас вроде где-то используется подзапрос на `hit_id global in (select hid ids for clicks in the given interval), но это редкий тип отчета