Мультимодельные базы данных: мифы и реальность на примере 3-х СУБД

архитектура больших данных хранилища базы СУБД, NoSQL мультимодельные базы данных примеры, курсы обучение, архитектура данных, графы примеры курсы обучение, обработка графов и документов в Greenplum и PostgreSQL, обучение Greenplum Arenadata DB курсы, Greenplum для инженеров данных и и разработчиков, хранение и аналитика больших данных с Greenplum, Школа Больших Данных Учебный центр Коммерсант

Как устроены по-настоящему мультимодельные базы данных, чем они отличаются от реляционных и NoSQL-СУБД, а также какова истинная природа универсального подхода к хранению и оперированию данными. Разбираемся на примере ArangoDB, OrientDB и Cosmos DB.

Что такое мультимодельная СУБД и зачем она нужна

Любая технология предназначена, прежде всего, для решения конкретных проблем, с которыми она справляется лучше других аналогов. Например, реляционные СУБД (MySQL, PostgreSQL, Greenplum и пр.) отлично подходят для хранения данных с жесткой и сложной схемой в OLTP и OLAP-сценариях. Графовые базы (Neo4j, TigerGraph, Memgraph) позволяют работать с графами знаний в задачах анализа отношений и поиска путей. Документо-ориентированные базы данных (MongoDB, CouchDB) хорошо работают с JSON- и XML-документами, а быстрые key-value (Redis, RocksDB, Riak, DynamoDB) и wide-column (Apache HBase, Cassandra) реализуют сценарии оперативного доступа к большим данным с примитивной структурой.

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

Чтобы уменьшить сложность архитектуры данных, в 2010-х годах возникли мультимодельные СУБД, объединяющие несколько моделей хранения данных в одном решении. Не стоит путать мультимодельные СУБД с технологиями, поддерживающими несколько моделей хранения данных. Например, PostgreSQL и Greenplum изначально представляют собой классические реляционные базы, но с помощью расширений Apache AGE и MADlib могут работать с графами, о чем мы писали здесь. Также эти СУБД поддерживают тип данных JSON, что характерно, прежде всего, для документо-ориентированных баз данных. Впрочем, под капотом этих дополнительных возможностей по-прежнему работает первичная модель хранения данных, например, в виде таблиц, связанных по внешнему ключу. При этом производительность дополнительных сценариев использования вторичных моделей данных будет намного ниже чем в специализированных решениях. В частности, здесь мы разбирали, почему нативные графовые базы данных намного быстрее реляционных и документо-ориентированных решений в задачах графовой аналитики.

Считается, что по-настоящему мультимодельные СУБД лишены таких недостатков, будучи изначально спроектированы без привязки к конкретной модели данных. Сегодня наиболее известными из таких хранилищ считаются ArangoDB, OrientDB и Cosmos DB. Далее рассмотрим, что они собой представляют и действительно ли являются истинно мультимодельными.

Знакомство с ArangoDB

Впервые представленная широкой публике в 2011 году ArangoDB (ранее AvocadoDB) позиционируется как мультимодельная СУБД, которая поддерживает три модели данных: графовую, документную и ключ-значение. ArangoDB также имеет встроенный движок полнотекстового поиска с рейтингом релевантности, подобно Elasticsearch или Apache Solr. Примечательно, что вместо стандартного SQL в этой СУБД используется собственный язык запросов AQL, который немного похож на SQL и тоже является декларативным, однако, позволяет работать одновременно со всеми моделями данных в одном запросе. Впрочем, на самом деле ArangoDB хранит графы и документы в виде объектов JSON, которые можно организовать в коллекции и базы данных, как это сделано в MongoDB: документы (записи данных) в хранятся коллекциях, аналогично таблицам реляционной БД.

Официальная документация сообщает, что модель данных ключ-значение в ArangoDB является подмножеством документо-ориентированной модели данных: у каждого документа есть атрибут _key, который идентифицирует документ в коллекции, действуя как первичный ключ для извлечения данных. Аналогично графы из вершин и ребер являются документами в ArangoDB: ребра имеют два специальных атрибута _from и _to, которые ссылаются на исходную и целевую вершины по их идентификаторам документа. Можно хранить вершины и ребра с любым количеством свойств, поскольку они являются полноценными JSON-документами.

Внутри ArangoDB документы JSON преобразуются в собственный двоичный формат хранения VelocyPack. Несмотря на это, производительность ArangoDB не слишком высокая: на больших объемах данных эта система начинает тормозить из-за неоптимального выполнения операций дискового ввода-вывода.

Таким образом, разработчики ArangoDB, которые позиционируют ее как истинно мультимодельную СУБД, немного лукавят: это скорее документо-ориентированное решение, поддерживающее работу с ключами/значениями и графами в парадигме JSON-документов.

Практическое применение Big Data аналитики для решения бизнес-задач

Код курса
PRUS
Ближайшая дата курса
15 июля, 2024
Продолжительность
32 ак.часов
Стоимость обучения
96 000 руб.

