Сучасныя інфармацыйныя сістэмы дастаткова складаныя. Не ў апошнюю чаргу іх складанасць абумоўлена складанасцю апрацоўваных у іх дадзеных. Складанасць жа дадзеных часцяком складаецца ў разнастайнасці выкарыстоўваных мадэляў дадзеных. Так, напрыклад, калі дадзеныя становяцца "вялікімі", адной з якія дастаўляюць нязручнасці характарыстык лічыцца не толькі іх аб'ём ("volume"), але і іх разнастайнасць ("variety").

Калі вы пакуль не знаходзіце заганы ў развагах, то чытайце далей.

Змест

Polyglot persistence
Мультымадэльнасць
Мультымадэльныя СКБД на аснове рэляцыйнай мадэлі
     Дакументная мадэль у MS SQL Server
     Графавая мадэль у MS SQL Server
Мультымадэльныя СКБД на аснове дакументнай мадэлі
     Рэляцыйная мадэль у MarkLogic
     Графавая мадэль у MarkLogic
Мультымадэльныя СКБД "без асноўнай мадэлі"
     ArangoDB
     OrientDB
     Azure CosmosDB
Мультымадэльныя СКБД на аснове графавай мадэлі?
Заключэнне
Апытанне

Polyglot persistence

Сказанае вышэй прыводзіць да таго, што часам у рамках нават адной сістэмы даводзіцца для захоўвання дадзеных і рашэнні розных задач па іх апрацоўцы выкарыстоўваць некалькі розных СКБД, кожная з якіх падтрымлівае сваю мадэль дадзеных. З лёгкай рукі М. Фаулера, аўтара шэрагу вядомых кніг і аднаго з суаўтараў 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	Дакументная	Ключ-значэнне, графавая*
Data Stax	Wide-column	Дакументная, графавая
Redis	Ключ-значэнне	Дакументная, графавая*
ArangoDB	-	Графавая, дакументная
OrientDB	-	Графавая, дакументная, рэляцыйная
Azure CosmosDB	-	Графавая, дакументная, рэляцыйная

Нататкі да табліцы

Зорачкамі ў табліцы пазначаны сцвярджэнні, якія патрабуюць агаворак:

СКБД PostgreSQL не падтрымлівае графавую мадэль дадзеных, аднак яе падтрымлівае такі прадукт на яе аснове, як, напрыклад, AgensGraph.
У дачыненні да MongoDB правільней казаць хутчэй аб наяўнасці графавых аператараў у мове запытаў ($lookup, $graphLookup), чым аб падтрымцы графавай мадэлі, хоць, вядома, іх увядзенне запатрабавала некаторых аптымізацый на ўзроўні фізічнага захоўвання ў напрамку падтрымкі графавай мадэлі.
У дачыненні да Redis маецца на ўвазе пашырэнне RedisGraph.

Далей для кожнага з класаў мы пакажам, як рэалізуецца падтрымка некалькіх мадэляў у СКБД з гэтага класа. Найбольш важнымі будзем лічыць рэляцыйную, дакументную і графавую мадэлі і на прыкладах канкрэтных СКБД паказваць, як рэалізуюцца "недастатковыя".

Мультымадэльныя СКБД на аснове рэляцыйнай мадэлі

Вядучымі СКБД у цяперашні час з'яўляюцца рэляцыйныя, прагноз Gartner нельга было б лічыць здзейсненым, калі б РСУБД не дэманстравалі руху ў напрамку мультымадэльнасці. І яны дэманструюць. Зараз меркаванні аб тым, што мультымадэльная СКБД падобная швейцарскаму нажу, якім нічога нельга зрабіць добра, можна накіроўваць адразу Лары Элісан.

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

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

Аб тым, як у MS SQL Server рэалізавана падтрымка дакументнай мадэлі, на Хабре ўжо было два выдатныя артыкулы, абмяжуюся кароткім пераказам і каментаром:

Спосаб падтрымкі дакументнай мадэлі ў 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 падтрымлівае яшчэ двума іншымі спосабамі:

СКБД можа быць паўнавартасным асобным сховішчам RDF-дадзеных (трыплеты ў ім будуць звацца кіраванага у супрацьлегласць апісаным вышэй здабываецца).
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 
  }
]

