Что такое ClickHouse и чем она отличается от других баз данных

ClickHouse — колоночная СУБД с открытым исходным кодом, которая за секунды считает агрегаты по миллиардам строк. Обычно к ней обращаются, когда классическая база перестаёт справляться с аналитикой: отчёты считаются минутами, а дашборды открываются настолько медленно, что ими уже никто не пользуется.

Разберём, как устроен ClickHouse, за счёт чего он работает быстро, чем отличается от других БД и с чего начать.

ClickHouse — аналитическая система управления базами данных класса OLAP (Online Analytical Processing). Её задача — быстро выполнять запросы, которые читают и агрегируют большие объёмы данных: считают выручку по регионам, строят воронки, ищут аномалии в логах.

Разработку начали в Яндексе для сервиса веб-аналитики «Метрика». В 2016 году компания открыла исходный код под лицензией Apache 2.0, и с тех пор ClickHouse развивает большое сообщество. Название расшифровывают как Clickstream Data Warehouse — хранилище данных о кликах пользователей.

В русскоязычной среде название произносят по-разному: «кликхаус», «клик хаус», а в поиске встречается и «клик хауз». Англоязычные пользователи иногда пишут его раздельно — click house. Во всех случаях речь об одной и той же СУБД.

Главные особенности ClickHouse:

• Колоночное хранение
  Значения каждого столбца лежат на диске отдельно, поэтому запрос читает только нужные колонки.
• SQL-интерфейс
  ClickHouse — реляционная СУБД в том смысле, что данные организованы в таблицы, а запросы пишут на диалекте SQL.
• Горизонтальное масштабирование
  Кластер можно расширять, добавляя серверы.
• Сжатие
  Однотипные значения в колонке хорошо сжимаются, поэтому хранение обходится дешевле.
• Аналитика в реальном времени
  Новые данные доступны для запросов сразу после вставки.

Столбцовые СУБД отличаются от строковых самим принципом хранения. PostgreSQL или MySQL записывают строку таблицы целиком: все поля одной записи лежат рядом. Это удобно, когда нужно прочитать или изменить конкретную запись. В строковом хранении поля записи обычно размещены рядом, поэтому широкий скан читает больше лишних данных, что может существенно повысить латентность ответа системы.

Скорость ClickHouse складывается из нескольких решений. СУБД читает с диска только нужные колонки и пропускает блоки, которые не подходят под условие запроса. Данные она обрабатывает не по одной строке, а пачками — векторами значений, что эффективно использует кеш процессора и SIMD-инструкции. Сам запрос ClickHouse распараллеливает по всем ядрам сервера, а в кластере — по всем серверам, что повышает скорость обработки запросов.

Архитектура ClickHouse

Основной компонент — процесс clickhouse-server. Он принимает запросы, выполняет их и управляет хранением данных. Подключиться к серверу можно несколькими способами:

• консольный клиент clickhouse-client (нативный протокол, порт 9000);
• HTTP-интерфейс (порт 8123) — удобно для интеграций и скриптов;
• драйверы JDBC/ODBC и библиотеки для Python, Go, Java и других языков.

В классическом self-managed кластере обычно применяют shared-nothing; в SharedMergeTree вычисления отделены от общего объектного хранилища. Масштабирование строится на двух механизмах:

1. Шардирование
   ClickHouse делит данные между шардами. Каждый шард хранит свою часть таблицы, а запрос выполняется на всех шардах параллельно.
2. Репликация
   Внутри шарда одни и те же данные хранят несколько реплик. Если один сервер выходит из строя, запросы обслуживает другой.

Чтобы запрос прошёл по всему кластеру, используют таблицу на движке Distributed. Она не хранит данные сама: принимает запрос, отправляет его на шарды и собирает итоговый результат. ClickHouse Keeper координирует репликацию и метаданные; репликация данных в ReplicatedMergeTree асинхронна.

Как ClickHouse хранит данные?

За хранение в ClickHouse отвечают движки таблиц. Движок определяет, где и в каком виде лежат данные, как работают вставка и чтение, есть ли репликация. Основные группы движков:

• Семейство MergeTree — основной выбор для продакшена. Сюда входят MergeTree, ReplacingMergeTree (убирает дубликаты по ключу при слияниях), SummingMergeTree и AggregatingMergeTree (предагрегируют данные), ReplicatedMergeTree (добавляет репликацию).
• Семейство Log — простые движки для небольших и временных таблиц.
• Движки интеграций — Kafka, PostgreSQL, MySQL, S3: читают данные из внешних систем или пишут в них.
• Специальные движки — Distributed, Memory, MaterializedView и другие.

Разберём, как работает MergeTree. Каждая вставка (INSERT) создаёт на диске новый кусок данных — part. Внутри куска строки отсортированы по ключу, который задаёт выражение ORDER BY. В фоне ClickHouse сливает мелкие куски в более крупные — отсюда название движка.

