Сучасні інформаційні системи є досить складними. Не в останню чергу їх складність обумовлена ​​складністю даних, що обробляються в них. Складність даних часто полягає в різноманітті використовуваних моделей даних. Так, наприклад, коли дані стають «великими», однією з характеристик, що доставляють незручності, вважається не тільки їх обсяг («volume»), але і їх різноманітність («variety»).

Якщо ви поки що не знаходите вади в міркуваннях, то читайте далі.

Зміст

Наполегливість поліглота
Мультимедельність
Мультимодельні СУБД на основі реляційної моделі
     Документна модель у MS SQL Server
     Графової моделі в MS SQL Server
Мультимодельні СУБД на основі документної моделі
     Реляційна модель у MarkLogic
     Гракова модель в MarkLogic
Мультимодельні СУБД «без основної моделі»
     ArangoDB
     OrientDB
     Azure CosmosDB
Мультимодельні СУБД на основі графової моделі?
Висновок
Опитування

Наполегливість поліглота

Сказане вище призводить до того, що часом у межах однієї системи доводиться зберігання даних і розв'язання різних завдань із їхньої обробці використовувати кілька різних СУБД, кожна з яких підтримує свою модель даних. З легкої руки М. Фаулер, автора ряду відомих книг та одного з співавторів Agile Manifesto, така ситуація отримала назву багатоваріантного зберігання («Polyglot persistence»).

Фаулер належить і наступний приклад організації зберігання даних у повнофункціональному і високонавантаженому додатку у сфері електронної комерції.

Приклад цей, звичайно, трохи перебільшений, але деякі міркування на користь вибору тієї чи іншої СУБД для відповідної мети можна знайти, наприклад, тут.

Зрозуміло, що бути служителем у такому зоопарку нелегко.

• Обсяг коду, що виконує збереження даних, зростає пропорційно до числа використовуваних СУБД; обсяг коду, що синхронізує дані, - добре якщо не пропорційно квадрату цього числа.
• Кратко числу використовуваних СУБД зростають витрати на забезпечення enterprise-характеристик (масштабованості, стійкості до відмов, високої доступності) кожної з використовуваних СУБД.
• Неможливо забезпечити enterprise-характеристики підсистеми зберігання загалом — особливо транзакційність.

З погляду директора зоопарку все виглядає так:

• Кратне збільшення вартості ліцензій та техпідтримки від виробника СУБД.
• Роздуття штату та збільшення термінів.
• Прямі фінансові втрати чи штрафні санкції через неузгодженість даних.

Наявне значне зростання сукупної вартості володіння системою (TCO). Чи є із ситуації «багатоваріантного зберігання» якийсь вихід?

Мультимедельність

Термін «багатоваріантне зберігання» узвичаївся в 2011 році. Усвідомлення проблем підходу та пошук рішення зайняли кілька років, і до 2015 року вустами аналітиків Gartner відповідь була сформульована:

• з «Market Guide for NoSQL DBMSs - 2015'
  

  Майбутнє СУБД, їх архітектури та способи використання — мультимодельність.

• з «Magic Quadrant for ODBMS - 2016'
  

  Провідні операційні СУБД пропонуватимуть кілька моделей — реляційну та нереляційну — у складі єдиної платформи.

Схоже, що цього разу аналітики Gartner із прогнозом не помилилися. Якщо зайти на сторінку з основним рейтингом СУБД на DB-Engines, можна побачити, що боБільшість його лідерів позиціонує себе саме як мультимодельні СУБД. Те саме можна побачити і на сторінці з будь-яким приватним рейтингом.

У таблиці нижче наведено СУБД — лідерів у кожному з приватних рейтингів, які заявляють про свою мультимодельність. Для кожної СУБД вказані початкова модель, що підтримується (колись колишня єдиною) і поряд з нею моделі, що підтримуються зараз. Також наведено СУБД, які позиціонують себе як «спочатку мультимодельні», які не мають за заявами творців будь-якої початкової успадкованої моделі.

