Столбцовое хранение

Столбцовое хранение (англ. columnar storage, column-oriented storage) — это способ организации данных в базах данных и файловых системах, при котором значения одного столбца (атрибута) таблицы хранятся физически последовательно, в отличие от традиционного строчного хранения, где последовательно записываются все поля одной записи. Данный метод оптимизирован для аналитических нагрузок (OLAP), предполагающих чтение большого количества значений из небольшого числа столбцов, и широко применяется в системах бизнес-аналитики, хранилищах данных и колоночных СУБД.

История

Концепция столбцового хранения возникла в 1970-х годах в рамках развития реляционных баз данных. Одной из первых систем, использующих такой подход, стала CASSM (Context-Addressed Segment Sequential Memory), разработанная в Калифорнийском университете в Беркли. Однако практическое распространение технология получила лишь в конце 1990-х — начале 2000-х годов с ростом объёмов данных и потребностей в быстрой аналитике.

Первой коммерческой колоночной СУБД считается Sybase IQ (выпущена в 1996 году), которая изначально была ориентирована на хранилища данных. В 2000-х годах появились специализированные системы, такие как Vertica (основана на исследованиях Майкла Стоунбрейкера, 2005), C-Store (2005), а также встроенные колоночные движки в составе традиционных СУБД (например, Microsoft SQL Server Columnstore Index, 2012). В 2010-х годах столбцовое хранение стало стандартом для облачных аналитических платформ (Amazon Redshift, Google BigQuery, Snowflake) и форматов файлов для больших данных (Apache Parquet, Apache ORC).

Принцип работы

В отличие от строчного хранения, где вся строка таблицы записывается в один блок памяти или на диск, при столбцовом хранении данные каждого столбца группируются отдельно. Например, для таблицы «Продажи» со столбцами «Дата», «Товар», «Сумма» строчное хранение запишет последовательно: (Дата1, Товар1, Сумма1), (Дата2, Товар2, Сумма2) и т. д. Столбцовое хранение запишет сначала все даты, затем все товары, затем все суммы.

Физическая организация

• Столбцовые сегменты: каждый столбец хранится в виде отдельного файла или набора блоков. Внутри сегмента значения могут быть сжаты, отсортированы или закодированы.
• Словарное кодирование: для столбцов с повторяющимися значениями (например, категории товаров) создаётся словарь уникальных значений, а в сегменте хранятся их коды. Это резко повышает степень сжатия.
• Битовые карты (bitmap indexes): для столбцов с небольшим числом уникальных значений могут использоваться битовые карты, ускоряющие фильтрацию.
• Зоны данных (min-max zones): для каждого блока столбца хранятся минимальное и максимальное значение, что позволяет при запросе с условием (WHERE) быстро пропускать блоки, не содержащие нужных данных (метаданные).

Преимущества и недостатки

Преимущества

1. Высокая производительность аналитических запросов: при чтении только необходимых столбцов (SELECT SUM(Сумма) FROM Продажи) объём считываемых данных с диска или из памяти значительно меньше, чем при строчном хранении, где пришлось бы читать все строки целиком.
2. Эффективное сжатие: значения одного типа (числа, даты, короткие строки) сжимаются лучше, чем разнородные данные в строке. Степень сжатия может достигать 10–20 раз по сравнению с несжатым строчным хранением.
3. Оптимизация для агрегаций: операции SUM, COUNT, AVG, MIN, MAX выполняются над непрерывным массивом чисел, что позволяет использовать SIMD-инструкции процессора и векторизованные алгоритмы.
4. Ускорение фильтрации: благодаря битовым картам и зонам данных многие строки отбрасываются без чтения их содержимого.

Недостатки

1. Низкая производительность для операций вставки, обновления и удаления отдельных строк: запись одной строки требует записи в несколько столбцовых сегментов, что приводит к фрагментации и снижению скорости. Поэтому колоночные СУБД обычно оптимизированы для пакетной загрузки, а не для транзакций (OLTP).
2. Сложность реализации транзакционной обработки: поддержка ACID (атомарность, согласованность, изоляция, долговечность) в столбцовых системах требует дополнительных механизмов (например, delta-хранилищ для недавних изменений).
3. Потребление памяти при чтении целых строк: если запрос требует все столбцы таблицы (SELECT *), столбцовое хранение может работать медленнее строчного из-за необходимости сборки строк из разных сегментов.

Применение

Столбцовое хранение является стандартом для следующих классов систем:

• Хранилища данных (Data Warehouses): Teradata, Amazon Redshift, Google BigQuery, Snowflake, ClickHouse, Vertica.
• Системы бизнес-аналитики (BI): Tableau, Power BI, Qlik — при подключении к колоночным источникам.
• Форматы файлов для больших данных: Apache Parquet, Apache ORC — используются в экосистемах Hadoop, Spark, Hive, Presto.
• Встроенные колоночные индексы: Microsoft SQL Server Columnstore Index, PostgreSQL с расширением cstore_fdw.
• СУБД смешанного типа: SAP HANA, Oracle Database In-Memory — поддерживают одновременное строчное и столбцовое хранение для разных таблиц.

Примеры реализации

ClickHouse (Россия)

Колоночная СУБД с открытым исходным кодом, разработанная компанией «Яндекс». Оптимизирована для аналитики в реальном времени, использует собственное столбцовое хранение с поддержкой сжатия, словарного кодирования и векторных вычислений. Широко применяется в системах мониторинга, веб-аналитики и рекламных технологиях.

Apache Parquet

Формат файлов с открытой спецификацией, основанный на столбцовом хранении. Поддерживает сложные вложенные структуры данных, эффективное сжатие и метаданные для оптимизации запросов. Является стандартом де-факто для хранения данных в экосистеме Hadoop.

Microsoft SQL Server Columnstore Index

Функция, введённая в SQL Server 2012, позволяющая создавать столбцовые индексы для таблиц. Используется для ускорения аналитических запросов в хранилищах данных, работающих на базе этой СУБД.

Сравнение со строчным хранением

Интересные факты

• В 2015 году компания Google объявила, что столбцовое хранение в BigQuery позволяет обрабатывать петабайты данных за секунды благодаря массовому параллелизму и сжатию.
• Формат Apache Parquet был разработан совместно инженерами Twitter и Cloudera в 2013 году и сейчас поддерживается десятками систем.
• В некоторых колоночных СУБД (например, Vertica) данные хранятся в отсортированном порядке по одному или нескольким столбцам, что дополнительно ускоряет фильтрацию и агрегации.

Критика

Основным недостатком столбцового хранения считается его непригодность для транзакционных систем. Попытки создать универсальную СУБД, эффективно работающую как с OLTP, так и с OLAP (Hybrid Transactional/Analytical Processing, HTAP), привели к появлению гибридных архитектур (например, SAP HANA), где данные хранятся одновременно в строчном и столбцовом формате, что увеличивает сложность и требования к ресурсам.

Источники

• Stonebraker, M. et al. (2005). C-Store: A Column-oriented DBMS. Proceedings of VLDB.
• Abadi, D. J. et al. (2008). Column-Stores vs. Row-Stores: How Different Are They Really? SIGMOD.
• Документация ClickHouse: «Столбцовое хранение данных».
• Документация Apache Parquet: «Параметры хранения и сжатия».
• Microsoft Docs: «Columnstore Indexes — Overview».