OLAPOLTPClickHouseбазы данныханалитика

OLAP и OLTP: разница простыми словами

2026-07-10 11 мин

Коротко: OLTP — это базы под приложение (Postgres, MySQL): много мелких быстрых транзакций, строковое хранение, задача — не потерять ни одной записи. OLAP — базы под аналитику (ClickHouse, Greenplum, DWH): тяжёлые запросы на агрегацию по миллиардам строк, колоночное хранение, задача — быстро посчитать SUM и GROUP BY. Разница olap oltp в одной фразе: OLTP отвечает на вопрос «что сейчас у конкретного клиента», OLAP — «что происходило со всеми клиентами за последний год». Гонять аналитику по проду нельзя, потому что тяжёлый отчёт заблокирует базу, от которой зависят пользователи.

Если ты собеседуешься на аналитика, эту пару спрашивают почти на каждом интервью — прямо или через вопрос «а почему нельзя посчитать это в проде». Разберём по-настоящему: с числами, кодом и российским стеком.

Что такое OLTP и OLAP простыми словами?

Расшифровки звучат страшно, а смысл — бытовой.

OLTP (Online Transaction Processing) — обработка транзакций в реальном времени. Это база, которая крутится под твоим приложением. Пользователь нажал «оформить заказ» — база вставила одну строку в orders, списала товар со склада, создала запись в payments. Три-четыре операции, каждая затрагивает единицы строк, всё за миллисекунды. Таких операций — тысячи в секунду. Классика: Postgres, MySQL, Oracle.

OLAP (Online Analytical Processing) — аналитическая обработка. Это база (или целое хранилище — DWH, Data Warehouse), куда данные из приложения регулярно перекладывают, чтобы по ним считать отчёты. Запрос тут один, но он читает миллионы или миллиарды строк: «выручка по городам за 12 месяцев с разбивкой по категориям». Классика в РФ: ClickHouse, Greenplum, а в облаках — колоночные движки внутри DWH.

Аналогия. OLTP — это касса в супермаркете: быстро пробить один чек, не ошибиться в копейках, обслужить следующего покупателя. OLAP — это когда в конце месяца бухгалтерия берёт все чеки за квартал и считает, какая категория товаров дала больше маржи. Одна касса не должна одновременно обслуживать очередь и пересчитывать квартальную отчётность — она захлебнётся.

Если хочешь освежить, что вообще такое база и SQL, начни с SQL с нуля: что такое БД и SQL — там основы, на которые ложится всё остальное.

Почему приложение живёт в OLTP, а аналитика в OLAP?

У этих двух систем противоположные приоритеты, и оптимизировать под оба сразу физически невозможно.

Приложению важно:

Аналитике важно другое:

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

Наглядное сравнение приоритетов:

ХарактеристикаOLTP (Postgres, MySQL)OLAP (ClickHouse, Greenplum)
Тип нагрузкимного мелких транзакциймало тяжёлых аналитических запросов
Хранениестроковое (по строкам)колоночное (по столбцам)
Типичный запросSELECT * WHERE id = 4815SUM/COUNT ... GROUP BY по миллионам строк
Объём на запросединицы строкмиллионы–миллиарды строк
Операции записиINSERT/UPDATE/DELETE постоянноINSERT пачками, UPDATE почти нет
Свежесть данныхреальное времязадержка минуты–часы (ETL)
Что оптимизируемlatency одной операцииthroughput сканирования
ИндексыB-tree по ключамразреженные, сортировка, партиции

Именно поэтому в нормальной компании данные из OLTP регулярно перегоняют в OLAP через ETL/ELT-пайплайны — приложение пишет в Postgres, а аналитик считает в ClickHouse по вчерашней (или near-realtime) копии.

Чем колоночное хранение отличается от строкового?

Это ключ ко всему различию, поэтому разберём на конкретной таблице. Пусть есть orders с миллиардом строк и колонками: order_id, user_id, city, category, amount, created_at.

Строковое хранение (OLTP) кладёт на диск данные так:

[4815, 77, Москва, электроника, 5300, 2026-06-01]
[4816, 91, Казань, одежда, 1200, 2026-06-01]
[4817, 77, Москва, книги, 640, 2026-06-01]
...

Все поля одной записи — рядом. Чтобы достать заказ №4815 целиком, база читает один непрерывный кусок диска. Идеально для приложения.

Но представь запрос аналитика: «сумма amount по всем заказам». Базе нужно значение только одной колонки, а на диске лежат целые строки. Придётся прочитать все поля всех строк — включая ненужные city, category, created_at — просто чтобы добраться до чисел amount. Это чтение гигабайтов лишних данных.

