Кратко — что это и где лучше.
Определения
- Row-oriented (строчное): данные хранятся построчно — все поля одной записи лежат рядом. Примеры: MySQL/InnoDB, PostgreSQL.
- Column-oriented (колонко-ориентированное): данные хранятся по столбцам — все значения одного атрибута подряд. Примеры: ClickHouse, Vertica, Amazon Redshift.
Когда выигрывает row-oriented
- OLTP, транзакции с частыми point-read / point-update: быстрый доступ/обновление одной строки, минимальное число I/O и локальные транзакции.
- Операции, читающие большинство или все столбцы одной строки (например, загрузка карточки пользователя).
- Высокая частота случайных записей/обновлений/удалений; простая поддержка ACID/locking/MVCC.
Почему: при строковой организации все поля нужной строки уже рядом, меньше разрозненных I/O и проще in-place update.
Когда выигрывает column-oriented
- OLAP, аналитика: агрегации, сканирование больших таблиц, группировки, фильтрация по нескольким столбцам, BI-отчёты, time-series.
- Запросы, читающие небольшое подмножество столбцов, но множество строк.
Почему: читается только нужная колонка(и) → меньше I/O, лучше сжатие (однотипные значения) и эффективная векторная обработка/SIMD, predicate pushdown, column pruning.
Простейшая модель I/O (чтобы понять выигрыш)
- Пусть R — число строк, N — число столбцов, M — число запрашиваемых столбцов, размер каждого значения ~S.
- Для полного сканирования M столбцов:
- row-store читает примерно $B_{row}=R\cdot N\cdot S$,
- column-store читает примерно $B_{col}=R\cdot M\cdot S$.
- Отношение $B_{col}/B_{row}=M/N$ — при $M\ll N$ выигрыши существенны.
- Дополнительно колонкохранилище обычно даёт ещё меньший объём за счёт компрессии и специализированного кодирования.
Дополнительные соображения
- Сжатие: колонкохранилища дают гораздо лучшую компрессию → меньше I/O, быстрее декодирование векторно.
- Обновления/вставки: колонка сложнее для частых мелких обновлений; многие column-stores используют write-buffer или LSM-подходы, что добавляет задержку.
- Индексы и селективность: для очень селективных точечных запросов строковые СУБД с индексами часто быстрее.
- Гибриды/HTAP: существуют системы (Kudu, SAP HANA, некоторые реализации MVCC + колонковые форматы), пытающиеся сочетать преимущества — они усложняют архитектуру и требуют компромиссов.
Вывод
- Для классического OLTP (низкая латентность на отдельные строки, частые обновления) — row-oriented.
- Для больших аналитических нагрузок (массовые сканирования, агрегации, few-columns-many-rows) — column-oriented.
- При смешанных нагрузках нужны либо гибридные решения, либо комбинация разных хранилищ (OLTP → row, ETL → column).