Каждая колонка куска лежит в отдельном сжатом файле. По умолчанию ClickHouse сжимает данные алгоритмом LZ4. Для отдельных колонок можно выбрать ZSTD или специализированные кодеки — например, Delta для монотонно растущих значений вроде временных меток.

Ключевую роль в скорости играет разреженный индекс (sparse index). ClickHouse делит отсортированные данные на гранулы — по умолчанию по 8192 строки. В первичный индекс попадает не каждая строка, а только значение ключа первой строки каждой гранулы. Поэтому индекс получается компактным и помещается в оперативную память даже для таблиц в миллиарды строк.

Для запроса с условием по ключу ClickHouse находит по индексу нужные гранулы и читает только их. Для колонок вне ключа можно добавить индексы пропуска данных (data skipping indexes) — они работают по тому же принципу.

Управлять объёмом помогают ещё два инструмента:

• Партиционирование (PARTITION BY) делит таблицу, например по месяцам, и старые партиции легко удалить целиком.
• TTL может перемещать данные на volume или disk из storage policy; например, в объектное хранилище S3 при соответствующей настройке.

Схема 3. Разреженный индекс. Горизонтальная лента отсортированных данных, разделённая на гранулы (Гранула 0, 1, 2, 3 — по 8192 строки). Над каждой гранулой — отметка со значением ключа первой строки: 2026-01-01, 2026-01-04, 2026-01-09, 2026-01-15. Отметки собраны в блок primary.idx. Запрос WHERE date = '2026-01-05' показан стрелкой, которая через индекс выбирает только гранулу 1. Остальные гранулы серые, с подписью «пропущено».

ClickHouse решает конкретный класс задач и в нём действительно силён. За пределами этого класса та же архитектура начинает мешать. Поэтому обе стороны полезно понимать заранее.

Ключевые преимущества

• Скорость аналитических запросов
  ClickHouse считает агрегаты по миллиардам строк за секунды, а на небольших объёмах — за миллисекунды.
• Эффективное сжатие
  Колоночный формат и кодеки обычно сокращают объём на диске в несколько раз по сравнению с исходными данными.
• Быстрая вставка
  При пакетной загрузке один сервер принимает сотни тысяч строк в секунду.
• Знакомый SQL
  Диалект близок к стандарту и добавляет полезные возможности: работу с массивами, приближённые вычисления (uniq, quantile), оконные функции.
• Масштабирование
  Шардирование и репликация позволяют вырасти от одного сервера до кластера из десятков и сотен узлов.
• Открытый исходный код
  Лицензия Apache 2.0, без привязки к вендору.
• Интеграции
  Десятки форматов (CSV, JSON, Parquet и другие), чтение из Kafka, S3, PostgreSQL и MySQL.

Ограничения ClickHouse

• Не подходит для OLTP
  Поддержка транзакций в ClickHouse ограничена. Для корзины интернет-магазина или платёжных операций лучше взять PostgreSQL.
• Изменение и удаление данных — дорогие операции
  Классические UPDATE и DELETE через ALTER TABLE переписывают целые куски данных. В новых версиях появились облегчённые варианты, но частые точечные изменения по-прежнему не сильная сторона ClickHouse.
• Мелкие вставки снижают производительность
  Каждый INSERT создаёт новый кусок, и тысячи вставок по одной строке перегружают фоновые слияния. Данные лучше отправлять пакетами или включить асинхронную вставку (async_insert).
• Точечные запросы по ключу медленнее, чем в строковых БД
  Точечный запрос обычно читает как минимум одну гранулу; её размер по умолчанию — до 8192 строк, но он зависит от настроек и размера строк
• JOIN требуют внимания
  ClickHouse поддерживает соединения таблиц, но на больших объёмах их нужно проектировать аккуратно. Часто данные денормализуют — хранят в одной широкой таблице.
• Эксплуатация кластера требует опыта
  Шарды, реплики, Keeper, обновления и бэкапы требуют времени команды.

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

Что важно учитывать при выборе:

• PostgreSQL и MySQL — строковые реляционные СУБД для приложений. ClickHouse их не заменяет, а дополняет: приложение пишет в PostgreSQL, а данные для аналитики попадают в ClickHouse через CDC или Kafka.
• Greenplum — MPP-СУБД на базе PostgreSQL. Она лучше справляется со сложными JOIN и транзакциями, но в типичных запросах по широким таблицам ClickHouse, как правило, быстрее.
• Elasticsearch силён в полнотекстовом поиске, ClickHouse — в агрегациях и сжатии. Поэтому большие объёмы логов в ClickHouse обычно хранить дешевле.

ClickHouse раскрывается там, где данных много, они поступают постоянно, а запросы в основном читают и агрегируют. Типичные сценарии:

