Moderne ynformaasjesystemen binne frij kompleks. Net it minste fan alles, har kompleksiteit is te tankjen oan de kompleksiteit fan de gegevens ferwurke yn harren. De kompleksiteit fan gegevens leit faak yn it ferskaat oan gegevensmodellen dy't brûkt wurde. Dus, bygelyks, as gegevens "grut" wurde, is ien fan 'e problematyske skaaimerken net allinich har folume ("folume"), mar ek har ferskaat ("ferskaat").

As jo noch gjin flater fine yn 'e redenearring, lês dan fierder.

Ynhâld

Polyglot persistinsje
Multi-model
Multi-model DBMS basearre op it relasjonele model
     Dokumintmodel yn MS SQL Server
     Grafykmodel yn MS SQL Server
Multi-model DBMS basearre op it dokumintmodel
     Relaasjemodel yn MarkLogic
     Grafykmodel yn MarkLogic
Multi-model DBMS "sûnder haadmodel"
     ArangoDB
     OrientDB
     Azure CosmosDB
Multi-model DBMS basearre op in grafyk model?
konklúzje
Poll

Polyglot persistinsje

It boppesteande liedt ta it feit dat soms sels binnen it ramt fan ien systeem it nedich is om ferskate ferskillende DBMS's te brûken om gegevens op te slaan en ferskate problemen fan ferwurking op te lossen, dy't elk har eigen gegevensmodel stypje. Mei de lichte hân fan M. Fowler, skriuwer in oantal ferneamde boeken en ien fan co-auteurs Agile Manifesto, dizze situaasje wurdt neamd multi-fariant opslach ("polyglot persistinsje").

Fowler hat ek it folgjende foarbyld fan it organisearjen fan gegevens opslach yn in folsleine en heechladen applikaasje op it mêd fan e-commerce.

Dit foarbyld is fansels wat oerdreaun, mar guon oerwegingen foar it kiezen fan ien of oare DBMS foar it oerienkommende doel kinne fûn wurde, bygelyks, hjir.

It is dúdlik dat feint wêze yn sa'n bistetún net maklik is.

It bedrach fan koade dat útfiert gegevens opslach groeit yn ferhâlding ta it oantal DBMSs brûkt; it bedrach fan koade syngronisearjende gegevens is goed as net evenredich mei it kwadraat fan dit getal.
As in mearfâldichheid fan it oantal brûkte DBMS's, ferheegje de kosten foar it leverjen fan ûndernimmingskenmerken (skaalberens, fouttolerânsje, hege beskikberens) fan elk fan 'e brûkte DBMS's.
It is ûnmooglik om de ûndernimmingskaaimerken fan it opslachsubsysteem as gehiel te garandearjen - benammen transaksjonaliteit.

Ut it eachpunt fan de bistetúndirekteur sjocht alles der sa út:

In meardere ferheging fan 'e kosten fan lisinsjes en technyske stipe fan' e DBMS-fabrikant.
Overstaffing en ferhege deadlines.
Direkte finansjele ferliezen as boetes fanwege data-ynkonsistinsje.

D'r is in signifikante ferheging fan 'e totale eigendomskosten (TCO) fan it systeem. Is d'r in manier út 'e situaasje fan "meardere opslachopsjes"?

Multi-model

De term "multivariate opslach" kaam yn 2011 yn gebrûk. Bewustwêzen fan 'e problemen fan' e oanpak en it sykjen nei in oplossing duorre ferskate jierren, en troch 2015, troch de mûle fan Gartner-analisten, waard it antwurd formulearre:

fan"Market Guide foar NoSQL DBMS's - 2015»:
De takomst fan DBMS's, har arsjitektuer en manieren om se te brûken is multi-model.
fan"Magic Quadrant foar ODBMS - 2016»:
Leadende operasjonele DBMS's sille meardere modellen oanbiede - relaasje en net-relasjoneel - as ûnderdiel fan ien platfoarm.

It liket derop dat dizze kear Gartner-analisten gelyk hiene mei har prognose. As jo gean nei de side mei haadwurdearring DBMS op DB-Engines, kinne jo sjen datоDe measte fan har lieders positionearje har spesifyk as multi-model DBMS's. Itselde kin sjoen wurde op 'e side mei elke privee beoardieling.

