Почему в olap индексы не востребованы?

Почему индексы не востребованы в OLAP

Отличия между OLTP и OLAP кардинально влияют на эффективность индексов. В OLAP-системах традиционные индексы теряют свою актуальность по нескольким критическим причинам.

1. Полнотабличные сканирования

ОЛАП запросы часто требуют анализа больших объёмов данных. Пример:

SELECT 
    region,
    SUM(sales) as total_sales,
    AVG(discount) as avg_discount
FROM orders
WHERE year = 2024
GROUP BY region

Такой запрос затрагивает миллионы строк. Обход индекса по B-tree будет медленнее, чем полное сканирование всей таблицы с применением оптимизированных алгоритмов обхода.

2. Аналитические операции

ОЛАП фокусируется на агрегации и группировке, а не на поиске конкретных записей:

• SUM, COUNT, AVG, MIN, MAX
• Фильтры обычно охватывают широкий диапазон значений
• Индекс на столбец, по которому фильтруем, не экономит ресурсы

3. Columnar Storage — архитектурный выбор

Модерные OLAP-системы (ClickHouse, Apache Druid, Parquet) используют column-oriented хранение вместо row-oriented:

Рядное хранилище (OLTP):
[id=1, name=Alice, age=30] [id=2, name=Bob, age=25]

Столбцовое хранилище (OLAP):
id:   [1, 2, 3, ...]
name: [Alice, Bob, Charlie, ...]
age:  [30, 25, 35, ...]

Получить все значения одного столбца в столбцовом хранилище дешевле, чем использовать индекс.

4. Секционирование и partitioning

ОЛАП системы используют горизонтальное секционирование по дате, региону и т.д.:

# Пример: данные разделены по годам
orders_2022/ 
orders_2023/
orders_2024/

Оптимизатор может исключить целые секции из сканирования (partition pruning) вместо использования индекса внутри таблицы.

5. Неизменяемость данных

ОЛАП обычно имеет append-only архитектуру:

• Старые данные не обновляются
• Новые данные добавляются батчами
• Индексы на изменяемых данных требуют постоянного переиндексирования

6. Стоимость памяти

Традиционные индексы занимают дополнительную память. В OLAP с петабайтами данных это критично:

• Индекс на большую таблицу может быть размером в гигабайты
• ROI (return on investment) от индекса низкий, если всё равно нужно сканировать большой диапазон

Альтернативы индексам в OLAP

1. Bitmap-индексы (для низкокардинальных столбцов):

Пол: [M, F, M, F, ...]
Вместо B-tree используем bitmap:
Мужчины:  [1, 0, 1, 0, ...]
Женщины:  [0, 1, 0, 1, ...]

2. Статистика и метаданные:

# ClickHouse хранит min/max для блоков
block_1: min_date=2024-01-01, max_date=2024-01-31
block_2: min_date=2024-02-01, max_date=2024-02-29
# Это позволяет пропустить целые блоки

3. Компрессия и кодирование:

• Run-length encoding для повторяющихся значений
• Dictionary encoding для строк
• Snappy, ZSTD для сжатия

Заключение

В OLAP полное сканирование оптимизированное (через columnar storage, compression, partition pruning) эффективнее, чем навигация по индексам. Это стратегический выбор архитектуры: sacrifice write performance и storage для read performance на больших датасетах.