Бюрократы, Проверяющие участников, importer, Администраторы интерфейса, interwiki, oversight, patroller, Администраторы (Semantic MediaWiki), steward, Скрывающие, Администраторы
8365
правок
Изменения
нет описания правки
Среди реляционных столбцовых СУБД — [[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 — {{iw|RCFIle}}, {{iw|ORC|||Apache ORC}}, {{iw|Parquet|||Apache Parquet}}, {{iw|Apache Arrow}} — также используют столбцовую организацию. Столбцовыми СУБД являются ряд систем, ориентированных на работу со временными рядами ([[InfluxDB]], [[Apache Druid]]).
Среди реляционных столбцовых СУБД — [[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 — {{iw|RCFIle}}, {{iw|ORC|||Apache ORC}}, {{iw|Parquet|||Apache Parquet}}, {{iw|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).
== Примеры ==
* [[Apache Druid]]
* [[C-Store]]
* [[ClickHouse]]
* [[Greenplum]]
* [[InfluxDB]]
* [[MonetDB]]
* [[K (язык программирования)|kdb]]
* [[Amazon Redshift]]
== Ссылки ==
== Ссылки ==