De tabel hjirûnder lit de DBMS sjen - de lieders yn elk fan 'e privee beoardielingen, dy't beweare dat se multi-model binne. Foar elke DBMS wurdt it orizjinele stipe model (dat eartiids de ienige wie) en dêrmei de modellen dy't op it stuit stipe wurde oanjûn. Ek fermeld binne DBMS's dy't harsels as "oarspronklik multi-model" positionearje en, neffens de makkers, gjin inisjele erflik model hawwe.

DBMS	Inisjele model	Oanfoljende modellen
Oracle	Relasjonele	Grafyk, dokumint
MS SQL	Relasjonele	Grafyk, dokumint
PostgreSQL	Relasjonele	Grafyk*, dokumint
MarkLogic	Dokumintêre	Grafyk, relaasje
MongoDB	Dokumintêre	Key-wearde, grafyk*
DataStax	Wide-kolom	Dokumintêre, grafyk
Redis	Key-wearde	Dokumintêre, grafyk*
ArangoDB	-	Grafyk, dokumint
OrientDB	-	Grafyk, dokumint, relaasje
Azure CosmosDB	-	Grafyk, dokumint, relaasje

Notysjes op 'e tafel

Asterisken yn 'e tabel markearje útspraken dy't reservearrings nedich binne:

De PostgreSQL DBMS stipet it grafykgegevensmodel net, mar dit produkt stipet it wol derop basearre, lykas AgensGraph.
Yn relaasje mei MongoDB is it krekter om te praten oer de oanwêzigens fan grafykoperators yn 'e query-taal ($lookup, $graphLookup) dan oer it stypjen fan it grafykmodel, hoewol, fansels, har yntroduksje easke wat optimisaasjes op it fysike opslachnivo yn 'e rjochting fan it stypjen fan it grafykmodel.
Yn relaasje ta Redis bedoele wy de útwreiding RedisGraph.

Folgjende sille wy foar elk fan 'e klassen sjen litte hoe't stipe foar ferskate modellen wurdt ymplementearre yn' e DBMS fan dizze klasse. Wy sille de relaasje-, dokumint- en grafmodellen beskôgje as de wichtichste en brûke foarbylden fan spesifike DBMS's om sjen te litten hoe't de "ûntbrekkende" wurde ymplementearre.

Multi-model DBMS basearre op it relasjonele model

De liedende DBMS's binne op it stuit relasjonele dy't Gartner's prognose koe net as wier wurde beskôge as RDBMS's gjin beweging yn 'e rjochting fan multi-modellering sjen litte. En se demonstrearje. No kin it idee dat in multi-model DBMS as in Switsersk mes is, dat neat goed kin dwaan, direkt nei Larry Ellison rjochte wurde.

De skriuwer hat lykwols de foarkar foar de ymplemintaasje fan multi-modeling yn Microsoft SQL Server, op it foarbyld wêrfan RDBMS-stipe foar dokumint- en grafmodellen wurde beskreaun.

Dokumintmodel yn MS SQL Server

D'r binne al twa poerbêste artikels oer Habré oer hoe't MS SQL Server stipe foar it dokumintmodel implementeart. Ik sil my beheine ta in koarte wertelling en kommentaar:

De manier om it dokumintmodel yn MS SQL Server te stypjen is frij typysk foar relationele DBMS's: JSON-dokuminten wurde foarsteld om te wurde opslein yn gewoane tekstfjilden. Stipe foar it dokumintmodel is om spesjale operators te leverjen om dizze JSON te parsearjen:

JSON_VALUE om skalêre attribuutwearden te ekstrahearjen,
JSON_QUERY subdokuminten út te heljen.

It twadde argumint fan beide operators is in útdrukking yn JSONPath-like syntaksis.

Abstrakt kinne wy sizze dat dokuminten dy't op dizze manier opslein binne gjin "earste-klasse entiteiten" binne yn in relasjonele DBMS, yn tsjinstelling ta tuples. Spesifyk, yn MS SQL Server binne d'r op it stuit gjin yndeksen op 'e fjilden fan JSON-dokuminten, wat it lestich makket om tabellen mei te dwaan mei de wearden fan dizze fjilden en sels dokuminten te selektearjen mei dizze wearden. It is lykwols mooglik om in berekkene kolom foar sa'n fjild en in yndeks derop te meitsjen.