СУБД	Початкова модель	Додаткові моделі
оракул	Реляційна	Графова, документна
MS SQL	Реляційна	Графова, документна
PostgreSQL	Реляційна	Графова*, документна
MarkLogic	Документна	Графічна, реляційна
MongoDB	Документна	Ключ-значення, графова*
DataStax	Wide-column	Документна, графова
Redis	Ключ-значення	Документна, графова*
ArangoDB	-	Графова, документна
OrientDB	-	Графова, документна, реляційна
Azure CosmosDB	-	Графова, документна, реляційна

Примітки до таблиці

Зірочками в таблиці позначені твердження, що вимагають застережень:

• СУБД PostgreSQL не підтримує графову модель даних, проте її підтримує такий продукт на її основі, як, наприклад, AgensGraph.
• Стосовно MongoDB правильніше говорити швидше про наявність графових операторів у мові запитів ($lookup, $graphLookup), ніж про підтримку графової моделі, хоча, звісно, ​​їх запровадження зажадало деяких оптимізацій лише на рівні фізичного зберігання у бік підтримки графової моделі.
• Стосовно Redis мається на увазі розширення RedisGraph.

Далі для кожного із класів ми покажемо, як реалізується підтримка кількох моделей у СУБД із цього класу. Найбільш важливими вважатимемо реляційну, документну та графову моделі та на прикладах конкретних СУБД показувати, як реалізуються «недостачі».

Мультимодельні СУБД на основі реляційної моделі

Ведучими СУБД нині є реляційні, прогноз Gartner не можна було б вважати таким, що здійснилося, якби РСУБД не демонстрували руху в напрямку мультимодельності. І вони демонструють. Тепер міркування про те, що мультимодельна СУБД подібна до швейцарського ножа, яким нічого не можна зробити добре, можна направляти відразу Ларрі Еллісону.

Автору, проте, більше подобається реалізація мультимодельності в Microsoft SQL Server, з прикладу якого підтримка РСУБД документної і графової моделей і буде описано.

Документна модель у MS SQL Server

Про те, як у MS SQL Server реалізована підтримка документної моделі, на Хабрі вже було дві чудові статті, обмежусь коротким переказом та коментарем:

• Працюємо з JSON у SQL Server 2016
• SQL Server 2017 JSON

Спосіб підтримки документної моделі в MS SQL Server є досить типовим для реляційних СУБД: JSON-документи пропонується зберігати у звичайних текстових полях. Підтримка документної моделі полягає у наданні спеціальних операторів для розбору цього JSON:

• JSON_VALUE для отримання скалярних значень атрибутів,
• JSON_QUERY для отримання піддокументів.

Другим аргументом обох операторів є вираз у JSONPath-подібному синтаксисі.

Абстрактно можна сказати, що документи, що зберігаються таким чином, не є в реляційній СУБД «сутностями першого класу», на відміну від кортежів. Саме в MS SQL Server нині відсутні індекси по полях JSON-документів, що робить скрутними операції з'єднання таблиць за значеннями цих полів і навіть вибірку документів за цими значеннями. Втім, можливо створити за таким полем стовпець, що обчислюється, і індекс по ньому.

Додатково MS SQL Server надає можливість зручно конструювати JSON-документ із вмісту таблиць за допомогою оператора FOR JSON PATH - Можливість, у певному сенсі протилежну попередньої, звичайному зберіганню. Зрозуміло, що хоч би якою швидкою була РСУБД, такий підхід суперечить ідеології документних СУБД, які по суті зберігають готові відповіді на популярні запити, і може вирішувати лише проблеми зручності розробки, але не швидкодії.

Нарешті, MS SQL Server дозволяє вирішувати завдання, зворотне конструювання документа: можна розкласти JSON за таблицями за допомогою OPENJSON. Якщо документ не зовсім плоский, потрібно використовувати CROSS APPLY.

Графової моделі в MS SQL Server

Підтримка графової (LPG) моделі реалізована в Microsoft SQL Server теж цілком передбачувано: пропонується використовувати спеціальні таблиці для зберігання вузлів та зберігання ребер графа. Такі таблиці створюються з використанням виразів CREATE TABLE AS NODE и CREATE TABLE AS EDGE відповідно.

Таблиці першого виду подібні до звичайних таблиць для зберігання записів з тією лише зовнішньою відмінністю, що в таблиці є системне поле $node_id - Унікальний в межах бази даних ідентифікатор вузла графа.

