Типичные ошибки и когда ClickHouse не подходит

Финальный урок: чек-лист грабель и трезвая граница применимости.

Большинство проблем с ClickHouse — не баги, а попытки использовать аналитическую базу как транзакционную.

Ошибка 1: мелкие частые вставки

Самая распространённая. Каждый INSERT — отдельный part; вставка по строке порождает лавину кусков и ошибку «too many parts». Лечение: батчи по тысячи/десятки тысяч строк, буферизация потока (приложение, Buffer-таблица, движок Kafka).

Ошибка 2: неверный ORDER BY

Если ключ сортировки не совпадает с тем, по чему вы фильтруете, отсечения гранул не происходит и запрос читает всю таблицу — «ClickHouse почему-то медленный». Лечение: проектируйте ORDER BY под реальные запросы (частый фильтр — первым в ключе). Высококардинальная «перемешивающая» колонка первой в ключе убивает отсечение.

Ошибка 3: частые мутации (UPDATE/DELETE)

В ClickHouse ALTER TABLE ... UPDATE/DELETE — это мутация: тяжёлая асинхронная операция, которая переписывает целые куски. Она не предназначена для частых точечных правок.

-- Это дорогая мутация, не как UPDATE в OLTP!
ALTER TABLE events UPDATE value = 0 WHERE user_id = 42;

Лечение: проектируйте так, чтобы правок не требовалось (append-only), или используйте ReplacingMergeTree/CollapsingMergeTree для логики «новой версии», а удаление старого делайте через DROP PARTITION/TTL.

Ошибка 4: SELECT * и лишние колонки

Колоночное преимущество исчезает, если читать все колонки. Лечение: выбирайте только нужные поля.

Ошибка 5: ждать мгновенной свёртки

Дедупликация/суммирование в спецдвижках и удаление по TTL происходят при слиянии, не сразу. Лечение: понимать асинхронность; при необходимости FINAL или агрегация в запросе.

Когда ClickHouse НЕ подходит

Когда подходит идеально

• Аналитика событий, логи, метрики, временные ряды.
• Отчёты и дашборды по сотням миллионов и миллиардам строк.
• Данные пишутся пачками и в основном не меняются (append-only).

Как работает под капотом

Все «ограничения» ClickHouse — следствие осознанного выбора в пользу скорости сканирования: колоночное хранение, отсутствие построчных транзакций, асинхронные слияния и мутации. Понимая этот компромисс, вы перестаёте бороться с инструментом и начинаете проектировать данные под него.

Частые ошибки (резюме)

• Мелкие вставки → too many parts. Решение — батчи.
• ORDER BY не под запросы → нет отсечения. Решение — ключ под фильтры.
• Частые мутации → дорого. Решение — append-only и спецдвижки.

Итоги

• Главные грабли: мелкие вставки, неверный ORDER BY, частые мутации.
• ClickHouse не для OLTP, точечных правок и крошечных данных.
• Он идеален для массовой аналитики append-only данных.
• Проектируйте данные под колоночную модель — и инструмент раскроется.