Derneist biedt MS SQL Server de mooglikheid om maklik in JSON-dokumint te konstruearjen út 'e ynhâld fan tabellen mei de operator FOR JSON PATH - in mooglikheid, yn in bepaalde sin, tsjinoer de foarige, konvinsjonele opslach. It is dúdlik dat nettsjinsteande hoe fluch in RDBMS is, dizze oanpak tsjinsprekt de ideology fan dokumint DBMS's, dy't yn essinsje klearmakke antwurden op populêre fragen opslaan, en allinich problemen kinne oplosse fan maklike ûntwikkeling, mar net snelheid.

Uteinlik lit MS SQL Server jo it tsjinoerstelde probleem fan dokumintkonstruksje oplosse: jo kinne JSON ûntlûpe yn tabellen mei OPENJSON. As it dokumint net folslein plat is, moatte jo gebrûk meitsje CROSS APPLY.

Grafykmodel yn MS SQL Server

Stipe foar it grafyk (LPG) model is ek folslein ymplementearre yn Microsoft SQL Server foarsisber: It wurdt foarsteld om spesjale tabellen te brûken om knopen op te slaan en grafrânen op te slaan. Sokke tabellen wurde makke mei útdrukkingen CREATE TABLE AS NODE и CREATE TABLE AS EDGE respektivelik.

Tabellen fan it earste type binne gelyk oan gewoane tabellen foar it opslaan fan records, mei it ienige eksterne ferskil dat de tabel in systeemfjild befettet $node_id - unike identifier fan in grafykknooppunt binnen de database.

Likegoed hawwe tabellen fan it twadde type systeemfjilden $from_id и $to_id, yngongen yn sokke tabellen definiearje dúdlik de ferbinings tusken knopen. In aparte tabel wurdt brûkt om relaasjes fan elk type op te slaan.

Lit ús dit yllustrearje mei in foarbyld. Lit de grafykgegevens in yndieling hawwe lykas dy yn 'e figuer werjûn. Om dan de oerienkommende struktuer yn 'e databank te meitsjen moatte jo de folgjende DDL-fragen útfiere:

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);

De wichtichste spesifisiteit fan sokke tabellen is dat yn queries tsjin har it mooglik is om grafyske patroanen te brûken mei Cypher-like syntaksis (lykwols, "*"etc. wurde noch net stipe). Op grûn fan prestaasjesmjittingen kin ek oannommen wurde dat de manier wêrop gegevens yn dizze tabellen wurde opslein oars is fan 'e manier wêrop gegevens yn reguliere tabellen opslein wurde en is optimalisearre foar it útfieren fan sokke grafykfragen.

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

Boppedat is it frij lestich om dizze grafyske patroanen net te brûken by it wurkjen mei sokke tabellen, om't yn gewoane SQL-fragen om ferlykbere problemen op te lossen, it nedich is om ekstra ynspanningen te meitsjen om systeem-"grafyk"-knooppuntidentifikatoren te krijen ($node_id, $from_id, $to_id; Om deselde reden wurde fragen foar it ynfoegjen fan gegevens hjir net werjûn, om't se ûnnedich omslachtich binne).

Om de beskriuwing fan 'e ymplemintaasjes fan' e dokumint- en grafykmodellen yn MS SQL Server gearfetsje, soe ik konstatearje dat sokke ymplemintaasjes fan ien model boppe op in oar net suksesfol lykje, benammen út it eachpunt fan taalûntwerp. It is needsaaklik om de iene taal mei de oare út te wreidzjen, de talen binne net folslein "ortogonaal", de kompatibiliteitsregels kinne frij bizar wêze.

Multi-model DBMS basearre op it dokumintmodel

Yn dizze seksje wol ik de ymplemintaasje fan multi-model yn dokumint DBMS's yllustrearje mei it foarbyld fan 'e net populêrste fan har, MongoDB (lykas sein, it hat allinich betingsten grafoperators $lookup и $graphLookup, net wurkje oan ferdielde kolleksjes), mar mei it foarbyld fan in mear folwoeksen en "bedriuw" DBMS MarkLogic.