Аналогічно, таблиці другого виду мають системні поля $from_id и $to_id, записи в таких таблицях зрозуміло задають зв'язки між вузлами. Для зберігання зв'язків кожного виду використовується окрема таблиця.

Проілюструємо сказане прикладом. Нехай графові дані мають схему як у наведеному малюнку. Тоді для створення відповідної структури у базі даних потрібно виконати наступні DDL-запити:

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

Основна специфіка таких таблиць полягає в тому, що в запитах до них можна використовувати графові патерни з Cypher-подібним синтаксисом (втім, «*» та ін. поки не підтримуються). На основі вимірювань продуктивності можна також припустити, що спосіб зберігання даних у цих таблицях відрізняється від механізму зберігання даних у звичайних таблицях та оптимізований для виконання подібних графових запитів.

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

Більше того, досить важко при роботі з такими таблицями ці графові патерни не використовувати, оскільки у звичайних SQL-запитах для вирішення аналогічних завдань потрібно докладати зусиль для отримання системних «графових» ідентифікаторів вузлів ($node_id, $from_id, $to_id; з цієї ж причини запити на вставку даних не наведені тут як надмірно громіздкі).

Підсумовуючи опис реалізацій документної та графової моделей в MS SQL Server, я б зазначив, що подібні реалізації однієї моделі поверх іншої не здаються вдалими в першу чергу з точки зору мовного дизайну. Потрібно розширювати одну мову іншою, мови не цілком «ортогональні», правила поєднання можуть бути досить химерні.

Мультимодельні СУБД на основі документної моделі

У цьому розділі хочеться проілюструвати реалізацію мультимодельності в документних СУБД на прикладі не найпопулярнішої з них MongoDB (як було сказано, в ній є лише умовно графові оператори $lookup и $graphLookup, які не працюють на шардованих колекціях), а на прикладі більш зрілої та «ентерпрайзної» СУБД MarkLogic.

Отже, нехай колекція містить набір XML-документів наступного виду (зберігати JSON-документи MarkLogic також дозволяє):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

Реляційна модель у MarkLogic

Реляційне представлення колекції документів можна створити за допомогою шаблон відображення (вміст елементів value у прикладі нижче може бути довільний XPath):

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

До створеного уявлення можна адресувати SQL-запит (наприклад, через ODBC):

SELECT name, surname FROM Person WHERE name="John"

На жаль, створене за допомогою шаблону відображення реляційне уявлення доступне лише для читання. Під час обробки запиту до нього MarkLogic спробує використати документні індекси. Насамперед у MarkLogic були й обмежені реляційні уявлення, цілком засновані на індексах і доступні для запису, але зараз вони вважаються deprecated.

Гракова модель в MarkLogic

З підтримкою графової (RDF) моделі все приблизно так само. Знов-таки за допомогою шаблон відображення можна створити RDF-представлення колекції документів із прикладу вище:

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

До отриманого RDF-графа можна адресувати SPARQL-запит:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

На відміну від реляційної, графову модель MarkLogic підтримує ще двома іншими способами:

1. СУБД може бути повноцінним окремим сховищем RDF-даних (триплети в ньому будуть називатися вдалося на противагу описаним вище витягнутий).
2. RDF у спеціальній серіалізації може бути просто вставлений у XML або JSON-документи (і триплети тоді будуть називатися некерований). Ймовірно, це така альтернатива механізмам idref і пр.

Хороше уявлення про те, як «насправді» все влаштовано в MarkLogic. Optic API, у цьому сенсі воно низькорівневе, хоча призначення його швидше протилежне - спробувати абстрагуватися від використовуваної моделі даних, забезпечити узгоджену роботу з даними в різних моделях, транзакційність та ін.

Мультимодельні СУБД «без основної моделі»

На ринку також представлені СУБД, які позиціонують себе як мультимодельні, не мають ніякої успадкованої основної моделі. До них відносяться ArangoDB, OrientDB (з 2018 року компанія-розробник належить SAP) та CosmosDB (Сервіс у складі хмарної платформи Microsoft Azure).

