Транзакции и аналитика: две разные нагрузки

Почему банковский перевод и квартальный отчёт нагружают базу совершенно по-разному.

OLTP (Online Transaction Processing) — обработка коротких транзакций, читающих и меняющих немного строк. OLAP (Online Analytical Processing) — анализ, читающий миллионы строк, но мало колонок.

Две жизни одной базы данных

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

Теперь руководитель хочет отчёт: «выручка по категориям за последний год с разбивкой по неделям». Этот запрос прочитает все заказы за год — десятки миллионов строк — но из каждой возьмёт только дату, категорию и сумму. Результат — небольшая табличка. Это OLAP: редкие, но очень тяжёлые запросы, сканирующие огромные объёмы.

Сравнение характеристик

Пример аналитического запроса

Вот как выглядит типичный OLAP-запрос на стандартном SQL — он сканирует всю таблицу заказов и сворачивает её в короткий отчёт:

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  category TEXT,
  amount INTEGER
);
INSERT INTO orders (id, category, amount) VALUES
  (1, 'books', 300),
  (2, 'books', 500),
  (3, 'toys', 1200),
  (4, 'toys', 800),
  (5, 'books', 200);
SELECT category, SUM(amount) AS revenue, COUNT(*) AS cnt
FROM orders
GROUP BY category
ORDER BY revenue DESC;

На пяти строках это мгновенно. Но представьте, что строк сто миллионов — и тут начинаются проблемы, о которых следующий урок.

Как работает под капотом

OLTP-базы оптимизированы под точечный доступ: B-tree индексы быстро находят нужную строку по ключу. Но они хранят строки целиком, рядом друг с другом. Для аналитики это плохо: чтобы посчитать сумму по одной колонке, движок вынужден прочитать с диска все колонки всех строк, потому что физически они лежат вперемешку. Аналитические базы переворачивают эту модель — об этом весь курс.

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

• Гонять тяжёлую аналитику на боевой OLTP-базе. Один отчёт «на весь год» может забить диск и память так, что оформление заказов начнёт тормозить.
• Думать, что «база — это база». OLTP и OLAP — разные инструменты под разные задачи, как грузовик и гоночная машина.

Итоги

• OLTP — короткие частые транзакции, мало строк, важна надёжность.
• OLAP — редкие тяжёлые запросы, миллионы строк, важна скорость сканирования.
• Аналитические базы (включая ClickHouse) созданы именно под OLAP.