Dat, lit de kolleksje in set fan XML-dokuminten fan it folgjende type befetsje (MarkLogic lit jo ek JSON-dokuminten opslaan):

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

Relaasjemodel yn MarkLogic

In relasjonele werjefte fan in samling dokuminten kin makke wurde mei werjaan template (ynhâld fan eleminten value yn it foarbyld hjirûnder kin d'r in willekeurige XPath wêze):

<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>

Jo kinne de oanmakke werjefte oanpakke mei in SQL-query (bygelyks fia ODBC):

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

Spitigernôch is de relasjonele werjefte makke troch it werjaansjabloan allinich lêzen. By it ferwurkjen fan in fersyk dêrfoar sil MarkLogic besykje te brûken dokumint yndeksen. Earder hie MarkLogic beheinde relasjonele werjeften, folslein yndeks basearre en skriuwber, mar no wurde se beskôge as ôfskreaun.

Grafykmodel yn MarkLogic

Mei stipe foar it grafyske (RDF) model is alles sawat itselde. Nochris mei help werjaan template jo kinne in RDF-fertsjintwurdiging meitsje fan in samling dokuminten út it hjirboppe foarbyld:

<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>

Jo kinne de resultearjende RDF-grafyk oanpakke mei in SPARQL-query:

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

Oars as de relaasje, stipet MarkLogic it grafykmodel op twa oare manieren:

In DBMS kin in folslein aparte opslach fan RDF-gegevens wêze (trijelingen dêryn wurde neamd beheare yn tsjinstelling ta de hjirboppe beskreaune ekstrakt).
RDF yn spesjale serialisaasje kin gewoan wurde ynfoege yn XML- of JSON-dokuminten (en trijelingen sille dan wurde neamd net beheard). Dit is wierskynlik in alternatyf foar meganismen idref en oaren.

In goed idee fan hoe't dingen "echt" wurkje yn MarkLogic wurdt jûn troch Optical API, yn dizze sin, it is leech-nivo, hoewol't it doel is earder it tsjinoerstelde - om te besykjen te abstraheren út de gegevens model brûkt, te garandearjen konsekwint wurk mei gegevens yn ferskillende modellen, transaksjonality, etc.

Multi-model DBMS "sûnder haadmodel"

D'r binne ek DBMS's op 'e merke dy't harsels as yn earste ynstânsje multi-model positionearje, sûnder ienich erflik haadmodel. Dêr heart by ArangoDB, OrientDB (sûnt 2018 it ûntwikkelingsbedriuw heart by SAP) en CosmosDB (tsjinst as ûnderdiel fan it Microsoft Azure-wolkplatfoarm).

Yn feite binne d'r "kearn" modellen yn ArangoDB en OrientDB. Yn beide gefallen binne dit har eigen gegevensmodellen, dy't generalisaasjes binne fan it dokumint ien. De generalisaasjes binne benammen om it fermogen te fasilitearjen om fragen fan in grafyk en relasjonele aard út te fieren.

Dizze modellen binne de iennichste beskikber foar gebrûk yn 'e opjûne DBMS, har eigen query-talen binne ûntworpen om mei har te wurkjen. Fansels binne sokke modellen en DBMS's kânsryk, mar it gebrek oan kompatibiliteit mei standertmodellen en talen makket it ûnmooglik om dizze DBMS's te brûken yn legacy-systemen - om de DBMS's dy't al binne brûkt te ferfangen.

D'r wie al in prachtich artikel oer ArangoDB en OrientDB op Habré: JOIN yn NoSQL-databases.

ArangoDB

ArangoDB beweart stipe foar in grafyske gegevensmodel.

De knopen fan in grafyk yn ArangoDB binne gewoane dokuminten, en de rânen binne dokuminten fan in spesjaal type dy't tegearre mei reguliere systeemfjilden (_key, _id, _rev) systeemfjilden _from и _to. Dokuminten yn dokumint DBMS's wurde tradisjoneel kombinearre yn kolleksjes. Samlingen fan dokuminten dy't rânen fertsjintwurdigje wurde rânekolleksjes neamd yn ArangoDB. Trouwens, rânekolleksjedokuminten binne ek dokuminten, sadat rânen yn ArangoDB ek as knooppunten kinne fungearje.

Roald gegevens

Lit ús in kolleksje hawwe persons, waans dokuminten der sa útsjen:

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

Lit der ek in kolleksje komme cafes:

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

Dan de kolleksje likes kin der sa útsjen:

[
  {
    "_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 
  }
]

Queries en resultaten

In query yn grafyske styl yn 'e AQL-taal brûkt yn ArangoDB, dy't yn minsklik lêsbere foarm ynformaasje werombringt oer wa't fan hokker kafee liket, sjocht der sa út:

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

Yn in relasjonele styl, wêr't wy relaasjes "berekkenje" ynstee fan se op te slaan, kin dizze fraach sa oerskreaun wurde (troch de wei, sûnder de kolleksje likes koe sûnder):

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 }