Обзор OrientDB

OrientDB, разработанная в 2010 году, позиционируется как мультимодельная СУБД с открытым исходным кодом, которая поддерживает графовую и документо-ориентированную модели хранения данных, а также ключ-значение и объектно-ориентированное хранилище. OrientDB в целом поддерживает SQL-подобный синтаксис, расширяя его для поддержки концепций графов. Эта СУБД не поддерживает JOIN-операторы, управляя отношениями через хранение прямых ссылок на целевые объекты отношения вместо вычисления JOIN. Это повышает скорость загрузки всего графа связанных объектов, например, в графовых и объектно-оринетированных базах.

Разработчики OrientDB подчеркивают, что она является по-настоящему мультимодельной, поскольку объединяет все функции четырех моделей данных в одно ядро. Эти возможности представляют собой не только интерфейсы к механизму базы данных, но и сам механизм был создан для поддержки всех моделей. Как уже было отмечено ранее, многие СУБД, заявляющие о поддержке нескольких моделей данных, на самом деле имеют только одну базовую модель, а другие модели реализуют через дополнительные уровни API, имитирующие их. 

Чтобы показать, как OrientDB реализует мультимодельность, представим сопоставления концепций разных моделей данных и их реализации в этой СУБД.

Классическое понятие в реляционной БД

Реализация в OrientDB

Графовая модель

Документо-ориентированная модель

Модель ключ-значение

Объектно-ориентированная модель

Таблица

Классы вершин и ребер графа

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

Строка

Вершина графа

Документ

Столбец

Свойство вершины/ ребра графа

Поле документа

Поле документа или свойство вершины/ ребра

Отношение

Ребро графа

Связь, которая может быть ссылочной и встроенной. Для ссылочных связей OrientDB хранит прямые ссылки на целевые объекты отношения. А при встроенных отношениях отношения сохраняются в записи, которая их внедряет, подобно композиции в UML. Встроенные записи не имеют собственного идентификатора записи и доступны только через запись контейнера, — нельзя напрямую ссылаться на них через другие записи, в отличие от ссылочных.

Сопоставление похожих концепций, реализуемых OrientDB в разных моделях данных, позволяет сказать, что эта СУБД использует объектную модель как основную, расширяя и адаптируя ее к графовым, документо-ориентированным и key-value сценариям. Таким образом, понятие истинной мультимодельности тоже реализуется с некоторыми оговорками.

Аналитика больших данных для руководителей

Код курса
BDAM
Ближайшая дата курса
1 июля, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.

Ликбез по Cosmos DB

Cosmos DB от Azure позиционируется как полностью управляемая мультимодельная СУБД почти мгновенным откликом в миллисекундах и автоматической масштабируемостью. Поддержка реляционных и нереляционных моделей данных реализуется в Cosmos DB с помощью разных API для MongoDB, PostgreSQL, Cassandra, Gremlin и Table. С помощью этих API можно моделировать данные на основе документов, пар ключ-значение, графов и моделей данных семейства столбцов.

Изначально API Cosmos DB для NoSQL хранит данные в формате документа, обеспечивая поддержку запросов к объектам JSON с помощью SQL. Для MongoDB API Cosmos DB хранит данные в структуре документа в формате BSON (бинарный JSON), который совместим с протоколом MongoDB.

Для PostgreSQL в Azure Cosmos DB есть API, созданный на основе оригинального PostgreSQL и отлично подходит для работы с локальной базой данных с поддержкой индексирования, геопространственных возможностей и JSONB. Для кластеров PostgreSQL используется расширение Citus, которое добавляет поддержку для распространения данных и распределенных транзакций.

Для Cassandra, которая является представителем семейства колонок, API Azure Cosmos DB хранит данные в схеме, ориентированной на столбцы, и является протоколом, совместимым с собственным API Cassandra.

Для работы с графами API Cosmos DB использует язык Gremlin, который позволяет создавать хранить данные в виде ребер и вершин и запрашивать их. API для Gremlin основан на платформе вычислений графа Apache TinkerPop. Наконец, для key-value модели в Cosmos DB есть табличный API, который хранит данные в формате ключ-значение.

Таким образом, назвать Cosmos DB по-настоящему мультимодельной базой данных тоже можно лишь с большой натяжкой: скорее, это надстройка над различными решениями, которая позволяет взаимодействовать с ними через уровень API.

Рассмотренные особенности СУБД, которые позиционируются как мультимодельные, позволяют сделать вывод, что истинная мультимодельность – это скорее миф, чем реальность, поскольку дополнительные модели хранения данных все равно реализуются через одну основную.

Узнайте больше подробностей по проектированию и поддержке современных дата-архитектур в проектах аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://habr.com/ru/articles/462493/
  2. https://www.arangodb.com/docs/stable/
  3. https://brainhub.eu/library/arangodb-use-case
  4. http://orientdb.org/docs/3.0.x/misc/Overview.html
  5. https://learn.microsoft.com/ru-ru/azure/cosmos-db/introduction
Поиск по сайту