Почему данные для анализа лучше хранить в OLAP базе данных?

Почему данные для анализа хранят в OLAP базах

OLAP (Online Analytical Processing) — это специализированный класс систем, оптимизированный для аналитических запросов. Данные для анализа хранят в OLAP базах, а не в традиционных OLTP (Online Transaction Processing) системах, из-за кардинальных различий в паттернах использования.

Различие между OLTP и OLAP

OLTP системы (как PostgreSQL, MySQL в режиме базы приложения) оптимизированы для:

• Частых малых транзакций (INSERT, UPDATE, DELETE)
• Быстрого доступа к единичным записям
• Нормализованных схем данных (для избежания аномалий)
• Строчной ориентации хранения (row-based storage)

OLAP системы (как Clickhouse, Vertica, Snowflake) оптимизированы для:

• Редких, но массивных аналитических запросов
• Чтения больших объёмов данных с фильтрацией
• Денормализованных схем (для скорости запросов)
• Колонной ориентации хранения (column-based storage)

Основные преимущества OLAP для анализа

1. Колонная ориентация хранения

OLAP базы хранят данные по колонкам, а не по строкам. Это критично для аналитики:

-- В OLTP (row-based): для получения среднего дохода по регионам
-- нужно прочитать ВСЕ колонки всех миллионов записей
SELECT region, AVG(revenue) FROM sales GROUP BY region;

-- В OLAP (column-based): прочитаны ТОЛЬКО колонки region и revenue
-- остальные данные пропущены

При запросе средней суммы по 100 млн строк в OLTP может потребоваться прочитать 50 ГБ данных, в OLAP — часто только 500 МБ нужных колонок.

2. Компрессия данных

В колонной ориентации однотипные данные расположены рядом. Алгоритмы компрессии (LZ4, ZSTD, RLE) эффективнее сжимают однородные значения:

# В одной колонке 100 млн записей: [1, 1, 1, 2, 2, 2, 3, 3, 3, ...]
# Компрессия RLE (Run-Length Encoding):
# 1 (count=33M) + 2 (count=33M) + 3 (count=33M)
# Результат: ~1GB вместо 30GB в неупакованном виде

3. Индексирование и векторизация

OLAP системы используют:

• Primary Key индексы для быстрого поиска по основному ключу
• Партиционирование по временным периодам (date ranges)
• Векторизованные операции — обработка блоков данных за раз (SIMD)

-- Быстрый запрос благодаря партиционированию по дате
SELECT COUNT(*) FROM analytics 
WHERE date >= 2024-01-01 AND date < 2024-02-01;
-- Прочитаны только партиции за январь

4. Денормализованные схемы

ОЛАП базы позволяют хранить данные в денормализованном виде (Star Schema, Snowflake Schema):

-- Вместо 8 JOINов в OLTP:
SELECT 
  d.date, 
  r.region, 
  c.category,
  COUNT(*) as cnt
FROM fact_sales f
JOIN dim_date d ON f.date_id = d.id
JOIN dim_region r ON f.region_id = r.id
JOIN dim_category c ON f.category_id = c.id
GROUP BY d.date, r.region, c.category;

-- В OLAP часто одна денормализованная таблица:
SELECT date, region, category, COUNT(*) 
FROM sales_analytics
GROUP BY date, region, category;

5. Масштабируемость на большие объёмы

OLAP базы спроектированы для работы с петабайтами данных:

• Распределённые системы (Clickhouse, Vertica кластеры)
• MPP архитектура (Massive Parallel Processing)
• Экспортируемость в облако (Snowflake, BigQuery)

Производительность

Бенчмарк типичного запроса (1 млрд строк, 50 колонок):

Когда нельзя использовать OLAP

• Высокая частота обновлений (OLAP часто read-optimized)
• ACID транзакции (некоторые OLAP не гарантируют)
• Малые датасеты (оверхед не окупается)

Вывод

ОЛАП базы хранят данные специально для аналитики: колонной ориентацией, компрессией, партиционированием и денормализацией. Это даёт 100-1000x ускорение для типичных аналитических запросов по сравнению с OLTP базами.