It resultaat yn beide gefallen sil itselde wêze:

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

Mear fragen en resultaten

As it resultaatformaat hjirboppe mear typysk liket te wêzen foar in relationele DBMS dan foar in dokumint DBMS, kinne jo dizze fraach besykje (of jo kinne brûke COLLECT):

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

It resultaat sil der sa útsjen:

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

OrientDB

De basis foar it ymplementearjen fan in grafykmodel boppe op in dokumintmodel yn OrientDB is kâns dokumintfjilden, neist min of mear standert skalêre wearden, hawwe ek wearden fan soarten lykas LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. De wearden fan dizze soarten binne keppelings as kolleksjes fan keppelings nei systeem identifiers dokuminten.

De dokumintidentifikator tawiisd troch it systeem hat in "fysike betsjutting", wat de posysje fan it rekord yn 'e databank oanjout, en sjocht der sa út: @rid : #3:16. Sa binne de wearden fan referinsjeeigenskippen wirklik oanwizers (lykas yn it grafykmodel) ynstee fan seleksjebetingsten (lykas yn it relasjonele model).

Lykas ArangoDB wurde rânen yn OrientDB fertsjintwurdige as aparte dokuminten (hoewol as in râne gjin eigen eigenskippen hat, kin it makke wurde lichtgewicht, en it sil net oerienkomme mei in apart dokumint).

Roald gegevens

Yn in opmaak tichtby dump formaat OrientDB-database, de gegevens fan it foarige foarbyld foar ArangoDB soene der sa útsjen:

[
     {
      "@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"
    }
  ]

Sa't wy sjen kinne, opslaan hoekpunten ek ynformaasje oer ynkommende en útgeande rânen. By mei help fan De dokumint-API moat referinsjele yntegriteit sels kontrolearje, en de Graph API nimt dit wurk op. Mar litte wy sjen hoe tagong ta OrientDB derút sjocht yn "suvere" query-talen dy't net binne yntegreare yn programmeartalen.

Queries en resultaten

In query fergelykber yn doel mei de query út it foarbyld foar ArangoDB yn OrientDB sjocht der sa út:

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

It resultaat sil krigen wurde yn de folgjende foarm:

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

As it resultaat opmaak wer liket te "relasjoneel", Jo moatte fuortsmite de line mei UNWIND():

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

De query-taal fan OrientDB kin wurde omskreaun as SQL mei Gremlin-like ynserts. Yn ferzje 2.2 ferskynde in Cypher-like oanfraachformulier, 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

It resultaatformaat sil itselde wêze as yn it foarige fersyk. Tink oan wat moat wurde fuortsmiten om it mear "relasjoneel", lykas yn 'e earste fraach.

Azure CosmosDB

Yn mindere mjitte is wat hjirboppe sein waard oer ArangoDB en OrientDB jildt foar Azure CosmosDB. CosmosDB leveret de folgjende API's foar gegevenstagong: SQL, MongoDB, Gremlin en Cassandra.

SQL API en MongoDB API wurde brûkt om tagong te krijen ta gegevens yn it dokumintmodel. Gremlin API en Cassandra API - foar tagong ta gegevens yn respektivelik grafyk- en kolomformaten. Gegevens yn alle modellen wurde bewarre yn it CosmosDB ynterne modelformaat: ARS ("atom-record-sekwinsje"), dy't ek ticht by it dokumint ien is.

