Column store базы данных: когда они быстрее реляционных решений

Когда аналитический запрос к таблице из миллиарда строк выполняется за секунды, а не за минуты, за этим почти всегда стоит одно архитектурное решение: колоночное хранение данных. Реляционные СУБД хранят каждую запись единым построчным блоком, и на аналитической нагрузке это превращается в узкое место.

Колоночные базы данных устроены иначе: значения каждого столбца записываются отдельным потоком, и движок читает только то, что действительно нужно. На таблицах от сотен миллионов строк это даёт прирост скорости аналитических запросов от 10 до 100 раз — конкретная цифра зависит от числа столбцов в таблице и от того, сколько из них задействовано в запросе (данные бенчмарков ClickBench и TPC-H).

Это не значит, что колоночная база данных везде лучше реляционной СУБД. Архитектура определяет профиль нагрузки, а не универсальное превосходство. В этой статье разберём, чем физически различаются оба подхода, в каких сценариях колоночное хранение даёт кратный выигрыш и как выбрать архитектуру под реальные задачи бизнеса.

Почему архитектура хранения важна

Реляционные СУБД хранят данные построчно: каждая запись представляет собой единый блок из всех полей. Такой формат оптимален для транзакционных операций (OLTP), где нужно быстро прочитать или обновить одну строку целиком. Оформление заказа, списание средств со счёта, регистрация пользователя — всё это построчные операции, и классические СУБД выполняют их за миллисекунды.

На аналитических запросах картина меняется. Запрос «посчитать сумму продаж за квартал по 50 регионам» обращается к двум-трём столбцам из таблицы с 40 полями, но построчная СУБД всё равно читает все 40 столбцов каждой строки. По данным исследований CMU Database Group (Университет Карнеги-Меллона), на типичных аналитических нагрузках от 80 до 95% дискового ввода-вывода уходит на чтение столбцов, которые запрос вообще не запрашивал. На таблице в миллиард записей это разница между секундами и минутами ожидания.

Колоночно-ориентированное хранение решает эту проблему на уровне физической записи: значения каждого столбца размещаются последовательно, отдельно от остальных, и движок читает только то, что действительно нужно. Ускорение аналитических запросов оказывается пропорциональным соотношению задействованных столбцов к общему числу полей в таблице.

Сравнение строчного и колоночного хранения

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

Построчное хранение (row-store). Строка целиком записывается в один блок, в итоге чтение одной записи требует одной операции ввода-вывода. Обновление поля в строке происходит быстро, потому что все данные записи расположены рядом.

Колоночное хранение (column-store). Каждый столбец записывается отдельным потоком. Чтение столбца по всей таблице становится последовательной операцией, которую процессор и дисковая подсистема выполняют максимально эффективно. Обновление одной строки требует записи в несколько отдельных блоков.

Колоночное хранение не вытесняет реляционные базы и не превосходит их в целом — каждая архитектура работает на своём типе нагрузки. Построчная выигрывает там, где нужны транзакции, колоночная — там, где нужна аналитика. Бенчмарк TPC-H, ставший индустриальным стандартом для оценки производительности аналитических СУБД, это наглядно подтверждает.

Преимущества колоночных баз данных

Сжатие данных. Значения внутри одного столбца однотипны: даты, числа, коды категорий. Алгоритмы RLE, dictionary encoding и delta encoding работают на таких данных эффективнее, чем на смешанных построчных блоках. Сжатие колоночных таблиц снижает объём хранения в 5–10 раз. Степень сжатия зависит от кардинальности столбца: низкокардинальные поля (статус, регион, категория) сжимаются в 15–20 раз, высококардинальные (UUID, хэш) — в 2–3 раза.

Скорость агрегации. Запросы с GROUP BY, SUM, COUNT, AVG составляют основную нагрузку на хранилище данных. Колоночные движки обрабатывают их пакетно (batch mode), оперируя блоками по 1 000–65 000 значений за один цикл, и по результатам бенчмарка ClickBench на таблицах со 100+ млн строк выполняют агрегацию в 10–50 раз быстрее построчных СУБД на одинаковом оборудовании. Особенно заметен эффект, когда запрос затрагивает менее 20% столбцов таблицы.

