Почему в OLAP-системах индексы не так востребованы, как в OLTP?

В OLAP-системах классические индексы (B-tree, hash) менее эффективны из-за характера аналитических нагрузок. Основная операция — не поиск отдельных записей, а сканирование и агрегация больших объемов данных.

Ключевые причины:

• Полнота сканирования: Аналитические запросы (например, GROUP BY, SUM по всему столбцу) часто требуют чтения всех строк. Индексы не ускоряют такие операции, а иногда даже замедляют из-за дополнительных операций ввода-вывода.
• Колоночное хранение: Данные хранятся по столбцам. При запросе считываются только нужные столбцы, что само по себе является мощной оптимизацией, делая индексы на уровне строк избыточными.
• Альтернативные методы оптимизации: Для фильтрации эффективнее используются:
  • Сортировка данных по первичному ключу (например, в ClickHouse).
  • Партиционирование по дате или категории.
  • Специализированные индексы, такие как скип-индексы (skip-indexes), которые хранят агрегированную информацию (min/max, Bloom filter) для блоков данных, позволяя пропускать нерелевантные блоки при сканировании.
• Затраты на запись: Поддержка индексов значительно замедляет операции вставки и обновления (ETL/ELT), что критично для хранилищ данных.

Пример в ClickHouse: Вместо создания отдельного индекса используется сортировка по первичному ключу, которая определяет физический порядок данных на диске.

CREATE TABLE sales (
    event_date Date,
    product_id UInt32,
    revenue Decimal(10,2)
) ENGINE = MergeTree
ORDER BY (event_date, product_id); -- Ключ сортировки для эффективных диапазонных запросов

-- Запрос с фильтром по дате будет эффективен благодаря сортировке
SELECT product_id, SUM(revenue)
FROM sales
WHERE event_date BETWEEN '2023-01-01' AND '2023-01-31'
GROUP BY product_id;