ClickHouse тормозит не из-за объёма, а из-за кривого SQL: как это чинить

ClickHouse тормозит не из-за объёма, а из-за кривого SQL: как это чинить

Терабайты трафика не убивают ClickHouse сами по себе. Убивает запрос, который тащит лишние колонки, фильтрует после агрегации и читает партиции без ключа. Первый принцип: в WHERE должны жить только поля, попадающие в partition key или primary key. Иначе движок делает full scan, а вы потом гадаете, где течет профит.

Дальше — нормализация запроса:
— SELECT только нужные поля, без `*`
— агрегируй после узкого фильтра
— используй `PREWHERE` для колонок с высокой селективностью
— не тащи `JOIN`, если можно собрать витрину заранее в ETL
— для уникальности и дедупликации смотри на `argMax`, а не на ручные костыли

Самая частая ошибка в аналитике байера — считать сырые логи без партиционирования по дате и без сортировки по связке `campaign_id, event_time`. В итоге один и тот же отчёт по расходу и конверсии начинает жить своей жизнью: трекер одно, кабинет другое. Проверяем сходимость дельты в трекере и кабинете, а потом уже оптимизируем SQL-запрос на лету.

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