Mar it gegevensmodel keazen troch de brûker en de brûkte API binne fêst op it momint fan it meitsjen fan in akkount yn 'e tsjinst. It is net mooglik om tagong te krijen ta gegevens dy't yn ien model laden binne yn it formaat fan in oar model, lykas yllustrearre troch soksawat as dit:

Sa is multi-model yn Azure CosmosDB hjoed allinich de mooglikheid om ferskate databases te brûken dy't ferskate modellen stypje fan ien fabrikant, dy't net alle problemen fan multi-fariant opslach oplost.

Multi-model DBMS basearre op in grafyk model?

Opmerklik is it feit dat d'r noch gjin multi-model DBMS's op 'e merke binne dy't basearre binne op in grafysk model (útsein multi-model stipe foar tagelyk twa grafyske modellen: RDF en LPG; sjoch dit yn foarige publikaasje). De grutste swierrichheden wurde feroarsake troch de ymplemintaasje fan in dokumintmodel boppe op in grafykmodel, ynstee fan in relaasje.

De fraach fan hoe't te realisearjen in relaasje model boppe op de grafyk model waard beskôge sels by de foarming fan de lêste. Hoe sprutsbygelyks David McGovern:

D'r is neat ynherinte oan 'e grafyske oanpak dy't foarkomt it meitsjen fan in laach (bgl tuples by relaasje type.

By it ymplementearjen fan in dokumintmodel boppe op in grafykmodel, moatte jo bygelyks it folgjende yn gedachten hâlde:

Eleminten fan in JSON-array wurde beskôge as oardere, mar dy dy't út 'e hoekpunt fan in râne fan' e grafyk komme, binne net;
Gegevens yn it dokumint model wurdt meastal denormalized jo noch net wolle opslaan ferskate kopyen fan itselde ynbêde dokumint, en subdokuminten hawwe meastentiids gjin identifiers;
Oan 'e oare kant is de ideology fan dokumint DBMS's dat dokuminten klearmakke "aggregaten" binne dy't net elke kear op 'e nij moatte wurde boud. It is ferplichte om it grafyske model te foarsjen mei de mooglikheid om fluch in subgrafyk te krijen dy't oerienkomt mei it ôfmakke dokumint.

In bytsje reklame

De skriuwer fan it artikel is besibbe oan 'e ûntwikkeling fan' e NitrosBase DBMS, wêrfan it ynterne model in grafyk is, en de eksterne modellen - relaasje en dokumint - binne har foarstellingen. Alle modellen binne gelyk: hast alle gegevens binne beskikber yn elk fan harren mei in query-taal dy't der natuerlik foar is. Boppedat kinne de gegevens yn elke werjefte feroare wurde. Feroarings sille wjerspegele wurde yn it ynterne model en, dus, yn oare werjeften.

Ik sil hooplik beskriuwe hoe model matching der út sjocht yn NitrosBase yn ien fan 'e folgjende artikels.

konklúzje

Ik hoopje dat de algemiene útstrieling fan wat men multymodellearjen hjit foar de lêzer min of mear dúdlik wurden is. Multi-model DBMS's binne hiel oars, en "multi-model stipe" kin der oars útsjen. Om te begripen wat yn elk spesifyk gefal "multi-model" neamd wurdt, is it handich om de folgjende fragen te beantwurdzjen:

Hawwe wy it oer it stypjen fan tradisjonele modellen as in soarte fan "hybride" model?
Binne de modellen "lykweardich", of is ien fan har it ûnderwerp fan 'e oaren?
Binne de modellen "ûnferskillich" foar elkoar? Kin gegevens skreaun yn ien model wurde lêzen yn in oar of sels oerskreaun?

Ik tink dat de fraach oer de relevânsje fan multi-model DBMS kin al posityf beäntwurde, mar de nijsgjirrige fraach is hokker soarten fan harren sil wêze mear yn fraach yn de heine takomst. It liket derop dat multi-model DBMS's dy't tradysjonele modellen stypje, primêr relaasje, sille yn gruttere fraach wêze; De populariteit fan multi-model DBMS's, dy't nije modellen oanbiede dy't de foardielen fan ferskate tradisjonele kombinearje, is in kwestje fan 'e fierste takomst.

Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. Ynlogge, asjebleaft.