Насправді «основні» моделі в ArangoDB та OrientDB є. Це в тому й іншому випадку власні моделі даних, які є узагальненнями документної. Узагальнення полягають переважно у полегшенні можливості здійснювати запити графового і реляційного характеру.

Ці моделі є в зазначених СУБД єдино доступними для використання, для роботи з ними призначені власні мови запитів. Безумовно, такі моделі та СУБД перспективні, проте відсутність сумісності зі стандартними моделями та мовами унеможливлює використання цих СУБД в успадкованих системах — заміну ними СУБД, які вже використовуються там.

Про ArangoDB та OrientDB на Хабрі вже була чудова стаття: JOIN у NoSQL базах даних.

ArangoDB

ArangoDB заявляє про підтримку графової моделі даних.

Вузли графа в ArangoDB – це звичайні документи, а ребра – документи спеціального виду, що мають поряд із звичайними системними полями (_key, _id, _rev) системні поля _from и _to. Документи у документних СУБД традиційно поєднуються в колекції. Колекції документів, що представляють ребра, в ArangoDB називаються edge-колекціями. До речі, документи edge-колекцій це теж документи, тому ребра в ArangoDB можуть виступати також і вузлами.

Початкові дані

Нехай у нас є колекція persons, документи якої виглядають так:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

Нехай також є колекція cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

Тоді колекція likes може виглядати наступним чином:

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

Запити та результати

Запит у графовому стилі мовою AQL, що використовується в ArangoDB, повертає в людиночитаному вигляді відомості про те, кому яке кафе подобається, виглядає так:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

У реляційному стилі, коли ми скоріше «обчислюємо» зв'язки, а не зберігаємо їх, цей запит можна переписати так (до речі, без колекції likes можна було б обійтися):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

Результат в обох випадках буде той самий:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

Ще запити та результати

