ClickHouse: SQL или NoSQL и что это меняет — вопрос о трёх разных вещах. Официальная документация ClickHouse называет продукт высокопроизводительной колоночной SQL-СУБД для аналитической обработки OLAP. Язык запросов здесь SQL, логическая модель — таблицы со строками и колонками, а физическое хранение — колоночное. Классификация NoSQL к ClickHouse не применяется.
Официальное определение ClickHouse
Документация ClickHouse на странице Intro даёт прямое определение: это высокопроизводительная колоночная система управления базами данных на SQL для онлайн-аналитической обработки. Продукт доступен как открытое ПО и как облачное предложение. Аналитика в этом определении — SQL-запросы со сложными вычислениями: агрегациями, обработкой строк, арифметикой — по массивным наборам данных.
Из этого определения следуют три независимых утверждения. Первое: интерфейс — декларативный язык на основе SQL, во многих случаях совпадающий со стандартом ANSI SQL. Второе: назначение — OLAP, аналитические запросы, которые обрабатывают миллиарды и триллионы строк. Третье: физическая организация — колоночная.
Документация перечисляет поддерживаемые конструкции: GROUP BY, ORDER BY, подзапросы в FROM, JOIN, оператор IN, оконные функции, скалярные подзапросы. Управление учётными записями выполняется SQL-запросами, ролевая модель доступа настраивается в духе ANSI SQL и распространённых реляционных СУБД.
Определение NoSQL приводит IBM: это подход к проектированию баз данных, позволяющий хранить и запрашивать данные вне традиционных структур реляционных баз. IBM описывает NoSQL как «not only SQL» или «non-SQL». Это определение подхода, и оно не описывает ClickHouse.
Различие принципиально для читателя: ярлык NoSQL описывает семейство подходов к модели данных и доступу, а определение ClickHouse описывает конкретный продукт с SQL-интерфейсом и аналитическим назначением.
Язык, модель данных и физическое хранение
Три вопроса, которые стоит держать раздельно. Язык запросов: на чём пишутся запросы. Логическая модель: как данные описаны для пользователя. Физическое хранение: как байты лежат на диске.
ClickHouse отвечает на них так. Язык — SQL. Логическая модель — таблицы с именованными колонками и типизированными значениями. Физическое хранение — колоночное: значения каждой колонки хранятся последовательно друг за другом.
Документация ClickHouse объясняет следствие колоночной раскладки. Восстановить отдельную строку сложнее, потому что между значениями строки появляются промежутки. Зато операции над колонками — фильтры и агрегации — работают существенно быстрее, чем в строковой раскладке.
FAQ ClickHouse формулирует это короче: колоночная база хранит данные каждой колонки независимо, что позволяет читать с диска только те колонки, которые нужны конкретному запросу. Плата — операции, затрагивающие целые строки, становятся пропорционально дороже.
Отсюда практический вывод. Наличие SELECT в синтаксисе не превращает систему в реляционную СУБД по факту, и колоночное хранение не превращает её в NoSQL. Это два разных измерения, и ClickHouse попадает в SQL по языку и в колоночные по хранению.
| Вопрос | Ответ для ClickHouse | Что это меняет |
|---|---|---|
| Язык запросов | SQL, декларативный, близкий к ANSI | Знакомый синтаксис, GROUP BY, JOIN, оконные функции |
| Логическая модель | Таблицы, колонки, типы | Схема описывается явно |
| Физическое хранение | Колоночное | Читаются только нужные колонки |
| Назначение | OLAP | Агрегации по большим объёмам |
| Семейство NoSQL | Не относится | Ярлык wide-column сюда не подходит |
Учебная таблица events: пять строк
Для проверки смысла SQL-запроса возьмём учебный набор из пяти строк. Значения условные, база данных при подготовке статьи не запускалась. Таблица называется events и описывает события пользователей.
| event_time | user_id | event_type | amount |
|---|---|---|---|
| 2026-11-01 10:00:00 | u1 | view | 0 |
| 2026-11-01 10:01:00 | u2 | view | 0 |
| 2026-11-01 10:02:00 | u1 | click | 0 |
| 2026-11-01 10:03:00 | u1 | purchase | 700 |
| 2026-11-01 10:04:00 | u2 | purchase | 1500 |
Пять строк, четыре колонки, три типа событий. Колонка amount хранит сумму покупки, у просмотров и кликов там ноль.
Запрос к этой таблице группирует события по типу и считает три агрегата: количество событий, сумму amount и максимум amount.
SELECT event_type, count() AS events, sum(amount) AS total, max(amount) AS largest
FROM events
GROUP BY event_type
ORDER BY total DESC, event_type ASC;
Порядок строк в результате задан двумя ключами: сначала по убыванию суммы, затем по возрастанию типа события. Второй ключ определяет, как расположатся строки с одинаковой нулевой суммой.
Ручной эталон без запуска базы
Результат считается вручную по пяти строкам. Покупок две: 700 и 1500. Сумма 2200, максимум 1500, количество 2. Просмотров два: суммы 0, максимум 0. Клик один: сумма 0, максимум 0.
Отсортированный эталон выглядит так:
purchase|2|2200|1500
click|1|0|0
view|2|0|0
Порядок нулевых сумм определён вторым ключом event_type ASC: click идёт раньше view по алфавиту. Всего строк в результате три — по числу различных типов событий.
Три проверки, которые читатель выполняет на бумаге. Первая: сложить 700 и 1500, получить 2200, взять максимум 1500, посчитать количество покупок — 2. Вторая: пересчитать по исходной таблице просмотры и клики — 2 и 1. Третья: убедиться, что число агрегатных строк равно трём.
Эталон не является результатом прогона ClickHouse и не измеряет скорость. Это арифметическая проверка логики запроса на прозрачных данных.
Мутация 1500 → 1600 и что она проверяет
Третья проверка — логическая мутация. На отдельной учебной копии таблицы меняется ровно одно значение: amount последней строки, 1500 заменяется на 1600. Остальные четыре строки остаются нетронутыми.
Пересчёт после замены. Покупки: 700 и 1600. Сумма 2300, максимум 1600, количество по-прежнему 2. Просмотры и клик не затронуты: их суммы и максимумы остаются нулевыми, количества — 2 и 1.
Эталон после мутации:
purchase|2|2300|1600
click|1|0|0
view|2|0|0
Что показывает эта проверка. Агрегат total зависит от значений колонки amount, а агрегат events — от количества строк. Замена одного числа меняет сумму и максимум, но не меняет счётчики. Порядок строк в результате сохраняется, потому что purchase остаётся единственной группой с ненулевой суммой.
Мутация проверяет логическую агрегацию: читатель видит, какие части запроса реагируют на изменение данных, а какие нет. Физическую колоночную организацию она не проверяет и не может проверить.
| Состояние | purchase total | purchase largest | purchase events | click | view |
|---|---|---|---|---|---|
| Исходное | 2200 | 1500 | 2 | 1 | 2 |
| После 1500 → 1600 | 2300 | 1600 | 2 | 1 | 2 |
Что запрос доказывает, а что берётся из документации
Запрос с GROUP BY проверяет логическую агрегацию: как из пяти строк получаются три агрегатные строки с правильными суммами, максимумами и счётчиками. Это проверяемо вручную и не требует запуска базы.
Физическое колоночное хранение запрос не доказывает. То, что значения колонки лежат на диске последовательно, следует из документации ClickHouse. Смешивать эти два уровня — распространённая ошибка при чтении примеров.
Документация ClickHouse на странице Intro сама соединяет SQL-пример и объяснение row/column: там приведён запрос по 100 миллионам строк веб-аналитики, который выбирает и фильтрует несколько колонок из более чем ста существующих. Официальное сравнение строковых и колоночных хранилищ объясняет разницу в объёме читаемых байтов: колоночное хранилище читает только нужные колонки, строковое вынуждено загружать целые блоки.
Отдельно стоит различие, которое путает чаще всего. Wide-column базы вроде Cassandra, HBase и Bigtable хранят строки, но набор колонок в каждой строке может отличаться. Это разреженные строковые хранилища под высокую скорость записи по ключу. Колоночные базы вроде ClickHouse хранят значения каждой колонки вместе. Совпадение в названии — источник основной путаницы в этой категории.
Практический порядок проверки для читателя: сначала посчитать агрегаты вручную по исходным строкам, затем сверить с результатом запроса, затем отдельно прочитать в документации, как устроено хранение. Три шага отвечают на три разных вопроса.
Частые вопросы
ClickHouse — это NoSQL или SQL?
ClickHouse — SQL-СУБД. Официальная документация называет продукт колоночной SQL-системой управления базами данных для OLAP. Язык запросов декларативный, основан на SQL и во многих случаях совпадает со стандартом ANSI SQL. К семейству NoSQL продукт не относится.
Почему ClickHouse называют колоночной базой, если это SQL?
Колоночность описывает физическое хранение, а SQL — язык запросов. Значения каждой колонки хранятся на диске последовательно, поэтому запрос читает только нужные колонки. Язык при этом остаётся SQL. Два измерения не противоречат друг другу.
Чем колоночная база отличается от wide-column NoSQL?
Wide-column базы хранят строки, и набор колонок в каждой строке может различаться. Колоночные базы хранят значения каждой колонки вместе. Документация ClickHouse прямо разделяет эти два класса систем и называет совпадение в названии частым источником путаницы.
Можно ли проверить колоночное хранение обычным SELECT?
Нет. Запрос с GROUP BY проверяет логическую агрегацию: суммы, максимумы, счётчики. Физическая раскладка данных по колонкам описывается в документации и не выводится из результата запроса. Эти два уровня стоит проверять отдельно.
Что даёт замена одного значения в учебной таблице?
Замена 1500 на 1600 меняет сумму покупок на 2300 и максимум на 1600, а счётчики остаются прежними. Такая мутация показывает, какие агрегаты зависят от значений колонки, а какие — от количества строк. Это ручная проверка логики запроса.