Как устроены по-настоящему мультимодельные базы данных, чем они отличаются от реляционных и 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
Ближайшая дата курса
2 декабря, 2024
Продолжительность
32 ак.часов
Стоимость обучения
96 000 руб.
Обзор OrientDB
OrientDB, разработанная в 2010 году, позиционируется как мультимодельная СУБД с открытым исходным кодом, которая поддерживает графовую и документо-ориентированную модели хранения данных, а также ключ-значение и объектно-ориентированное хранилище. OrientDB в целом поддерживает SQL-подобный синтаксис, расширяя его для поддержки концепций графов. Эта СУБД не поддерживает JOIN-операторы, управляя отношениями через хранение прямых ссылок на целевые объекты отношения вместо вычисления JOIN. Это повышает скорость загрузки всего графа связанных объектов, например, в графовых и объектно-оринетированных базах.
Разработчики OrientDB подчеркивают, что она является по-настоящему мультимодельной, поскольку объединяет все функции четырех моделей данных в одно ядро. Эти возможности представляют собой не только интерфейсы к механизму базы данных, но и сам механизм был создан для поддержки всех моделей. Как уже было отмечено ранее, многие СУБД, заявляющие о поддержке нескольких моделей данных, на самом деле имеют только одну базовую модель, а другие модели реализуют через дополнительные уровни API, имитирующие их.
Чтобы показать, как OrientDB реализует мультимодельность, представим сопоставления концепций разных моделей данных и их реализации в этой СУБД.
|
Классическое понятие в реляционной БД |
Реализация в OrientDB |
|||
|
Графовая модель |
Документо-ориентированная модель |
Модель ключ-значение |
Объектно-ориентированная модель |
|
|
Таблица |
Классы вершин и ребер графа |
Класс или кластер как форма группировки документов в коллекции. Концепция класса взята из ООП. В OrientDB классы определяют записи, подобно таблицам в реляционных базах данных. Классы могут быть без схемы, с полной схемой или смешанные. Они могут наследоваться от других классов, создавая дерево классов. Наследование в этом контексте означает, что подкласс расширяет родительский класс, наследуя все его атрибуты. У каждого класса есть свои кластеры (файлы данных) |
||
|
Строка |
Вершина графа |
Документ |
||
|
Столбец |
Свойство вершины/ ребра графа |
Поле документа |
Поле документа или свойство вершины/ ребра |
|
|
Отношение |
Ребро графа |
Связь, которая может быть ссылочной и встроенной. Для ссылочных связей OrientDB хранит прямые ссылки на целевые объекты отношения. А при встроенных отношениях отношения сохраняются в записи, которая их внедряет, подобно композиции в UML. Встроенные записи не имеют собственного идентификатора записи и доступны только через запись контейнера, — нельзя напрямую ссылаться на них через другие записи, в отличие от ссылочных. |
||
Сопоставление похожих концепций, реализуемых OrientDB в разных моделях данных, позволяет сказать, что эта СУБД использует объектную модель как основную, расширяя и адаптируя ее к графовым, документо-ориентированным и key-value сценариям. Таким образом, понятие истинной мультимодельности тоже реализуется с некоторыми оговорками.
Аналитика больших данных для руководителей
Код курса
BDAM
Ближайшая дата курса
13 января, 2025
Продолжительность
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 в Москве:
Источники