Колоночное хранение (OLAP) кладёт данные по столбцам:

amount:    [5300, 1200, 640, ...]
city:      [Москва, Казань, Москва, ...]
category:  [электроника, одежда, книги, ...]

Теперь для SUM(amount) база читает только один непрерывный массив чисел — колонку amount. Остальные столбцы вообще не трогаются с диска. Плюс однотипные значения в колонке отлично сжимаются: город «Москва» повторяется миллионы раз, а сжатие таких данных даёт кратную экономию. В ClickHouse это ещё и специальные кодеки — про них подробно в ClickHouse: практический гайд 2026 и ClickHouse-кодеки LZ4, ZSTD, Delta, T64.

Грубая арифметика, почему аналитика в OLAP быстрее в разы. Пусть в строке 6 колонок примерно равного размера, а нам для отчёта нужны 2 из них:

Прочитанные данные (строковое) = 100% строк * 6 колонок = весь объём
Прочитанные данные (колоночное) = 100% строк * 2 колонки = ~33% объёма

Меньше чтения с диска плюс лучше сжатие плюс векторная обработка колонок процессором — в сумме OLAP обгоняет OLTP на аналитических запросах в десятки, а иногда в сотни раз. И наоборот: колоночная база плохо достаёт одну строку целиком и почти не умеет в частые UPDATE — поэтому под приложение она не годится.

Почему нельзя гонять тяжёлые отчёты по проду?

Самый частый способ уронить прод — запустить аналитический запрос на боевой OLTP-базе. Разберём, что именно ломается.

1. Блокировки и конкуренция за ресурсы. Тяжёлый GROUP BY по всей таблице orders съедает CPU, память и дисковый ввод-вывод. Пока он молотит, обычные транзакции пользователей встают в очередь. Пользователь жмёт «оплатить» — и получает таймаут, потому что аналитик решил посчитать годовую выручку прямо в проде.

2. Полное сканирование там, где база к нему не готова. OLTP-база заточена под точечный доступ по индексу. Запрос вида «просканируй всё за год и сгруппируй» заставляет её читать всю таблицу — операция, для которой строковый движок не оптимизирован в принципе. Как читать план такого запроса и находить Seq Scan, разбирается в EXPLAIN ANALYZE в PostgreSQL: как читать медленный запрос.

3. Раздувание буферного кэша. OLTP-база держит в памяти «горячие» страницы — те, к которым обращаются приложения. Аналитический скан прочитывает гигабайты холодных данных и вытесняет горячие страницы из кэша. После твоего отчёта приложение ещё несколько минут тормозит, пока кэш не прогреется заново.

Что делают вместо этого:

Правило аналитика: если запрос считает бизнес-метрику по большому периоду — например DAU за квартал или GMV по всем городам — ему место в OLAP, а не в проде приложения.

Какие базы относятся к OLAP, а какие к OLTP?

Быстрый ориентир, чтобы не путаться на собесе.

OLTP (под приложение, строковое хранение):

OLAP (под аналитику, колоночное хранение):

Важная оговорка: граница не абсолютная. Postgres можно расширить колоночными движками, а некоторые OLAP-системы умеют в near-realtime вставку и работают почти как оперативные. Но базовая логика «строки для транзакций, колонки для агрегатов» держится всегда. Если хочется глубже про современные realtime-OLAP-движки — есть разбор realtime OLAP: ClickHouse, Druid, StarRocks, Pinot и про архитектуру Lakehouse на Iceberg, Trino и ClickHouse.

Как это выглядит в российском стеке (ClickHouse, Greenplum)?

На практике в типичной продуктовой компании в РФ схема такая:

Один и тот же вопрос — разный SQL. Посмотрим на выручку по городам за год.

В OLTP такой запрос вообще стараются не запускать, но синтаксис привычный:

-- Postgres (OLTP): формально работает, но душит прод на большом объёме
SELECT city,
       SUM(amount) AS revenue,
       COUNT(*)    AS orders_cnt
FROM orders
WHERE created_at >= '2025-07-01'
  AND created_at <  '2026-07-01'
GROUP BY city
ORDER BY revenue DESC;

В OLAP-ClickHouse тот же смысл, но движок колоночный и есть свои функции для дат и приблизительных подсчётов:

-- ClickHouse (OLAP): читает только колонки city, amount, created_at
SELECT city,
       sum(amount)      AS revenue,
       count()          AS orders_cnt,
       uniqExact(user_id) AS buyers
FROM orders
WHERE created_at >= '2025-07-01'
  AND created_at <  '2026-07-01'