Якщо здається, що формат результату характерний більше для реляційної СУБД, ніж для документної, можна спробувати такий запит (або можна скористатися COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

Результат матиме такий вигляд:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

В основі реалізації графової моделі поверх документної в OrientDB лежить можливість полів документів мати окрім більш-менш стандартних скалярних значень ще й значення таких типів, як LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Значення цих типів – посилання або колекції посилань на системні ідентифікатори документів.

Ідентифікатор документа, що присвоюється системою, має «фізичний зміст», вказуючи позицію запису в базі, і виглядає приблизно так: @rid : #3:16. Тим самим значення посилальних властивостей — справді скоріше покажчики (як у графовій моделі), аніж умови відбору (як у реляційній).

Як і в ArangoDB, в OrientDB ребра представляються окремими документами (хоча якщо ребра не має своїх властивостей, його можна зробити легковажним, і йому не відповідатиме окремий документ).

Початкові дані

У форматі, наближеному до формату дампа бази OrientDB, дані з попереднього прикладу для ArangoDB виглядали б приблизно так:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

Як бачимо, вершини теж зберігають інформацію про вхідних і вихідних ребрах. При використанні Document API за цілісністю посилання доводиться стежити самому, а Graph API бере цю роботу на себе. Але подивимося, як виглядають звернення до OrientDB на «чистих», не інтегрованих у мови програмування, мови запитів.

Запити та результати

Запит, аналогічний за призначенням запиту з прикладу ArangoDB, в OrientDB виглядає так:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

Результат буде отримано у такому вигляді:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

Якщо формат результату знову здається надто «реляційним», потрібно забрати рядок з UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

Мова запитів OrientDB можна охарактеризувати як SQL з Gremlin-подібними вставками. У версії 2.2 з'явилася Cypher-подібна форма запиту, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

Формат результату буде таким самим, як у попередньому запиті. Подумайте, що потрібно прибрати, щоб зробити його більш «реляційним», як у першому запиті.

Azure CosmosDB

Найменше сказане вище про ArangoDB та OrientDB відноситься до Azure CosmosDB. CosmosDB надає такі API доступу до даних: SQL, MongoDB, Gremlin та Cassandra.

SQL API та MongoDB API використовуються для доступу до даних у документній моделі. Gremlin API та Cassandra API — для доступу до даних відповідно до графової та колонкової. Дані у всіх моделях зберігаються у форматі внутрішньої моделі CosmosDB: ARS («atom-record-sequence»), що також близька до документної.

Але вибрана користувачем модель даних і API фіксуються в момент створення облікового запису в сервісі. Неможливо отримати доступ до даних, завантажених в одній моделі, у форматі іншої моделі, що ілюструвалося приблизно таким малюнком:

Тим самим мультимодельність в Azure CosmosDB на сьогоднішній день є лише можливість використовувати кілька баз даних, що підтримують різні моделі, від одного виробника, що не вирішує всіх проблем багатоваріантного зберігання.

Мультимодельні СУБД на основі графової моделі?

Привертає увагу той факт, що на ринку поки немає мультимодельних СУБД, що мають в основі графову модель (якщо не вважати мультимодельністю підтримку одночасно двох графових моделей: RDF і LPG; див. про це в попередній публікації). Найбільші труднощі викликає реалізація поверх графової моделі документної, а не реляційної.

Питання про те, як реалізувати поверх графової моделі реляційну, розглядалося ще за часів становлення цієї останньої. Як говорив, Наприклад, Девід Макговерен:

Вони не мають у своєму розпорядженні граф, наскільки те, що твори генерують літопис (наприклад, послідовний indexing) на графі, що дає змогу об'єднати значний перегляд з (1) відкриття кнопок з основним ключовим значенням пар і (2) Групування слів relation type.

При реалізації документної моделі поверх графової потрібно мати на увазі, наприклад, наступне:

• Елементи JSON-масиву вважаються впорядкованими, що виходять із вершини ребра графа – ні;
• Дані в документній моделі зазвичай денормалізовані, зберігати кілька копій одного й того ж вкладеного документа все ж таки не хочеться, а ідентифікаторів у піддокументів зазвичай немає;
• З іншого боку, ідеологія документних СУБД полягає в тому, що документи є готовими «агрегатами», які не потрібно щоразу будувати наново. Потрібно забезпечити у графовій моделі можливість швидко отримати підграф, що відповідає готовому документу.

Небагато реклами

Автор статті стосується розробки СУБД NitrosBase, внутрішня модель якої є графовою, а зовнішні моделі — реляційна та документна — є її уявленнями. Всі моделі рівноправні: практично будь-які дані доступні в будь-якій із них з використанням природної для неї мови запитів. Більш того, у будь-якому поданні дані можуть бути змінені. Зміни відіб'ються у внутрішній моделі і, відповідно, в інших уявленнях.

Як виглядає відповідність моделей у NitrosBase - опишу, сподіваюся, в одній із наступних статей.

Висновок

Сподіваюся, що загальні контури того, що називається мультимодельністю, стали читачеві більш-менш зрозумілими. Мультиморобні називаються досить різні СУБД, і «підтримка кількох моделей» може виглядати по-різному. Для розуміння того, що називають «мультимодельністю» у кожному конкретному випадку, корисно відповісти на такі питання:

1. Чи йдеться про підтримку традиційних моделей чи про якусь одну «гібридну» модель?
2. Чи «рівноправні» моделі, чи одна з них підлягає іншим?
3. Чи «байдужі» моделі один одному? Чи можуть бути дані, записані в одній моделі, бути прочитаними в іншій або навіть перезаписані?

Думаю, на питання про актуальність мультимодельних СУБД вже можна дати позитивну відповідь, але цікаве питання про те, які саме їхні різновиди будуть затребувані найближчим часом. Схоже, затребувані будуть мультимодельні СУБД, що підтримують традиційні моделі, в першу чергу, реляційну; популярність мультимодельних СУБД, що пропонують нові моделі, що поєднують у собі переваги різних традиційних, - справа більш віддаленого майбутнього.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Ви використовуєте мультимодельні СУБД?

• Не використовуємо, зберігаємо все в одній СУБД та в одній моделі

• Використовуємо мультимодельні можливості традиційних СУБД

• Практикуємо багатоваріантне зберігання (polyglot persistence)

• Використовуємо нові мультимодельні СУБД (Arango, Orient, CosmosDB)

Проголосували 19 користувачів. Утрималися 4 користувача.

Джерело: habr.com