Эффективное использование кэша. Последовательное расположение данных одного столбца в памяти минимизирует промахи кэша процессора. Процессор получает непрерывный поток однородных значений, что является оптимальным паттерном для CPU с многоуровневым кэшем L1/L2/L3.

Векторизация вычислений. Современные колоночные-движки используют SIMD-инструкции (SSE4.2, AVX2, AVX-512) и обрабатывают 4–16 значений столбца за одну процессорную операцию, что даёт дополнительный прирост при фильтрации, сортировке и арифметических вычислениях.

Сценарии применения

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

OLAP-нагрузки. Сложные аналитические запросы с множеством группировок, фильтров и агрегатов — основной профиль для колоночных баз данных. Они спроектированы под эту нагрузку, но каждый со своим акцентом. Tarantool Column Store совмещает колоночное хранение с транзакционной обработкой прямо в оперативной памяти.

Антифрод и риск-скоринг в реальном времени. Финансовые организации обрабатывают тысячи транзакций в секунду и параллельно проверяют каждую по историческим паттернам. Для этого нужна СУБД, которая совмещает транзакционную и аналитическую обработку в одном контуре, то есть реализует HTAP-архитектуру. Tarantool Column Store построен именно так: по документации Tarantool, он хранит более 1Тб данных с 500+ атрибутами и обнаруживает подозрительные операции с задержкой менее 100 миллисекунд. Стоит учитывать, что HTAP оправдан, когда одновременно нужны и транзакции, и аналитика; для чисто пакетной аналитики без обновлений достаточно классического column store.

Оценка кредитных рисков. При выдаче кредита Tarantool Column Store в реальном времени анализирует матрицу кредитных условий и дополнительных сервисов, оценивая риск невозврата по каждому предложению. Колоночное хранилище справляется с такими расчётами за доли секунды, тогда как построчная СУБД на том же объёме потребует десятков секунд из-за избыточного чтения данных.

IoT и телеметрия. Датчики генерируют потоки однотипных числовых данных: температура, давление, обороты. Низкая кардинальность и монотонность временных рядов позволяют колоночным СУБД сжимать такие данные с коэффициентом 10–15x по данным бенчмарков TSBS (Time Series Benchmark Suite), а агрегация по временным окнам — скользящее среднее, максимум за час, сумма за смену — выполняется на лету.

Как выбрать правильную архитектуру

Выбор между строковым и колочным хранением определяется профилем нагрузки.

Какой тип запросов преобладает? Если большинство операций — это INSERT, UPDATE, DELETE по отдельным записям, строчная СУБД будет эффективнее. Если основная нагрузка приходится на SELECT с агрегацией по большим массивам данных, колоночное хранение даст кратный прирост. Определить соотношение можно, проанализировав профиль запросов в production за одну-две недели.

Нужна ли аналитика в реальном времени? Если данные нужно анализировать с задержкой в миллисекунды, стоит смотреть в сторону in-memory колоночных решений. Tarantool Column Store хранит данные в оперативной памяти, совмещает OLTP и OLAP в одном контуре и поддерживает SQL-запросы через стандартные драйверы Arrow flight SQL (через AJBC/JDBC драйвера), а также HTTP API, что избавляет от необходимости строить отдельный ETL-конвейер между транзакционной и аналитической системами.

Какой объём данных и как он растёт? На таблицах до нескольких миллионов записей разница между архитектурами минимальна: современные построчные СУБД справляются с аналитикой на таких объёмах. При переходе к сотням миллионов и миллиардам строк колоночное хранение даёт ощутимое преимущество за счёт сжатия и пакетной обработки.

Для транзакционных систем подходит строковое, для аналитики и хранилищ данных — колоночное хранение. А там, где нужны и транзакции, и аналитика одновременно, стоит рассмотреть HTAP-решения вроде Tarantool Column Store, совмещающие оба подхода в одной СУБД. Сейчас, когда особенно актуален вопрос свежести данных, именно гибридные системы на основе колонок будут особенно полезны — об этом мы расскажем в одном из ближайших материалов в блоге.