Колоночное хранение данных
Колоночное хранение данных, Столбцовое хранение данных — способ организации хранения в базах данных, когда данные хранятся не построчно (строка за строкой), а постолбцово.
Наиболее эффективно показывают себя в случае работы с большими сериями быстрых операций на запись (особенно — в случае временных рядов, работе с данными с меткой времени), например непрерывным потоком данных от автоматизированных датчиков, устройств слежения за транспортом (например, БСМТС), финансовыми транзакциями. С этими особенностями связана популярность данных решений в сферах АСУТП, финтехе, мониторинге транспортной обстановки.
Эффективен при операциях выборках данных из небольшого подмножества столбцов с последующей их постолбцовой обработкой, а также для сжатия данных (так как в столбцах зачастую хранятся повторяющиеся или близкие данные). Может быть эффективно реализована вставка большого количества строк, но при этом операции одиночной вставки, обновления и удаления при столбцовом хранении менее эффективны, чем в строчном.
Относительно хуже себя показывают на операциях удаления произвольных записей.
Колоночная (Столбцовая) СУБД[править | править код]
Столбцовая СУБД — система управления базами данных, поддерживающая столбцовое хранение. Традиционные реляционные СУБД обычно используют строчное хранение, что эффективно для OLTP-сценариев, тогда как для OLAP-нагрузки столбцовое хранение обеспечивает, как правило, лучшую производительность.
Среди реляционных столбцовых СУБД — Teradata Database, Netezza, Sybase IQ, kdb, C-Store (и её потомок Vertica[англ.]), Greenplum, Hana, ParAccel[англ.] (и её потомок Amazon Redshift), MonetDB, ClickHouse. В ряде традиционных реляционных СУБД реализованы средства столбцового хранения (Oracle Database, MS SQL Server, MariaDB), либо существуют дополнения (например, Citus для PostgreSQL). Основные форматы Hadoop — RCFIle, [[Apache ORC}}, Apache Parquet, Apache Arrow — также используют столбцовую организацию. Столбцовыми СУБД являются ряд систем, ориентированных на работу со временными рядами (InfluxDB, Apache Druid).
Особенности реализации[править | править код]
Ключевым, хотя и скорее техническим отличием от классических реляционных СУБД является ориентация на максимально быстрые операции записи (или сохранения в память) серий событий. Для этого в большинстве колоночных СУБД предусмотрены механизмы хранения данных в физическом порядке поступления, при котором новая порция записей максимально быстро добавляется в конец ("хвост") соответствующей области памяти (файла).
Простой пример. Допустим, предусмотрено что запись состоит из 3 полей - метка времени, номер датчика, показатель (например, температура в градусах Кельвина). Для хранения создается 3 отдельных файла, и при поступлении входящего потока от набора датчиков СУБД разделяет соответствующую информацию на 3 отдельных операции добавления в конец каждого из трех файлов - отдельно массив меток времени, отдельно массив номеров датчиков, отдельно собственно показателей. Сама структура данных (время-датчик-градусы) оказывается распределенной по 3м файлам, но так как число строк в каждом файле одинаково, это дает возможность извлекать из них произвольные наборы записей для последующего анализа.
Ключевым показателем оптимальности в данном примере является то, что время добавления данных прямо пропорционально только объему серии, и ограничено практически только скоростью работы хранилища данных на запись. Для классических СУБД время массового добавления серии данных растет нелинейно[1].
Из описанного механизма становятся очевидны ключевые особенности столбцового хранения:
| Преимущества | Недостатки |
|---|---|
| очень быстрое добавление серии новых записей | значительно более медленное удаление либо редактирование произвольных записей (т.к. каждое удаление из середины файла приводит к необходимости сдвинуть все следующие записи во всех файлах) |
| очень быстрые выборки по ключевому признаку (например, "все записи за период") | более медленные выборки по произвольному признаку |
В случае, если столбцовая (колоночная) СУБД поддерживает четкую структуру полей и язык SQL, их можно трактовать как классические SQL СУБД. В случае если база поддерживает неструктурированные поля (например, хранение фотографий с меткой времени сьемки), их можно трактовать как NoSQL или документо-ориентированные СУБД, но это различие не принципиально[2]. Существуют реализации механизмов хранения данных для некоторых распространенных реляционных СУБД, которые добавляют к ним режимы работы столбцового хранения (например, cstore fdw,[3] vops[4] для PostgreSQL или ColumnStore[5] для MariaDB).
Некоторые вендоры ориентированы на использование с их СУБД не SQL языка, а языка векторной обработки данных (например специализированный язык K для базы kdb).
Форматы хранения данных[править | править код]
Начиная с 2010ых годов получили широкое распространение универсальные колоночные форматы данных, такие как Parquet, ORC, RCFile и ряд других. Несмотря на то, что большинство из них изначально было связано с инфраструктурой Hadoop, были выпущены многочисленные библиотеки, фреймворки обработки данных, позволяющих использовать эти форматы напрямую в прикладном программном обеспечении.