ClickHouse тормозит не из-за объёма, а из-за плохого запроса — вот где режется CPU

ClickHouse тормозит не из-за объёма, а из-за плохого запроса — вот где режется CPU

Терабайты трафика не требуют магии, они требуют дисциплины в SQL. Сначала смотри не на таблицу, а на план: сколько строк реально читает запрос, есть ли чтение лишних партиций, не ломает ли фильтр индекс по первому ключу. Если условие стоит на функции от поля — ClickHouse часто уходит в полный скан.

Рабочие правила:
— Фильтры по времени и ключам ставь в WHERE без обёрток вроде toDate() и substring().
— Выбирай только нужные колонки: SELECT * на сырых логах — это лишний IO и память.
— Используй партиционирование под реальный паттерн запросов, а не под красивую схему в DDL.
— Для агрегаций сначала сужай выборку, потом считай метрики; GROUP BY по сырым терабайтам без предфильтра — прямой путь к деградации.

Отдельно проверяй сортировку ключа: если основные разрезы — offer_id, campaign_id, event_time, то порядок в ORDER BY должен помогать, а не мешать. Иначе дедупликация, джоины и оконные функции начнут есть память быстрее, чем ты успеешь открыть Grafana. Данные не врут, в отличие от байеров.

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