OLTP и OLAP, строковое и колоночное хранение

↑ 3.1 ClickHouse · → Следующая

Желательно~3 мин чтенияУровень: middle

Зачем это на собесе

Базовый вопрос перед ClickHouse: чем аналитическая нагрузка отличается от транзакционной и почему для неё нужна другая БД.

OLTP и OLAP

	OLTP	OLAP
Задача	транзакции: заказ, платёж	аналитика: отчёты, дашборды
Запросы	много коротких, по ключу	мало тяжёлых, агрегаты по миллионам строк
Читает	несколько строк, все столбцы	много строк, несколько столбцов
Запись	частые точечные INSERT/UPDATE	пакетная загрузка, редкие обновления
Данные	текущие	исторические, большие объёмы
Примеры	PostgreSQL, MySQL	ClickHouse, BigQuery, Snowflake, Druid
Консистентность	строгая ACID	часто eventual, упор на скорость сканирования

Строковое и колоночное хранение

Строковое: значения одной строки лежат рядом. Эффективно для чтения записи целиком.

Колоночное: значения одного столбца лежат рядом отдельным файлом.

Запрос: SELECT avg(price) FROM sales WHERE date >= '2026-01-01'
Строковое:  читаются ВСЕ столбцы всех строк, затем берутся два нужных
Колоночное: читаются только столбцы price и date

Преимущества колоночного хранения:

• читаются только нужные столбцы (в таблице 100 столбцов, в запросе 3 — читается 3%);
• сильное сжатие: значения одного типа и похожие подряд (LZ4, ZSTD, delta, dictionary);
• векторизованное выполнение: обработка блоками (тысячи значений) с SIMD;
• эффективные агрегаты и фильтры.

Недостатки: дорого читать/менять одну строку целиком, UPDATE/DELETE неэффективны, транзакции ограничены.

Что такое ClickHouse

Колоночная СУБД для OLAP с открытым исходным кодом (разработана в Яндексе, теперь ClickHouse Inc.). Особенности:

• очень быстрое сканирование и агрегация (миллиарды строк в секунду на кластере);
• SQL с расширениями, богатые агрегатные функции и функции массивов;
• встроенная репликация и шардирование;
• горизонтальная масштабируемость;
• сжатие в 5–20 раз;
• эффективная вставка батчами;
• неограниченная сортировка «на диске» и параллелизм.

Когда подходит

Логи и события, метрики и трассы (observability), веб- и продуктовая аналитика, рекламные и финансовые отчёты, IoT-телеметрия, time-series.

Когда не подходит

• частые точечные UPDATE/DELETE;
• OLTP-транзакции и строгая консистентность между таблицами;
• запросы по первичному ключу «одна строка» как основная нагрузка (можно, но это не сильная сторона);
• небольшие данные (PostgreSQL проще);
• много JOIN между крупными таблицами как основной сценарий (поддерживается, но требует внимания).

Типовая архитектура

PostgreSQL (OLTP)  ──CDC / Kafka / ETL──▶  ClickHouse (OLAP)  ──▶  Grafana / BI / отчёты

Основную транзакционную БД не нагружаем аналитикой: данные реплицируются в ClickHouse.

Вопросы с ответами

Почему колоночная БД быстрее для аналитики?

Читаются только нужные столбцы, данные хорошо сжимаются, обработка идёт векторизованно блоками, что даёт большой выигрыш на агрегатах по большим таблицам.

Почему ClickHouse плох для OLTP?

Нет полноценных транзакций и эффективных точечных UPDATE/DELETE, вставки ожидаются батчами, чтение отдельной строки требует обращения ко многим столбцам.