Я работал со многими формами данных на протяжении своей карьеры. За это время мне приходилось создавать или запрашивать существующие базы данных для получения статистических данных. Традиционные базы данных обычно предназначены для быстрого запроса конкретных данных из базы данных и поддержки транзакционных операций. Хотя существует возможность работать со статистическими агрегатами, они обычно не очень быстры. Особенно, когда вы работаете с базами данных, содержащими сотни миллионов строк.

Для поддержки чисто аналитического доступа к базе данных было создано колоночное хранение.

Чем полезно колоночное хранение?

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

Этот подход  оптимален, когда вы ищете некоторую или большую часть информации в записи или строке. Это не очень удобно, если вы хотите вычислить статистику по определенному столбцу. Если бы я хотел вычислить средний возраст в приведенной выше таблице, мне пришлось бы читать и передавать всю информацию об ID и именах, чтобы получить информацию о возрасте, которая сама может быть легко сохранена в одном байте для каждой записи. Что делает колоночное хранение, так это устанавливает значение в имени. Вместо хранения данных в строках или записях данные хранятся в столбцах. Таким образом, когда вы хотите вычислить средний возраст, вам нужно только прочитать данные с информацией о возрасте в памяти, а не все данные в каждой строке. Хранимые данные в итоге выглядят примерно так:

Колоночное хранение не подходит для транзакционных операций или выбора содержимого определенной строки или записи, но оно отлично подходит для создания статистики по определенному столбцу в таблице.

Если вы собираетесь хранить данные в столбцах, а не в строках, стоимость одиночных вставок очень высока, а количество необработанных байтов намного больше, чем вы обычно храните. Большинство колоночных хранилищ традиционно загружаются партиями, которые могут оптимизировать процесс хранения столбцов, и данные практически всегда сжимаются на диске для преодоления увеличенного объема данных, которые необходимо сохранить. В дополнение к сжатию большинство современных  колоночных хранилищ хранят данные столбцов в блоках с несколькими предварительно вычисленными статистическими данными, которые заставляют запросы работать намного быстрее, позволяя производить вычисления, которые выдают гораздо меньше данных.

В качестве примера того, какую разницу в производительности может обеспечить колоночное хранение, приведу историю из личного опыта. В прошлом году я работал с клиентской базой данных, содержащей двадцать миллионов записей, связанных с информацией о покупке. Типичный запрос на покупку в таблицу заказов с использованием  MySQL MyISAM займет 30-40 минут. Те же запросы с использованием MariaDB AX (вариант колоночного хранения MySQL) занимали от 0,1 секунды до 8 секунд.

Это технология, которая отображает возможности BI в реальном времени.

Два вида колоночных хранилищ

Оказывается, существует два очень разных типа колоночных баз данных.

Cassandra и HBase хранят каждый столбец отдельно по причинам, сильно отличающихся от других колоночных хранилищ. В результате производительность тоже сильно отличается. Концепция колоночных баз данных HBase и Cassandra не предполагает проведение быстрого анализа. Вместо этого они хранят отдельные столбцы, сгруппированные вместе, чтобы поддерживать свою распределенную таблицу (большую таблицу) и быструю запись. Когда вы слышите или читаете рекомендации об этих типах баз данных как о колоночных, помните, что они не обеспечат вам должную аналитическую производительность. Поскольку и Hbase, и Cassandra так плохи в отношении аналитики, они не поддерживают большинства возможностей построения агрегатов в целом.

Некоторые примеры специфических колоночных баз данных с открытым исходным кодом.

Несмотря на то, что существует много примеров запатентованных колоночных баз данных, поскольку я глубоко вовлечен в мир открытого исходного кода, мои примеры связаны именно с таким типом баз данных.

MariaDB AX

MariaDB AX является относительным новичком в мире колоночного хранения, хотя исходный код, который они используют, существует довольно давно. Корпорация MariaDB приняла кодовую базу от Infinidb: https://en.wikipedia.org/wiki/InfiniDB

MariaDB AX использует интерфейс движка хранилища, чтобы позволить пользователям использовать диалект MySQL SQL для распределенного колоночного хранилища. Одной из приятных особенностей использования MariaDB AX является создание таблиц с использованием механизма хранения Transactional InnoDB и объединение транзакционных и аналитических рабочих нагрузок в одной и той же базе данных. Хотя вы не будете проводить их в одних и тех же таблицах.

Parquet

Parquet это не база данных. Это файловый формат, который можно использовать для хранения таблиц базы данных в распределенных файловых системах, таких как HDFS, CEPH или AWS S3. Данные хранятся в Parquet  в областях, которые содержат блоки данных столбцов, позволяющие разбить файл Parquet. Хранение файла на многих распределенных хостах позволяет ему осуществлять параллельную обработку. Вы можете получить доступ к файлам Parquet, используя Apache Spark, Hive, Pig, Apache Drill и Impala Cloudera.

Clickhouse

Clickhouse была создана российской компанией Yandex для поддержки своих собственных внутренних требований по предоставлению аналитики своим клиентам. В отличие от MariaDB AX или Parquet у него есть собственный диалект SQL и его собственные API. Тем не менее, он быстро становится очень популярным, потому что он очень быстрый.

Citus Data

Корпорация Citus Data строит расширения для PostgreSQL. Одним из расширений, благодаря которым известен Citus Data , является расширение распределенного кластера, которое превращает PostgreSQL в базу данных распределенного кластера. Другое - функция хранения гибридных столбцов, которая позволяет вам выбирать некоторые таблицы в столбце базы данных PostgreSQL, что позволяет хранить остальные в старой дружественной транзакционной модели.

Greenplum

Бизнес Greenplum долгое время относился к сфере BI и хранилищу данных. Их продукт, такой как Citus Data, основан на PostgreSQL. Хотя есть гораздо более старая версия PostgreSQL. Они предлагают как проприетарную версию, так и версию с открытым исходным кодом.

Все остальные

Те, что я перечислил здесь, это те, с которыми я имел дело в последние пару лет. Есть несколько технологий баз данных в категории хранилища столбцов, которые я здесь не упоминал, но вы можете узнать о них здесь: https://en.wikipedia.org/wiki/List_of_column-oriented_DBMSes

Заключение

Колоночные базы данных хранят данные в столбцах вместо строк. Они позволяют вычислять статистику по этим столбцам на один-два порядка или больше, быстрее, чем это делается на традиционных, основанных на строках, базах данных.

Столбцово-ориентированная таблица очень хороша для аналитики, но обычно ужасна для традиционных транзакционных нагрузок.

Большинство, хотя и не все, колоночные хранилища предназначены для работы на распределенном кластере серверов

No Comments