Запыты і вынікі

Запыт у графавым стылі на выкарыстоўванай у ArangoDB мове AQL, які вяртае ў чалавекачытаемым выглядзе звесткі пра тое, каму якое кафэ падабаецца, выглядае так:

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) на графавым database, які здольны адноснага прагляду з (1), адкрыццё кнопак ад стандартных ключавых ключоў і (2) grouping of tuples relation type.

Пры рэалізацыі ж дакументнай мадэлі па-над графавай трэба мець на ўвазе, напрыклад, наступнае:

Элементы JSON-масіва лічацца спарадкаванымі, выходныя з вяршыні рабра графа - не;
Дадзеныя ў дакументнай мадэлі звычайна дэнармалізаваны, захоўваць некалькі копій аднаго і таго ж укладзенага дакумента ўсё ж не хочацца, а ідэнтыфікатараў у паддакументаў звычайна няма;
З іншага боку, ідэалогія дакументных СКБД у тым і заключаецца, што дакументы з'яўляюцца гатовымі "агрэгатамі", якія не трэба кожны раз будаваць нанова. Патрабуецца забяспечыць у графавай мадэлі магчымасць хутка атрымаць падграф, які адпавядае гатоваму дакументу.

Трохі рэкламы

Аўтар артыкула мае дачыненне да распрацоўкі СКБД NitrosBase, унутраная мадэль якой з'яўляецца графавай, а знешнія мадэлі - рэляцыйная і дакументная - з'яўляюцца яе ўяўленнямі. Усе мадэлі раўнапраўныя: практычна любыя дадзеныя даступныя ў любой з іх з выкарыстаннем натуральнай для яе мовы запытаў. Больш за тое, у любым уяўленні дадзеныя могуць быць зменены. Змены адаб'юцца ва ўнутранай мадэлі і, адпаведна, у іншых уяўленнях.

Як выглядае адпаведнасць мадэляў у NitrosBase апішу, спадзяюся, у адной з наступных артыкулаў.

Заключэнне

Спадзяюся, што агульныя контуры таго, што завецца мультымадэльнасцю, сталі чытачу больш-менш ясныя. Мультымадэльнымі завуцца досыць розныя СКБД, і "падтрымка некалькіх мадэляў" можа выглядаць па-рознаму. Для разумення таго, што завуць "мультымадзельнасцю" у кожным канкрэтным выпадку, карысна адказаць на наступныя пытанні:

Ці гаворка ідзе аб падтрымцы традыцыйных мадэляў або аб нейкай адной «гібрыднай» мадэлі?
Ці «раўнапраўныя» мадэлі, ці адна з іх з'яўляецца дзейнікам для іншых?
Ці «неабыякавыя» мадэлі адзін аднаму? Ці могуць дадзеныя, запісаныя ў адной мадэлі, быць прачытанымі ў іншай ці нават перазапісаны?

Думаю, на пытанне аб актуальнасці мультымадэльных СКБД ужо можна даць станоўчы адказ, але цікавае пытанне аб тым, якія менавіта іх разнавіднасці будуць больш запатрабаваны ў бліжэйшы час. Падобна, больш запатрабаваны будуць мультымадэльныя СКБД, якія падтрымліваюць традыцыйныя мадэлі, у першую чаргу, рэляцыйную; папулярнасць жа мультымадэльных СКБД, якія прапануюць новыя мадэлі, якія спалучаюць у сабе добрыя якасці розных традыцыйных, - справа больш аддаленай будучыні.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці выкарыстоўваеце вы мультымадэльныя СКБД?

Не выкарыстоўваем, захоўваем усё ў адной СКБД і ў адной мадэлі
Выкарыстоўваны мультымадэльныя магчымасці традыцыйных СКБД
Практыкуем шматварыянтнае захоўванне (polyglot persistence)
Выкарыстоўваны новыя мультымадэльныя СКБД (Arango, Orient, CosmosDB)

Прагаласавалі 19 карыстальнікаў. Устрымаліся 4 карыстальніка.

Крыніца: habr.com

Мультымадэльныя СКБД - аснова сучасных інфармацыйных сістэм?