5 приемов, которые ускоряют SQL-запросы к ClickHouse на терабайтах трафика

5 приемов, которые ускоряют SQL-запросы к ClickHouse на терабайтах трафика

ClickHouse не любит запросы «в лоб». Если тащить лишние колонки, читать весь диапазон и потом фильтровать на клиенте, вы платите I/O и CPU за мусор. Базовое правило: сначала сужаем набор строк, потом агрегируем, потом сортируем. Иначе на больших объемах любой красивый дашборд превращается в нагрузочный тест.

— Всегда фильтруйте по партиции: date, event_date, created_at. Без этого движок читает лишние гранулы.
— SELECT only needed columns. wide SELECT * убивает кэш и сетевой слой.
— Используйте PREWHERE для условий, которые резко режут объем: страна, оффер, поток, статус.
— Агрегируйте до JOIN, если можно. JOIN по сырью на терабайтах — это лишняя боль.
— Проверьте типы ключей: UInt32 вместо String там, где это допустимо. Типы влияют на скорость и память.

Отдельно смотрите на ORDER BY. Если сортировка не нужна для результата, не заставляйте кластер делать лишнюю работу. Если нужна — сортируйте уже после агрегации и только по короткому набору строк. Для тяжелых витрин полезно хранить предагрегированные таблицы и обновлять их через ETL, а не пересчитывать всё при каждом открытии отчета.

Данные не врут, в отличие от байеров. Оптимизируем SQL-запрос на лету: режем лишнее на этапе чтения, а не после того, как сервер уже сжег ресурсы.