OLTP vs OLAP для аналитика

Карьерник — квиз-тренажёр в Telegram с 1500+ вопросами для собесов аналитика. SQL, Python, A/B, метрики. Бесплатно.

Зачем это знать

OLTP vs OLAP — fundamental concept в data engineering. На собесе junior/middle аналитика спросят обязательно: «в чём разница», «какой тип у ClickHouse», «почему production-DB не для аналитики».

На работе это проявляется: «не делай heavy SELECT на prod-БД — положит приложение». Без понимания OLTP/OLAP — не поймёте почему.

В статье:

  • Короткий ответ
  • Примеры OLTP и OLAP систем
  • Почему для analytics нужен separate DWH
  • Columnar storage — секрет OLAP
  • ClickHouse, Snowflake, BigQuery

Короткий ответ

  • OLTP (Online Transaction Processing): для транзакций, operational. Postgres, MySQL, Oracle.
  • OLAP (Online Analytical Processing): для аналитики, BI. Snowflake, BigQuery, ClickHouse, Redshift.

OLTP — «создай заказ, возьми баланс» (частые, мелкие операции). OLAP — «сколько заказов по категориям за квартал» (редкие, тяжёлые aggregations).

Сравнение

OLTP OLAP
Цель транзакции аналитика
Данные актуальные исторические
Объём GB TB-PB
Запросы короткие, частые длинные, редкие
Пример operations INSERT, UPDATE одной строки SELECT, GROUP BY миллионов
Storage row-oriented column-oriented
Schema 3NF (нормализация) star/snowflake (dimensional)
Пользователи приложение аналитики

Почему нужны оба

OLTP для приложения

Когда пользователь делает заказ:

INSERT INTO orders (user_id, total) VALUES (42, 2500);
UPDATE users SET total_orders = total_orders + 1 WHERE id = 42;

Нужна скорость на уровне миллисекунд. Читает/пишет по одной записи.

OLAP для аналитики

Когда аналитик хочет отчёт:

SELECT category, SUM(total)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY category;

Сканирует миллионы строк, агрегирует. Может идти секунды-минуты.

Если делать оба в одной БД — аналитический запрос блокирует приложение. Классика.

Columnar storage — секрет OLAP

Row-oriented (OLTP)

Postgres хранит строки целиком. Для INSERT/UPDATE одной строки — быстро.

Row 1: [id=1, name=Alice, age=30, city=Moscow]
Row 2: [id=2, name=Bob, age=25, city=SPb]

Column-oriented (OLAP)

Snowflake / ClickHouse хранят колонки отдельно.

id column:   [1, 2, 3, 4, ...]
name column: [Alice, Bob, ...]
age column:  [30, 25, ...]

Для SELECT SUM(age) нужно прочитать только age column — 10× быстрее. Плюс compression лучше (однородные данные).

Примеры систем

OLTP

  • PostgreSQL — open-source, full-featured
  • MySQL — популярный web apps
  • Oracle — enterprise
  • SQL Server — Microsoft ecosystem
  • MongoDB — NoSQL document
  • Redis — in-memory key-value

OLAP

  • Snowflake — cloud DWH, Pay-per-use
  • BigQuery (Google) — serverless
  • Redshift (AWS) — managed Postgres-like
  • ClickHouse — open-source columnar (используется Яндексом, Avito)
  • Apache Druid — real-time OLAP
  • Vertica — enterprise

Hybrid (HTAP)

Системы, пытающиеся совместить OLTP + OLAP в одной БД:

  • TiDB
  • SingleStore (MemSQL)
  • CockroachDB

Ограничено в production использовании.

Для аналитика

Где работаете

  • Source DBs (OLTP): Postgres / MySQL — «read only» иногда
  • DWH (OLAP): Snowflake / BigQuery / ClickHouse — основная работа
  • ETL переносит данные из OLTP в OLAP раз в день / час

Типовой стек

App → PostgreSQL (OLTP) → [ETL через Airflow/dbt] → Snowflake (OLAP) → Metabase (BI)

Аналитик query-ит Snowflake, не Postgres.

На собесе

«Разница OLTP и OLAP?» OLTP для транзакций (app). OLAP для аналитики.

«Почему не делать аналитику на prod-БД?» Тяжёлые SELECT блокируют транзакции приложения.

«ClickHouse — OLTP или OLAP?» OLAP (columnar).

«Что быстрее для SELECT миллионы строк?» OLAP columnar — в 10-100× быстрее row-based OLTP.

Частые ошибки

1. Аналитика на production OLTP

Replicas или DWH — обязательны.

2. Использовать Postgres для analytics на больших данных

До 1TB нормально. Дальше — нужен Snowflake / ClickHouse.

3. UPDATE в OLAP

Columnar плохо подходит для обновлений. Архитектура append-only.

4. Not normalizing OLAP

В OLAP denormalization — стандарт (star schema).

Связанные темы

FAQ

MySQL — только OLTP?

Да, по классике. Для analytics — читать реплику или копировать в DWH.

Можно ли analytics на Postgres?

Для малых объёмов — да. Для серьёзной аналитики (>500GB) — нет.

ClickHouse vs Snowflake?

ClickHouse — open-source, self-hosted. Snowflake — cloud managed. Оба OLAP.

Airflow нужен?

Для ETL из OLTP в OLAP — обычно да.


Тренируйте SQL и data engineering — откройте тренажёр с 1500+ вопросами для собесов.