Колоночное хранение данных: различия между версиями
| (не показаны 4 промежуточные версии этого же участника) | |||
| Строка 7: | Строка 7: | ||
Относительно хуже себя показывают на операциях удаления произвольных записей. | Относительно хуже себя показывают на операциях удаления произвольных записей. | ||
| − | == Столбцовая СУБД == | + | == Колоночная (Столбцовая) СУБД == |
Столбцовая СУБД — система управления базами данных, поддерживающая столбцовое хранение. Традиционные [[реляционная СУБД|реляционные СУБД]] обычно используют строчное хранение, что эффективно для [[OLTP]]-сценариев, тогда как для [[OLAP]]-нагрузки столбцовое хранение обеспечивает, как правило, лучшую производительность. | Столбцовая СУБД — система управления базами данных, поддерживающая столбцовое хранение. Традиционные [[реляционная СУБД|реляционные СУБД]] обычно используют строчное хранение, что эффективно для [[OLTP]]-сценариев, тогда как для [[OLAP]]-нагрузки столбцовое хранение обеспечивает, как правило, лучшую производительность. | ||
| − | Среди реляционных столбцовых СУБД — [[Teradata Database]], [[Netezza]], [[Sybase IQ]], [[kdb]], [[C-Store]] (и её потомок {{iw|Vertica}}), [[Greenplum]], [[Hana]], {{iw|ParAccel}} (и её потомок [[Amazon Redshift]]), [[MonetDB]], [[ClickHouse]]. В ряде традиционных реляционных СУБД реализованы средства столбцового хранения ([[Oracle Database]], [[Microsoft SQL Server|MS SQL Server]], [[MariaDB]]), либо существуют дополнения (например, Citus для [[PostgreSQL]]). Основные форматы Hadoop — | + | Среди реляционных столбцовых СУБД — [[Teradata Database]], [[Netezza]], [[Sybase IQ]], [[kdb]], [[C-Store]] (и её потомок {{iw|Vertica}}), [[Greenplum]], [[Hana]], {{iw|ParAccel}} (и её потомок [[Amazon Redshift]]), [[MonetDB]], [[ClickHouse]]. В ряде традиционных реляционных СУБД реализованы средства столбцового хранения ([[Oracle Database]], [[Microsoft SQL Server|MS SQL Server]], [[MariaDB]]), либо существуют дополнения (например, Citus для [[PostgreSQL]]). Основные форматы Hadoop — [[RCFIle]], [[Apache ORC}}, [[Apache Parquet]], [[Apache Arrow]] — также используют столбцовую организацию. Столбцовыми СУБД являются ряд систем, ориентированных на работу со временными рядами ([[InfluxDB]], [[Apache Druid]]). |
| + | |||
| + | == Особенности реализации== | ||
| + | Ключевым, хотя и скорее техническим отличием от классических реляционных СУБД является ориентация на максимально быстрые операции записи (или сохранения в память) серий событий. Для этого в большинстве колоночных СУБД предусмотрены механизмы хранения данных в физическом порядке поступления, при котором новая порция записей максимально быстро добавляется в конец ("хвост") соответствующей области памяти (файла). | ||
| + | |||
| + | Простой пример. Допустим, предусмотрено что запись состоит из 3 полей - метка времени, номер датчика, показатель (например, температура в градусах Кельвина). Для хранения создается 3 отдельных файла, и при поступлении входящего потока от набора датчиков СУБД разделяет соответствующую информацию на 3 отдельных операции добавления в конец каждого из трех файлов - отдельно массив меток времени, отдельно массив номеров датчиков, отдельно собственно показателей. Сама структура данных (время-датчик-градусы) оказывается распределенной по 3м файлам, но так как число строк в каждом файле одинаково, это дает возможность извлекать из них произвольные наборы записей для последующего анализа. | ||
| + | |||
| + | Ключевым показателем оптимальности в данном примере является то, что время добавления данных прямо пропорционально только объему серии, и ограничено практически только скоростью работы хранилища данных на запись. Для классических СУБД время массового добавления серии данных растет нелинейно<ref>[https://clickhouse.com/benchmark/dbms/ ClickBench — a Benchmark For Analytical DBMS]</ref>. | ||
| + | |||
| + | Из описанного механизма становятся очевидны ключевые особенности столбцового хранения: | ||
| + | {| class="wikitable" | ||
| + | |||
| + | ! Преимущества !! Недостатки | ||
| + | |- | ||
| + | | очень быстрое добавление серии новых записей || значительно более медленное удаление либо редактирование произвольных записей (т.к. каждое удаление из середины файла приводит к необходимости сдвинуть все следующие записи во всех файлах) | ||
| + | |- | ||
| + | | очень быстрые выборки по ключевому признаку (например, "все записи за период") || более медленные выборки по произвольному признаку | ||
| + | |||
| + | |} | ||
| + | |||
| + | В случае, если столбцовая (колоночная) СУБД поддерживает четкую структуру полей и язык [[SQL]], их можно трактовать как классические SQL СУБД. В случае если база поддерживает неструктурированные поля (например, хранение фотографий с меткой времени сьемки), их можно трактовать как [[NoSQL]] или документо-ориентированные СУБД, но это различие не принципиально<ref>[https://habr.com/ru/post/413051/ Колоночные СУБД против строчных, как насчет компромисса?]</ref>. Существуют реализации механизмов хранения данных для некоторых распространенных реляционных СУБД, которые добавляют к ним режимы работы столбцового хранения (например, [[cstore fdw]],<ref>{{cite web|url=https://github.com/citusdata/cstore_fdw|title=Columnar store for analytics with PostgreSQL}}</ref> [[vops]]<ref>{{cite web|url=https://github.com/postgrespro/vops|title=Vectorized Operations extension for PostgreSQL}}</ref> для [[PostgreSQL]] или ColumnStore<ref>{{cite web|url=https://mariadb.com/kb/en/mariadb-columnstore/|title=MariaDB ColumnStore}}</ref> для [[MariaDB]]). | ||
| + | |||
| + | Некоторые вендоры ориентированы на использование с их СУБД не SQL языка, а языка векторной обработки данных (например специализированный язык [[K (язык программирования)|K]] для базы kdb). | ||
| + | |||
| + | == Форматы хранения данных == | ||
| + | Начиная с 2010ых годов получили широкое распространение универсальные колоночные форматы данных, такие как [[Parquet]], [[ORC]], [[RCFile]] и ряд других. Несмотря на то, что большинство из них изначально было связано с инфраструктурой Hadoop, были выпущены многочисленные библиотеки, фреймворки обработки данных, позволяющих использовать эти форматы напрямую в прикладном программном обеспечении. | ||
| + | |||
| + | == Примеры == | ||
| + | * [[Apache Druid]] | ||
| + | * [[C-Store]] | ||
| + | * [[ClickHouse]] | ||
| + | * [[Greenplum]] | ||
| + | * [[InfluxDB]] | ||
| + | * [[MonetDB]] | ||
| + | * [[K (язык программирования)|kdb]] | ||
| + | * [[Amazon Redshift]] | ||
== Ссылки == | == Ссылки == | ||
* [https://codedocs.org/what-is/column-oriented-dbms Column-oriented DBMS] | * [https://codedocs.org/what-is/column-oriented-dbms Column-oriented DBMS] | ||
| + | |||
| + | == Примечания == | ||
| + | <references /> | ||
| + | [[Категория:СУБД]] | ||
| + | [[Категория:Анализ временных рядов]] | ||
| + | [[Категория:Колоночные форматы хранения данных]] | ||
| + | [[Категория:Форматы хранения данных]] | ||
| + | |||
{{Databases}} | {{Databases}} | ||
| − | |||
Текущая версия от 03:14, 25 сентября 2024
Колоночное хранение данных, Столбцовое хранение данных — способ организации хранения в базах данных, когда данные хранятся не построчно (строка за строкой), а постолбцово.
Наиболее эффективно показывают себя в случае работы с большими сериями быстрых операций на запись (особенно — в случае временных рядов, работе с данными с меткой времени), например непрерывным потоком данных от автоматизированных датчиков, устройств слежения за транспортом (например, БСМТС), финансовыми транзакциями. С этими особенностями связана популярность данных решений в сферах АСУТП, финтехе, мониторинге транспортной обстановки.
Эффективен при операциях выборках данных из небольшого подмножества столбцов с последующей их постолбцовой обработкой, а также для сжатия данных (так как в столбцах зачастую хранятся повторяющиеся или близкие данные). Может быть эффективно реализована вставка большого количества строк, но при этом операции одиночной вставки, обновления и удаления при столбцовом хранении менее эффективны, чем в строчном.
Относительно хуже себя показывают на операциях удаления произвольных записей.
Колоночная (Столбцовая) СУБД[править | править код]
Столбцовая СУБД — система управления базами данных, поддерживающая столбцовое хранение. Традиционные реляционные СУБД обычно используют строчное хранение, что эффективно для 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, были выпущены многочисленные библиотеки, фреймворки обработки данных, позволяющих использовать эти форматы напрямую в прикладном программном обеспечении.