• Веб- и продуктовая аналитика — события, воронки, когорты, retention. Ровно та задача, ради которой ClickHouse создавали.
• Логи и observability — логи приложений, трейсы, метрики, события безопасности.
• BI и дашборды — Superset, DataLens или Grafana получают ответ за секунды даже на больших таблицах.
• Телеметрия и IoT — временные ряды с датчиков, которые ClickHouse хорошо сжимает.
• Рекламные и финансовые платформы — показы, клики, конверсии, поиск аномалий.
• Витрины данных — быстрый аналитический слой поверх основного хранилища.

Начать работу с ClickHouse можно двумя способами: поднять сервер самостоятельно или взять готовый кластер в облаке. Первый вариант подойдёт, чтобы посмотреть на СУБД локально: официальный скрипт curl https://clickhouse.com/ | sh скачивает бинарный файл, команда sudo ./clickhouse install ставит его как сервис, а clickhouse-client подключает консольный клиент. Для задач сложнее знакомства придётся добавить к этому шарды, реплики, обновления, мониторинг и резервные копии.

Второй вариант снимает эту часть работы. Managed ClickHouse в MWS Cloud Platform — managed service (управляемый сервис), в котором платформа разворачивает кластер и берёт на себя его обслуживание. Вы выбираете конфигурацию и работаете с данными, а не с инфраструктурой.

Как создать кластер

Кластер создают в веб-консоли, через MWS CLI или API. В консоли порядок такой:

1. Выберите проект, откройте раздел Managed ClickHouse и нажмите Создать.
2. Выберите тип кластера: Standalone — один узел для тестов и небольших нагрузок, Multi-Node — кластер с шардами и ClickHouse Keeper.
3. Укажите версию ClickHouse, тип виртуальной машины, размер диска и при необходимости значение IOPS.
4. Задайте сетевые настройки: сеть, подсеть и тип внутреннего IP-адреса. Внешний адрес нужен, только если планируете подключаться из-за пределов облака.
5. Введите имя и пароль администратора, задайте окно резервного копирования и сервисное окно.
6. Проверьте настройки и нажмите Создать.

Пароль администратора стоит сразу сохранить в Secret Manager: позже посмотреть его не получится. На третьем шаге стоит определиться с релизом: последняя версия приносит новые возможности, LTS-версия живёт дольше и обычно спокойнее ведёт себя в продакшене. Подробности по каждому шагу — в документации сервиса.

Как подключиться к кластеру

Из облака подключаются с виртуальной машины в той же сети, что и кластер. Понадобятся адрес ресурса и имя администратора со страницы кластера, а также корневой сертификат MWS. Дальше — установить клиент (sudo apt install clickhouse-client), прописать путь к сертификату в XML-файле конфигурации и выполнить команду:

bash

clickhouse-client \\

--secure \\

--host <IPv4-адрес ресурса> \\

--port 9440 \\

--user <имя администратора> \\

--password <пароль> \\

--config-file <путь к файлу конфигурации>

Если подключение прошло успешно, клиент выведет версию сервера и номер ревизии — примерно так: Connected to ClickHouse server version 25.1.8 revision 54475. Установленную версию также покажет запрос SELECT version(). Подключиться можно к кластеру целиком, к отдельному шарду или к конкретному узлу — адреса для всех трёх вариантов есть на вкладке Сети. Из внешней сети подключение тоже возможно: для этого добавляют правило файрвола на порт TCP:9440.

Первые запросы

Синтаксис ClickHouse близок к стандартному SQL. Посмотрим на создание таблицы для событий сайта:

sql

CREATE TABLE events

(

event_date Date,

user_id UInt64,

event_type LowCardinality(String),

url String,

duration UInt32

)

ENGINE = MergeTree

PARTITION BY toYYYYMM(event_date)

ORDER BY (event_type, event_date, user_id);

Что здесь важно:

• ENGINE = MergeTree — движок таблицы;
• PARTITION BY — партиции по месяцам;
• ORDER BY — ключ сортировки, по нему строится разреженный индекс; в начало ставят колонки, по которым чаще фильтруют;
• LowCardinality(String) — оптимизация для строк с малым числом уникальных значений.

Добавим данные и посчитаем просмотры и уникальных пользователей по дням:

sql

INSERT INTO events VALUES

('2026-09-01', 1001, 'page_view', '/pricing', 35),

('2026-09-01', 1002, 'click', '/signup', 3);

SELECT

event_date,

count() AS views,

uniq(user_id) AS users

FROM events

WHERE event_type = 'page_view'

GROUP BY event_date

ORDER BY event_date;

Функция uniq считает уникальные значения приближённо и очень быстро. Для точного результата есть uniqExact.

Дальше остаётся обычная работа с данными: базы, пользователи и роли, таблицы и запросы. Резервные копии создаются по расписанию, обновления приходят в сервисное окно, а графики нагрузки доступны в консоли — эту часть Managed ClickHouse закрывает за вас.

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