Официальная документация
ClickHouse Docs
Базовые концепции: table engines, архитектура, SQL и операционные практики.
ClickHouse — колонночная OLAP СУБД для аналитики на больших объёмах. Её сильная сторона — быстрые агрегирующие запросы по событиям и логам при высоком throughput записи и эффективной компрессии данных.
История: ключевые вехи
Внутренний запуск в Яндексе
ClickHouse появляется как колонночная аналитическая база для высоконагруженных отчётов.
Open source релиз
Проект становится публичным и начинает развиваться в open-source экосистеме.
Выделение отдельной компании ClickHouse, Inc.
Команда запускает отдельную компанию вокруг проекта, фокус смещается на коммерческую экосистему и cloud-направление.
Cloud и экосистема
Развитие managed-предложений, object storage интеграций и экосистемы инструментов.
Ключевые принципы архитектуры
Column-oriented storage
Чтение только нужных колонок резко снижает I/O для аналитических запросов.
MergeTree family
Партиции, сортировка, фоновые merge-процессы и репликация — ядро большинства продакшен-инсталляций.
Vectorized execution
Запросы выполняются батчами, что повышает throughput и эффективность CPU-кеша.
Compression + skipping
Колоночная компрессия и data skipping индексы ускоряют scan-heavy workload.
High-Level Architecture
На high-level уровне ClickHouse разделяет client layer, coordinator layer и storage/background слой MergeTree. Запись и чтение идут через координаторы, а фактическое хранение и вычисления происходят на shard-репликах.
Sharded + Replicated
Канонический продакшен-профиль: шардирование по ключу, репликация через Keeper и параллельный scan.
Плюсы
- Горизонтальный масштаб под рост данных.
- Лучший read throughput и отказоустойчивость.
- Гибкая балансировка write/read пути по узлам.
Ограничения
- Выше операционная сложность.
- Нужен контроль lag, merge backlog и skew.
Workload Queue
Control Plane
Запросы распределяются по шардам, а реплики обеспечивают HA и масштаб чтения.
Готово к симуляции архитектуры ClickHouse.
Последнее решение
—
Активный шаг: idle
Shard A / R1
primary replica
parts: 36 | reads: 0 | writes: 0
Shard A / R2
secondary replica
parts: 35 | reads: 0 | writes: 0
Shard B / R1
primary replica
parts: 34 | reads: 0 | writes: 0
Shard B / R2
secondary replica
parts: 33 | reads: 0 | writes: 0
Replication & Merges
Keeper ops: 0
Репликация и merge-процессы держат parts и lag в управляемом диапазоне.
Cluster Counters
Reads: 0 | Writes: 0 | Parts: 138 | Avg lag: 1.5
Контролируйте баланс между ingestion throughput, merge backlog и query latency.
Architecture Checklist
Write / Read Path через компоненты
Ниже интерактивная схема, где видно прохождение запросов через ключевые компоненты: coordinator, shard replicas, Keeper и background процессы.
Read/Write Path Explorer
Выбери путь и запусти последовательность, чтобы увидеть прохождение запроса через компоненты ClickHouse.
Write path: operational notes
- Клиент отправляет INSERT батчами (обычно через HTTP/native protocol).
- Данные пишутся в новые части (parts) внутри MergeTree-таблиц.
- Фоновые merge-процессы укрупняют parts и оптимизируют хранение.
- При репликации данные синхронизируются между репликами через coordination layer.
Read path: operational notes
- Планировщик определяет, какие партиции и части потенциально релевантны запросу.
- Data skipping и min/max статистики отсекают лишние диапазоны данных.
- Движок читает только нужные колонки и выполняет агрегации батчами.
- Результат возвращается после parallel scan и reduce-этапов.
Практика моделирования данных
- Сначала проектируй под шаблоны чтения и агрегации, а не под OLTP-нормализацию.
- Выбирай ORDER BY так, чтобы ключевые фильтры максимально отсеивали данные.
- Используй партиционирование по времени/домену для управляемых retention и scan.
- Применяй materialized views для pre-aggregation горячих аналитических отчётов.
- Планируй TTL/retention заранее — объёмы в аналитике растут быстро.
Когда выбирать ClickHouse
Хорошо подходит
- Product analytics, BI-дашборды, observability/лог-аналитика.
- Событийные и time-series данные с очень высоким write throughput.
- Сложные агрегирующие запросы по большим историческим объёмам.
- Near-real-time витрины данных для команд продукта и аналитики.
Стоит избегать
- OLTP-сценарии с частыми point-updates и короткими транзакциями.
- Нагрузки, где критичны row-level lock и строгая transactional семантика.
- Системы с множеством мелких UPDATE/DELETE в реальном времени.
- Use cases, где ключевая задача — online serving по одной записи.