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

Материал из in.wiki
Перейти к навигации Перейти к поиску

Колоночное хранение данных, Столбцовое хранение данных — способ организации хранения в базах данных, когда данные хранятся не построчно (строка за строкой), а постолбцово.

Наиболее эффективно показывают себя в случае работы с большими сериями быстрых операций на запись (особенно — в случае временных рядов, работе с данными с меткой времени), например непрерывным потоком данных от автоматизированных датчиков, устройств слежения за транспортом (например, БСМТС), финансовыми транзакциями. С этими особенностями связана популярность данных решений в сферах АСУТП, финтехе, мониторинге транспортной обстановки.

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

Относительно хуже себя показывают на операциях удаления произвольных записей.

Колоночная (Столбцовая) СУБД[править | править код]

Столбцовая СУБД — система управления базами данных, поддерживающая столбцовое хранение. Традиционные реляционные СУБД обычно используют строчное хранение, что эффективно для 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, были выпущены многочисленные библиотеки, фреймворки обработки данных, позволяющих использовать эти форматы напрямую в прикладном программном обеспечении.

Примеры[править | править код]

Ссылки[править | править код]

Примечания[править | править код]

  1. ClickBench — a Benchmark For Analytical DBMS
  2. Колоночные СУБД против строчных, как насчет компромисса?
  3. "Columnar store for analytics with PostgreSQL".
  4. "Vectorized Operations extension for PostgreSQL".
  5. "MariaDB ColumnStore".

Шаблон:Databases