llmdocsсправочник разработчика

ClickHouse

Материал из llmdocs — справочник разработчика
Портал: Базы данных
ClickHouse
Типколоночная аналитическая СУБД (OLAP)
АвторАлексей Миловидов и команда Яндекса
Разработкас 2009 года для Яндекс.Метрики
Открытие кодаиюнь 2016
ЯзыкC++
ЛицензияApache 2.0
Разработчик сейчасClickHouse, Inc. (с 2021) и сообщество
Основной движок таблицMergeTree

ClickHouse — колоночная система управления базами данных для аналитики. Она рассчитана на запросы вида «посчитай выручку по дням и регионам за год» по таблицам из миллиардов и триллионов строк и выполняет их за секунды и доли секунды. ClickHouse хранит данные по столбцам, сжимает их и обрабатывает векторно, пакетами значений, используя все ядра процессора. Запросы пишутся на диалекте SQL.[1]

ClickHouse применяют для веб-аналитики, мониторинга и логов, финансовой аналитики, телеметрии, рекламных систем и аналитики LLM-приложений.

История

Разработку начал Алексей Миловидов в Яндексе в 2009 году для системы веб-аналитики Яндекс.Метрика, где требовалось строить отчёты «на лету» по сырым данным, а не по заранее подсчитанным агрегатам. В 2012 году ClickHouse заработал в продакшене Метрики, а в июне 2016 года Яндекс открыл исходный код под лицензией Apache 2.0.[4] В 2021 году для развития проекта была основана компания ClickHouse, Inc., предлагающая и облачный сервис. Архитектура системы подробно описана в статье на конференции VLDB 2024.[3]

Почему так быстро

  • Колоночное хранение. Запрос читает только нужные столбцы: для суммы по одному столбцу из сотни не нужно читать остальные 99.
  • Сжатие. Однотипные значения столбца сжимаются в разы и десятки раз (LZ4, ZSTD и специальные кодеки для временных рядов), так что с диска читается меньше данных.
  • Векторное выполнение. Операции применяются к блокам из тысяч значений, эффективно используя кэш процессора и SIMD-инструкции.
  • Параллелизм. Запрос распараллеливается на все ядра сервера и на узлы кластера.
  • Разреженный первичный индекс. Данные отсортированы по ключу, а индекс хранит по одной отметке на блок строк (по умолчанию 8192), помещаясь в памяти даже для огромных таблиц.

Сравнение с другими аналитическими системами на одинаковых данных — в открытом тесте ClickBench.[5]

MergeTree

Основной движок таблиц — MergeTree. Вставка создаёт новую неизменяемую отсортированную «часть» (part), а фоновые процессы сливают мелкие части в крупные — идея, родственная LSM-деревьям (см. B-дерево).[2]

CREATE TABLE events
(
    event_time  DateTime,
    user_id     UInt64,
    event_type  LowCardinality(String),
    url         String,
    duration_ms UInt32
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_type, event_time)
TTL event_time + INTERVAL 1 YEAR;          -- автоматически удалять старые данные

SELECT
    toDate(event_time) AS day,
    event_type,
    count() AS events,
    uniq(user_id) AS users,                -- приближённый подсчёт уникальных
    quantile(0.95)(duration_ms) AS p95
FROM events
WHERE event_time >= now() - INTERVAL 30 DAY
GROUP BY day, event_type
ORDER BY day;

Варианты движка решают специальные задачи: ReplacingMergeTree удаляет дубликаты по ключу, SummingMergeTree и AggregatingMergeTree хранят предагрегированные данные, ReplicatedMergeTree обеспечивает репликацию. Материализованные представления обновляются при вставке и позволяют строить агрегаты на лету.

Сильные стороны

  • Огромная скорость агрегаций и сканирования; богатая библиотека аналитических функций — квантили, приближённые уникальные значения, массивы, оконные функции.
  • Чтение напрямую из файлов Parquet, CSV и JSON, из S3, Kafka, PostgreSQL и MySQL.
  • Эффективное хранение: логи и метрики занимают в разы меньше места, чем в строковых СУБД.
  • Масштабирование от ноутбука (clickhouse-local) до кластеров из сотен серверов.

Ограничения

  • Не для транзакционной нагрузки. Нет полноценных транзакций ACID в привычном смысле; точечные обновления и удаления дороги и выполняются асинхронными «мутациями» или облегчённым удалением.
  • Вставка пакетами. Тысячи мелких вставок в секунду создают слишком много частей; данные собирают в пакеты или используют асинхронную вставку.
  • Соединения больших таблиц работают хуже, чем в системах, специально под них оптимизированных; схему проектируют широкими денормализованными таблицами (см. Нормализация).
  • Свой диалект SQL с особенностями типов и функций.

Место в архитектуре

Типичная схема: транзакционные данные живут в PostgreSQL или MySQL, события и логи потоком идут через Kafka, а ClickHouse хранит их для аналитики, дашбордов (Grafana, Superset) и отчётов. Альтернативы — облачные хранилища (BigQuery, Snowflake, Redshift), Apache Druid и Pinot, а для аналитики на одной машине — встраиваемая DuckDB.

См. также

Источники

  1. ClickHouse Documentation
  2. ClickHouse — MergeTree table engine
  3. R. Schulze et al. — ClickHouse: Lightning Fast Analytics for Everyone (VLDB 2024)
  4. ClickHouse — History
  5. ClickBench — a Benchmark For Analytical DBMS
  6. ClickHouse — GitHub
Категории: