Колоночное хранение

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

История

Концепция колоночного хранения была впервые реализована в академических и ранних коммерческих системах, ориентированных на анализ данных, в 1970-х годах. Одной из первых известных систем стала C-Store, разработанная в Массачусетском технологическом институте (MIT) и впоследствии коммерциализированная в Vertica. Однако широкое распространение колоночные СУБД получили в 2000-х годах с ростом объёмов данных и потребностей в быстрой аналитике. Ключевыми драйверами стали проекты с открытым исходным кодом, такие как MonetDB (начало 2000-х) и Apache Parquet (формат файлов, 2013 год), а также коммерческие продукты: Amazon Redshift (2012), Google BigQuery (2010), ClickHouse (разработан в компании Яндекс, 2016). В настоящее время колоночное хранение является стандартом де-факто для большинства современных аналитических СУБД и систем обработки больших данных (Big Data).

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

При строчном хранении (row-oriented) данные на диске организованы следующим образом: последовательно записываются все поля первой записи, затем все поля второй и так далее. При колоночном хранении (column-oriented) данные на диске организованы иначе: сначала записываются все значения первого столбца, затем все значения второго столбца и так далее.

Пример

Рассмотрим таблицу «Продажи»:

Строчное хранение (на диске): 1, Телефон, Электроника, 15000, 2024-01-10, 2, Книга, Книги, 800, 2024-01-11, 3, Ноутбук, Электроника, 55000, 2024-01-12.

Колоночное хранение (на диске): 1, 2, 3, Телефон, Книга, Ноутбук, Электроника, Книги, Электроника, 15000, 800, 55000, 2024-01-10, 2024-01-11, 2024-01-12.

Характеристики и преимущества

Производительность запросов

Колоночное хранение значительно ускоряет выполнение аналитических запросов, которые затрагивают лишь несколько столбцов из многих. Например, запрос «Посчитать сумму продаж по категории "Электроника"» при колоночном хранении считывает с диска только столбцы Цена и Категория. При строчном хранении пришлось бы считать все столбцы всех строк, что приводит к избыточному вводу-выводу (I/O) и снижению производительности.

Сжатие данных

Значения одного столбца, как правило, имеют одинаковый тип данных и часто повторяются (высокая кардинальность или низкая). Это позволяет применять эффективные алгоритмы сжатия, такие как:

• RLE (Run-Length Encoding): сжатие повторяющихся значений.
• Delta-encoding: хранение разниц между последовательными значениями.
• Dictionary encoding: замена уникальных значений на короткие коды (словарь).
• Bit-packing: упаковка битов для экономии места.

Сжатие данных в колоночных СУБД может достигать коэффициента 5–10 раз и более по сравнению со строчным хранением, что снижает требования к дисковому пространству и ускоряет операции чтения.

Векторизация

Колоночные СУБД часто используют векторизованную обработку данных (vectorized processing). Вместо обработки одной строки за раз (как в строчных СУБД), они обрабатывают пакеты (векторы) значений одного столбца. Это позволяет эффективно использовать SIMD-инструкции (Single Instruction, Multiple Data) современных процессоров, что даёт дополнительный прирост производительности.

Недостатки

Производительность на запись и обновление

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

• Буферные таблицы (in-memory delta stores): новые данные сначала записываются в небольшую строчную структуру в оперативной памяти, а затем периодически сливаются (merge) в основное колоночное хранилище.
• Партиционирование: данные разбиваются на сегменты, и запись происходит только в один сегмент.

Сложность реализации

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

Классификация колоночных СУБД

Колоночные системы можно разделить на несколько категорий:

По способу хранения

• Чисто колоночные (pure columnar): все данные физически хранятся по столбцам. Примеры: Vertica, MonetDB, ClickHouse.
• Гибридные (hybrid): данные могут храниться как по столбцам, так и по строкам, в зависимости от типа нагрузки. Примеры: Microsoft SQL Server (с опцией columnstore index), Oracle Database (с опцией In-Memory Column Store).

По архитектуре

• Однопроцессорные (shared-nothing): данные распределены между несколькими узлами, каждый из которых обрабатывает свою часть данных. Примеры: Amazon Redshift, Google BigQuery, ClickHouse.
• Многопроцессорные с общей памятью (shared-memory): все узлы имеют доступ к общей памяти. Примеры: SAP HANA.

Применение

Колоночное хранение является основой для большинства систем класса OLAP, используемых в:

• Бизнес-аналитика (BI): построение отчётов, дашбордов, анализ продаж, финансов, маркетинга.
• Хранилища данных (Data Warehousing): централизованное хранение и агрегация данных из различных источников.
• Обработка больших данных (Big Data): анализ логов, событий, потоковых данных в реальном времени.
• Научные вычисления: обработка геномных данных, климатических моделей, физических экспериментов.

Примеры колоночных СУБД

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

• ClickHouse (разработан в компании Яндекс) — одна из самых быстрых колоночных СУБД с открытым исходным кодом. Она способна обрабатывать запросы к таблицам с миллиардами строк за доли секунды.
• Apache Parquet — формат колоночного хранения, широко используемый в экосистеме Apache Hadoop и Apache Spark. Он поддерживает сложные вложенные структуры данных и эффективное сжатие.
• Колоночное хранение лежит в основе многих современных систем машинного обучения, так как позволяет быстро считывать подмножества признаков (features) для обучения моделей.

Критика

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

Источники

• Hellerstein, J. M., Stonebraker, M., & Hamilton, J. (2007). Architecture of a Database System. Foundations and Trends in Databases.
• Abadi, D. J., Boncz, P. A., & Harizopoulos, S. (2009). Column-oriented Database Systems. VLDB Journal.
• Документация ClickHouse (https://clickhouse.com/docs/ru).
• Документация Apache Parquet (https://parquet.apache.org/).
• Документация Amazon Redshift (https://docs.aws.amazon.com/redshift/).