Версия сайта для слабовидящих
Как устроены по-настоящему мультимодельные базы данных, чем они отличаются от реляционных и 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
Ближайшая дата курса
17 июня, 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 в Москве:
Источники