GROUP BY city
ORDER BY revenue DESC;

Разница в поведении: Postgres пойдёт читать строки целиком и заблокирует ресурсы, ClickHouse прочитает три колонки из миллиарда строк за секунды и никому не помешает, потому что это отдельная система с копией данных.

Отдельная сила OLAP — специализированные функции. Например, приблизительный подсчёт уникальных (uniq) вместо точного, оконные агрегаты по огромным периодам, эффективные джойны фактов на справочники. Про то, как устроена такая аналитика на реальном стеке — ClickHouse для аналитика: гайд.

Если хочешь потренировать сами запросы — агрегаты, GROUP BY, оконные функции — это удобно делать в SQL-тренажёре: там настоящий PostgreSQL и SQLite в браузере, а логика SUM ... GROUP BY одинаковая и для OLTP, и для OLAP. Систематически прокачать SQL с азов до окон можно на курсе SQL с нуля.

Как считать агрегаты на Python, если данных немного?

Не всегда нужна отдельная OLAP-база. Если выгрузка помещается в память (десятки-сотни тысяч строк), аналитик часто делает ту же агрегацию в pandas — и это по духу ровно OLAP-операция: свернуть много строк в таблицу-агрегат.

import pandas as pd

# выгрузка из OLTP или OLAP в DataFrame
df = pd.read_csv("orders.csv", parse_dates=["created_at"])

mask = (df["created_at"] >= "2025-07-01") & (df["created_at"] < "2026-07-01")
year = df.loc[mask]

report = (
    year.groupby("city")
        .agg(revenue=("amount", "sum"),
             orders_cnt=("order_id", "count"),
             buyers=("user_id", "nunique"))
        .sort_values("revenue", ascending=False)
        .reset_index()
)
print(report.head(10))
groupby().agg() в pandas — это тот же аналитический паттерн «сгруппируй и сверни», что и GROUP BY в SQL. Разница только в масштабе: pandas хорош на данных, влезающих в память одной машины, а ClickHouse/Greenplum — когда строк миллиарды. Потренировать pandas-агрегации можно в Python-тренажёре, а если нужен колоночный движок прямо в Python на больших данных — посмотри разбор Polars vs pandas: Polars внутри колоночный и заметно ближе к OLAP-логике.

Что спрашивают про OLAP и OLTP на собеседовании?

Это база, которую на интервью аналитика проверяют почти всегда. Типичные вопросы и короткие ответы, которые от тебя ждут.

«В чём разница OLAP и OLTP?» — OLTP под приложение: много мелких транзакций, строковое хранение, оптимизация под latency одной операции. OLAP под аналитику: тяжёлые запросы на агрегацию, колоночное хранение, оптимизация под throughput сканирования.

«Почему нельзя считать тяжёлый отчёт в проде?» — тяжёлый скан душит ресурсы OLTP-базы, блокирует пользовательские транзакции и вытесняет горячий кэш. Аналитику место в OLAP или хотя бы на read-реплике.

«Почему колоночное хранение быстрее для аналитики?» — читаются только нужные колонки, а не строки целиком; однотипные значения в колонке хорошо сжимаются; процессор обрабатывает массив значений векторно.

«Где здесь ClickHouse, а где Postgres?» — Postgres/MySQL — OLTP под приложение; ClickHouse/Greenplum — OLAP под аналитику, куда данные приезжают через ETL.

«Что такое DWH?» — Data Warehouse, аналитическое хранилище, куда сводят данные из разных OLTP-источников для отчётности; внутри почти всегда колоночный OLAP-движок.

Хочешь потренировать формулировки под реальные собесы — загляни в тренажёр вопросов для аналитика: там вопросы с проверкой, в том числе по базам данных. А отработать устный ответ голосом поможет AI мок-собес, который задаёт вопросы и разбирает твои ответы как живой интервьюер. Полезно будет и общее руководство как подготовиться к собесу аналитика за месяц.

Что запомнить

Дальше — практика. На zasqlpython первые 5 задач в каждом разделе открыты бесплатно: разомнись на SQL-агрегациях в тренажёре, прогони вопросы по базам данных в разделе интервью, а когда захочешь полный доступ ко всем задачам, метрикам и безлимитному AI-собесу — есть Pro. Понимание OLAP vs OLTP — тот самый фундамент, на котором держится вся работа аналитика с данными.

Готовься к собесу на реальных вопросах
OLAP vs OLTP — база, которую спрашивают почти всегда. Прокачай ответы на тренажёре: реальные вопросы аналитика с проверкой.
Открыть тренажёр вопросов →

Похожие статьи