SQL в ClickHouse тормозит не на терабайтах, а на плохой модели данных

SQL в ClickHouse тормозит не на терабайтах, а на плохой модели данных

Сырые логи и кривой SQL почти всегда бьют по одному месту: диск, сетевой слой и лишние чтения. Если запрос делает full scan по всей таблице, он уже проиграл. Нормальная схема начинается с правильного PARTITION BY и ORDER BY: сначала режем по дате, потом сортируем по ключам фильтрации. Иначе ClickHouse честно прочитает всё, а потом вы будете искать, где именно течет профит?

Проверяем базовые вещи:
• фильтр по партиции должен попадать в WHERE;
• в JOIN не тащим лишние поля, только ключ и нужные метрики;
• агрегируем как можно раньше, а не после вывода сырых строк;
• используем pre-aggregation для частых срезов, а не пересчитываем их каждый раз.

Самая дорогая ошибка — пытаться лечить медленный запрос косметикой. LIMIT, кэш и перенос условий в подзапрос помогают только если план чтения уже адекватный. Смотрите EXPLAIN, оценивайте количество прочитанных строк, проверяйте, попал ли запрос в нужный индекс и не сломал ли его CAST() или функция на колонке фильтра.

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

Оптимизируем SQL-запрос на лету только после того, как убрали лишние чтения и пересчитали схему хранения.