🧠 SQL в ClickHouse — это не просто “обычный SQL”

🔥 Главная мысль

Когда человек приходит в ClickHouse после PostgreSQL, MySQL или MS SQL, ему кажется, что SQL здесь будет таким же.

Но на практике ClickHouse SQL похожий, а поведение во многих местах — другое.

Почему?

Потому что ClickHouse — это аналитическая СУБД. А значит, язык запросов здесь подчинён не транзакциям, а скорости чтения, агрегациям и работе с большими объёмами данных.

Самая важная мысль:

в ClickHouse нужно не просто “знать SQL”, а понимать, как этот SQL связан с архитектурой аналитического движка.

🟢 Плюсы

• SQL в ClickHouse знаком по форме и быстро читается • есть мощные возможности для аналитики • удобно писать SELECT, агрегаты, фильтрацию и группировки • есть полезные расширения вроде PREWHERE, APPLY, EXCEPT, table functions • можно работать не только с SQL, но и с PRQL-диалектом, хотя по умолчанию используется clickhouse

Пример плюса: если тебе нужно быстро собрать витрину, посчитать агрегации и отфильтровать большой объём данных, SQL в ClickHouse делает это очень удобно.

🔴 Минусы

• это не “тот же самый SQL”, что в классическом OLTP-мире • UPDATE и DELETE здесь устроены иначе • некоторые знакомые операции работают с аналитической логикой, а не с транзакционной • если писать запросы как в OLTP-базе, можно получить тяжёлые и дорогие сценарии

Пример минуса: если пытаться обновлять строки так же, как в обычной транзакционной БД, можно неожиданно попасть в мутации и полную перезапись затронутых данных. Для UPDATE и DELETE в ClickHouse используются альтернативы через ALTER TABLE ... UPDATE|DELETE, а не классическое поведение OLTP-СУБД.

🧪 Живые примеры

Что важно запомнить с самого начала:

• ClickHouse поддерживает 2 диалекта: SQL и PRQL :contentReference[oaicite:3]{index=3} • основной диалект по умолчанию — clickhouse • SELECT — это главная и самая естественная операция для ClickHouse • INSERT тоже естественен • UPDATE и DELETE — уже неестественная зона для этого движка

Очень показательный пример:

в обычной базе человек думает так: “нашёл строку → обновил строку”

В ClickHouse чаще надо думать так: “загрузил данные → посчитал данные → перестроил данные архитектурно, если нужно”

Ещё один важный пример: в SELECT у ClickHouse есть PREWHERE, WHERE и HAVING, и это не одно и то же.

• PREWHERE — фильтрация раньше WHERE • WHERE — до агрегации • HAVING — после агрегации

То есть даже знакомые конструкции здесь надо понимать чуть глубже.

🏗 Архитектурная мысль

В больших компаниях ClickHouse SQL используют не как “универсальный язык на все случаи”, а как язык аналитического слоя.

Обычно он живёт в задачах типа:

• BI и дашборды • витрины • логи и события • аналитические отчёты • большие агрегации • техничные запросы к system tables и table functions

Что это даёт:

• быстрые аналитические запросы • понятный язык для инженеров и аналитиков • меньше разрыва между бизнес-запросом и реальным SQL

⚠️ Риски:

• думать, что ClickHouse SQL полностью совпадает с PostgreSQL / MySQL • переносить OLTP-привычки в аналитическую СУБД • использовать UPDATE/DELETE как будто это обычная строковая база • не учитывать, что некоторые секции запроса работают по-другому

Отдельно полезно помнить: в ClickHouse много силы не только в базовом SELECT, но и в расширениях вроде COLUMNS('pattern'), APPLY, EXCEPT и table functions. Это как раз то, что делает язык особенно удобным для аналитики и техничных запросов.

✅ Вывод

SQL в ClickHouse — знакомый по форме, но аналитический по смыслу ⚡️

Для чтения, агрегаций, витрин и больших выборок он очень хорош. Для сценариев “точечно обновить строку” — уже не лучший путь.

Поэтому правильный подход такой:

не просто писать SQL, а писать SQL под природу ClickHouse 🚀