A modern információs rendszerek meglehetősen összetettek. Nem utolsósorban összetettségük a bennük feldolgozott adatok összetettségéből adódik. Az adatok összetettsége gyakran a felhasznált adatmodellek sokféleségében rejlik. Így például amikor az adatok „nagyokká” válnak, az egyik problémás jellemző nemcsak a mennyisége („volume”), hanem a változatossága („változata”) is.

Ha még nem talál hibát az érvelésben, akkor olvasson tovább.

Tartalom

Poliglott kitartás
Több modell
Többmodell DBMS a relációs modell alapján
     Dokumentummodell az MS SQL Serverben
     Grafikonmodell az MS SQL Serverben
Többmodell DBMS a dokumentummodell alapján
     Relációs modell a MarkLogic-ban
     Grafikonmodell a MarkLogicban
Többmodell DBMS „főmodell nélkül”
     ArangoDB
     OrientDB
     Azure CosmosDB
Többmodell DBMS gráfmodell alapján?
Következtetés
Опрос

Poliglott kitartás

A fentiek arra vezetnek, hogy néha egy rendszer keretein belül is több különböző DBMS-t kell használni az adatok tárolására és a feldolgozás különböző problémáinak megoldására, amelyek mindegyike támogatja a saját adatmodelljét. M. Fowler könnyű kezével, szerző számos híres könyv és egy társszerzők Agilis kiáltvány, ezt a helyzetet hívják többváltozatos tárolás („poliglott kitartás”).

Fowler a következő példával is rendelkezik az adattárolás megszervezésére egy teljes értékű és nagy terhelésű alkalmazásban az e-kereskedelem területén.

Ez a példa természetesen némileg eltúlzott, de néhány megfontolás amellett szól, hogy egyik vagy másik DBMS-t a megfelelő célra válasszuk, pl. itt.

Nyilvánvaló, hogy szolgának lenni egy ilyen állatkertben nem könnyű.

Az adattárolást végző kód mennyisége a felhasznált DBMS-ek számával arányosan nő; a kódszinkronizáló adatok mennyisége jó, ha nem arányos ennek a számnak a négyzetével.
A használt DBMS-ek számának többszöröseként nőnek az egyes használt DBMS-ek vállalati jellemzőinek (skálázhatóság, hibatűrés, magas rendelkezésre állás) biztosításának költségei.
Lehetetlen biztosítani a tároló alrendszer vállalati jellemzőit, mint egészet - különösen a tranzakciós jelleget.

Az állatkert igazgatója szemszögéből minden így néz ki:

A DBMS-gyártótól származó licencek és műszaki támogatás költségeinek többszörös növekedése.
Létszám és meghosszabbított határidők.
Közvetlen pénzügyi veszteségek vagy büntetések az adatok következetlensége miatt.

Jelentősen megnőtt a rendszer teljes birtoklási költsége (TCO). Van-e kiút a „több tárolási lehetőség” helyzetéből?

Több modell

A „többváltozós tárolás” kifejezés 2011-ben került használatba. A megközelítés problémáinak tudatosítása és a megoldás keresése több évig tartott, és 2015-re a Gartner elemzőinek száján keresztül megfogalmazódott a válasz:

Tól től "Piaci útmutató NoSQL DBMS-ekhez – 2015"
A DBMS-ek jövője, architektúrája és felhasználási módjai többmodellből állnak.
Tól től "Magic Quadrant for ODBMS - 2016"
A vezető operatív DBMS-ek több – relációs és nem relációs – modellt kínálnak egyetlen platform részeként.

Úgy tűnik, a Gartner elemzői ezúttal igazat adtak előrejelzésüknek. Ha azzal az oldalra lépsz fő minősítés DBMS a DB-Engines rendszeren, ezt láthatodоA legtöbb vezető kifejezetten többmodell DBMS-ként pozicionálja magát. Ugyanez látható az oldalon bármilyen privát minősítéssel.

Az alábbi táblázat a DBMS-t mutatja – az egyes privát besorolások vezetőit, amelyek azt állítják, hogy többmodellesek. Minden DBMS-nél fel van tüntetve az eredeti támogatott modell (ami egykor volt az egyetlen), és ezzel együtt a jelenleg támogatott modellek. A listán szerepelnek azok a DBMS-ek is, amelyek „eredetileg többmodellként” pozícionálják magukat, és az alkotók szerint nem rendelkeznek kezdeti örökölt modellel.

DBMS	Kezdeti modell	További modellek
Jóslat	Relációs	Grafikon, dokumentum
MS SQL	Relációs	Grafikon, dokumentum
PostgreSQL	Relációs	Grafikon*, dokumentum
MarkLogic	Dokumentumfilm	Grafikon, relációs
MongoDB	Dokumentumfilm	Kulcsérték, grafikon*
DataStax	Széles oszlop	Dokumentumfilm, grafikon
Feleinek	Kulcs érték	dokumentumfilm, grafikon*
ArangoDB	-	Grafikon, dokumentum
OrientDB	-	Grafikon, dokumentum, relációs
Azure CosmosDB	-	Grafikon, dokumentum, relációs

Táblázat megjegyzései

A táblázatban csillagok jelölik a fenntartást igénylő kijelentéseket:

A PostgreSQL DBMS nem támogatja a grafikon adatmodellt, de ez a termék támogatja azt az alapján, mint például az AgensGraph.
A MongoDB-vel kapcsolatban helyesebb a gráfoperátorok jelenlétéről beszélni a lekérdező nyelvben ($lookup, $graphLookup).
Redis kapcsán a kiterjesztést értjük RedisGraph.

Ezután az egyes osztályok esetében bemutatjuk, hogyan valósul meg több modell támogatása a DBMS-ben ebből az osztályból. A relációs, dokumentum- és gráfmodelleket tekintjük a legfontosabbnak, és konkrét DBMS-ek példáit használjuk annak bemutatására, hogy a „hiányzók” hogyan valósulnak meg.

Többmodell DBMS a relációs modell alapján

A vezető DBMS-ek jelenleg relációsak, a Gartner előrejelzése nem tekinthető igaznak, ha az RDBMS-ek nem mutatnának mozgást a multi-modellezés irányába. És demonstrálnak. Most már közvetlenül Larry Ellisonhoz irányítható az az ötlet, hogy a többmodelles DBMS olyan, mint egy svájci kés, amely nem tud semmi jót csinálni.

A szerző azonban előnyben részesíti a multi-modellezés Microsoft SQL Serverben való megvalósítását, amelynek példáján a dokumentum- és gráfmodellek RDBMS támogatását ismertetjük.

Dokumentummodell az MS SQL Serverben

Habréról már két kiváló cikk jelent meg arról, hogy az MS SQL Server hogyan valósítja meg a dokumentummodell támogatását; egy rövid átbeszélésre és kommentárra szorítkozom:

A dokumentummodell támogatásának módja az MS SQL Serverben meglehetősen jellemző a relációs DBMS-ekre: a JSON-dokumentumok tárolása normál szövegmezőkben javasolt. A dokumentummodell támogatása speciális operátorok biztosítása a JSON elemzéséhez:

JSON_VALUE skaláris attribútumértékek kinyeréséhez,
JSON_QUERY részdokumentumok kinyerésére.

Mindkét operátor második argumentuma egy kifejezés a JSONPath-szerű szintaxisban.

Absztrakt módon azt mondhatjuk, hogy az így tárolt dokumentumok nem „első osztályú entitások” egy relációs DBMS-ben, ellentétben a sorokkal. Pontosabban, az MS SQL Serverben jelenleg nincsenek indexek a JSON-dokumentumok mezőiben, ami megnehezíti a táblák összekapcsolását ezeknek a mezőknek az értékeit használva, és még az értékeket használó dokumentumok kiválasztását is. Lehetséges azonban egy ilyen mezőhöz egy számított oszlopot és egy indexet létrehozni.

Ezenkívül az MS SQL Server lehetővé teszi a JSON-dokumentumok kényelmes összeállítását a táblák tartalmából az operátor használatával. FOR JSON PATH - az előzővel, a hagyományos tárolással bizonyos értelemben ellentétes lehetőség. Nyilvánvaló, hogy bármilyen gyors is egy RDBMS, ez a megközelítés ellentmond a dokumentum-DBMS-ek ideológiájának, amelyek lényegében kész válaszokat tárolnak a népszerű lekérdezésekre, és csak a könnyű fejlesztés, de nem a gyorsaság problémáit tudják megoldani.

Végül az MS SQL Server lehetővé teszi a dokumentumkészítés ellentétes problémájának megoldását: a JSON-t táblázatokra bonthatja OPENJSON. Ha a dokumentum nem teljesen sík, akkor használnia kell CROSS APPLY.

Grafikonmodell az MS SQL Serverben

A grafikon (LPG) modell támogatása a Microsoft SQL Serverben is teljes mértékben megvalósul megjósolhatóan: Javasoljuk speciális táblázatok használatát a csomópontok tárolására és a gráfélek tárolására. Az ilyen táblázatok kifejezések segítségével jönnek létre CREATE TABLE AS NODE и CREATE TABLE AS EDGE volt.

Az első típusú táblák hasonlóak a szokásos rekordok tárolására szolgáló táblákhoz, azzal az egyetlen külső különbséggel, hogy a tábla rendszermezőt tartalmaz. $node_id — az adatbázison belüli gráfcsomópont egyedi azonosítója.

Hasonlóképpen a második típusú tábláknak is vannak rendszermezői $from_id и $to_id, az ilyen táblázatok bejegyzései egyértelműen meghatározzák a csomópontok közötti kapcsolatokat. Az egyes típusú kapcsolatok tárolására külön tábla szolgál.

Illusztráljuk ezt egy példával. Legyen a grafikon adatai olyan elrendezésűek, mint az ábrán látható. Ezután a megfelelő struktúra létrehozásához az adatbázisban a következő DDL lekérdezéseket kell futtatnia:

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

Az ilyen táblák fő sajátossága, hogy az ellenük irányuló lekérdezésekben lehetőség van Cypher-szerű szintaxisú gráfminták használatára (azonban*"stb. még nem támogatottak). A teljesítménymérések alapján az is feltételezhető, hogy az adatok tárolásának módja ezekben a táblákban eltér a hagyományos táblákban való tárolás módjától, és az ilyen gráflekérdezések végrehajtására van optimalizálva.

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

Ezenkívül meglehetősen nehéz nem használni ezeket a grafikonmintákat az ilyen táblákkal való munka során, mivel a szokásos SQL-lekérdezésekben hasonló problémák megoldásához további erőfeszítéseket kell tenni a rendszer „gráf” csomópont-azonosítóinak megszerzéséhez ($node_id, $from_id, $to_id; Ugyanebből az okból kifolyólag az adatok beszúrására vonatkozó lekérdezések itt nem jelennek meg, mivel azok szükségtelenül nehézkesek.

Összefoglalva a dokumentum- és gráfmodellek MS SQL Serverben való implementációinak leírását, megjegyzem, hogy az egyik modell ilyen implementációja a másikra nem tűnik sikeresnek, elsősorban nyelvi tervezési szempontból. Az egyik nyelvet ki kell bővíteni a másikkal, a nyelvek nem teljesen „ortogonálisak”, a kompatibilitási szabályok meglehetősen bizarrak lehetnek.

Többmodell DBMS a dokumentummodell alapján

Ebben a részben a multimodell implementációját szeretném szemléltetni a dokumentum-DBMS-ekben a nem legnépszerűbb közülük, a MongoDB példáján keresztül (amint említettük, csak feltételes gráfoperátorokat tartalmaz $lookup и $graphLookup, amely nem szilánkos gyűjteményeken dolgozik), hanem egy kiforrottabb és „vállalati” DBMS példájával MarkLogic.

Tehát hagyja, hogy a gyűjtemény a következő típusú XML-dokumentumok készletét tartalmazza (a MarkLogic lehetővé teszi a JSON-dokumentumok tárolását is):

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

Relációs modell a MarkLogic-ban

Egy dokumentumgyűjtemény relációs nézete hozható létre megjelenítési sablon (az elemek tartalma value az alábbi példában tetszőleges XPath lehet):

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

A létrehozott nézetet megcímezheti SQL lekérdezéssel (például ODBC-n keresztül):

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

Sajnos a megjelenítési sablon által létrehozott relációs nézet csak olvasható. Az erre vonatkozó kérés feldolgozásakor a MarkLogic megpróbálja használni dokumentummutatók. Korábban a MarkLogicnak teljesen korlátozott relációs nézetei voltak index alapú és írhatóak, de most már elavultnak számítanak.

Grafikonmodell a MarkLogicban

A grafikon (RDF) modell támogatásával minden nagyjából ugyanaz. Megint a segítséggel megjelenítési sablon a fenti példából létrehozhat egy dokumentumgyűjtemény RDF-reprezentációját:

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

Az eredményül kapott RDF gráfot megcímezheti egy SPARQL lekérdezéssel:

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

A relációs modelltől eltérően a MarkLogic két másik módon is támogatja a gráfmodellt:

A DBMS lehet az RDF adatok teljes értékű különálló tárolója (a benne lévő hármasokat ún. sikerült szemben a fent leírtakkal extrahált).
A speciális szerializált RDF egyszerűen beilleszthető XML vagy JSON dokumentumokba (és a hármasokat ezután hívják menedzselt). Ez valószínűleg a mechanizmusok alternatívája idref stb

Jó ötletet ad arról, hogy a dolgok „valójában hogyan működnek” a MarkLogicban Optikai API, ebben az értelemben alacsony szintű, bár célja inkább az ellenkezője - megpróbálni elvonatkoztatni a használt adatmodelltől, konzisztens munkát biztosítani az adatokkal a különböző modellekben, tranzakciós stb.

Többmodell DBMS „főmodell nélkül”

Vannak olyan DBMS-ek is a piacon, amelyek kezdetben többmodellként pozícionálják magukat, örökölt főmodell nélkül. Ezek tartalmazzák ArangoDB, OrientDB (2018 óta a fejlesztő cég az SAP-hoz tartozik) ill CosmosDB (szolgáltatás a Microsoft Azure felhőplatform részeként).

Valójában vannak „alap” modellek az ArangoDB-ben és az OrientDB-ben. Mindkét esetben saját adatmodellről van szó, amelyek a dokumentum egyik általánosításai. Az általánosítások főként a gráf és relációs jellegű lekérdezések végrehajtásának megkönnyítésére szolgálnak.

Csak ezek a modellek használhatók a megadott DBMS-ben; saját lekérdezési nyelveiket úgy tervezték, hogy működjenek velük. Természetesen az ilyen modellek és DBMS-ek ígéretesek, de a szabványos modellekkel és nyelvekkel való kompatibilitás hiánya lehetetlenné teszi ezeknek a DBMS-eknek az örökölt rendszerekben való használatát – az ott már használt DBMS-ek helyettesítésére.

A Habrén már volt egy csodálatos cikk az ArangoDB-ről és az OrientDB-ről: CSATLAKOZZ A NoSQL adatbázisokhoz.

ArangoDB

Az ArangoDB azt állítja, hogy támogatja a grafikon adatmodellt.

A gráf csomópontjai az ArangoDB-ben közönséges dokumentumok, az élek pedig speciális típusú dokumentumok, amelyek a szabályos rendszermezőkkel együtt rendelkeznek (_key, _id, _rev) rendszermezők _from и _to. A dokumentum-DBMS-ekben lévő dokumentumokat hagyományosan gyűjteményekbe egyesítik. Az éleket reprezentáló dokumentumok gyűjteményeit élgyűjteménynek nevezzük az ArangoDB-ben. Egyébként az élgyűjtemény dokumentumai is dokumentumok, így az ArangoDB élei csomópontként is működhetnek.

Nyers adatok

Legyen egy gyűjteményünk persons, amelynek dokumentumai így néznek ki:

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

Legyen gyűjtemény is cafes:

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

Aztán a gyűjtemény likes így nézhet ki:

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

Lekérdezések és eredmények

Az ArangoDB-ben használt AQL nyelvű gráf stílusú lekérdezés, amely ember által olvasható formában ad vissza információt arról, hogy ki melyik kávézót szereti, így néz ki:

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

Egy relációs stílusban, ahol a kapcsolatokat „számítjuk” ahelyett, hogy tárolnánk, ez a lekérdezés így átírható (egyébként a gyűjtemény nélkül likes nélkülözhetné):

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 }

Az eredmény mindkét esetben ugyanaz lesz:

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

További lekérdezések és eredmények

Ha úgy tűnik, hogy a fenti eredményformátum jellemzőbb egy relációs DBMS-re, mint egy dokumentum-DBMS-re, akkor megpróbálhatja ezt a lekérdezést (vagy használhatja COLLECT):

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

Az eredmény így fog kinézni:

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

OrientDB

Az OrientDB dokumentummodellje feletti gráfmodell megvalósításának alapja az alkalom a dokumentummezők a többé-kevésbé szabványos skaláris értékeken kívül olyan típusú értékeket is tartalmaznak, mint pl LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Ezeknek a típusoknak az értékei a hivatkozások vagy hivatkozásgyűjtemények rendszerazonosítók dokumentumokat.

A rendszer által hozzárendelt dokumentumazonosító „fizikai jelentésű”, a rekord pozícióját jelzi az adatbázisban, és így néz ki: @rid : #3:16. Így a referenciatulajdonságok értékei valójában mutatók (mint a gráfmodellben), nem pedig kiválasztási feltételek (mint a relációs modellben).

Az ArangoDB-hez hasonlóan az élek az OrientDB-ben is külön dokumentumokként jelennek meg (bár ha egy élnek nincsenek saját tulajdonságai, akkor elkészíthető könnyűsúlyú, és nem fog megfelelni egy külön dokumentumnak).

Nyers adatok

Közeli formátumban dump formátum OrientDB adatbázis, az ArangoDB előző példájában szereplő adatok valahogy így néznek ki:

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

Amint látjuk, a csúcsok a bejövő és kimenő élekről is tárolnak információkat. Nál nél felhasználásával A Document API-nak magát a hivatkozási integritást kell figyelnie, és a Graph API átveszi ezt a munkát. De nézzük meg, hogyan néz ki az OrientDB-hez való hozzáférés a „tiszta” lekérdezési nyelveken, amelyek nincsenek integrálva a programozási nyelvekbe.

Lekérdezések és eredmények

Az OrientDB-ben az ArangoDB példájában szereplő lekérdezéshez hasonló célú lekérdezés így néz ki:

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

Az eredményt a következő formában kapjuk meg:

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

Ha az eredmény formátuma ismét túlságosan „relációs”-nak tűnik, el kell távolítania a következőt: UNWIND():

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

Az OrientDB lekérdezési nyelve SQL-ként írható le Gremlin-szerű beillesztésekkel. A 2.2-es verzióban megjelent egy Cypher-szerű kérési űrlap, 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

Az eredmény formátuma ugyanaz lesz, mint az előző kérésben. Gondolja át, mit kell eltávolítani, hogy „relatívabb” legyen, mint a legelső lekérdezésnél.

Azure CosmosDB

Kisebb mértékben az ArangoDB-ről és az OrientDB-ről fent elmondottak az Azure CosmosDB-re vonatkoznak. A CosmosDB a következő adatelérési API-kat biztosítja: SQL, MongoDB, Gremlin és Cassandra.

Az SQL API és a MongoDB API a dokumentummodell adatainak eléréséhez használható. Gremlin API és Cassandra API - az adatok grafikon- és oszlopformátumú eléréséhez. Az összes modell adatai a CosmosDB belső modellformátumban kerülnek mentésre: ARS („atom-rekord-sorozat”), amely szintén közel áll a dokumentumhoz.

De a felhasználó által választott adatmodell és a használt API rögzítve van a fiók létrehozásának időpontjában a szolgáltatásban. Az egyik modellbe betöltött adatokhoz nem lehet hozzáférni egy másik modell formátumában, amint azt valami ilyesmi szemlélteti:

Így az Azure CosmosDB többmodellje ma csak egy gyártó különböző modelljeit támogató több adatbázis használatának képessége, ami nem oldja meg a többváltozatos tárolás minden problémáját.

Többmodell DBMS gráfmodell alapján?

Figyelemre méltó az a tény, hogy még nincsenek a piacon olyan többmodelles DBMS-ek, amelyek gráfmodellre épülnének (kivéve az egyidejűleg két gráfmodell többmodell támogatását: RDF és LPG; lásd: korábbi kiadvány). A legnagyobb nehézségeket az okozza, hogy egy dokumentummodellt egy gráfmodellre kell megvalósítani, nem pedig egy relációs modellre.

A gráfmodell kialakításánál is felmerült az a kérdés, hogy hogyan lehet relációs modellt megvalósítani a gráfmodellre. Hogyan mondottPéldául David McGovern:

A gráf-megközelítésben semmi sem akadályozza meg egy olyan réteg létrehozását (pl. megfelelő indexeléssel) egy gráfadatbázison, amely lehetővé teszi a relációs nézetet (1) a sorok helyreállításával a szokásos kulcsértékpárokból és (2) az értékek csoportosításával. sorok relációtípus szerint.

Amikor egy dokumentummodellt grafikonmodellre implementál, szem előtt kell tartania például a következőket:

A JSON-tömb elemeit rendezettnek tekintjük, de a gráf élének csúcsából kiinduló elemeket nem;
A dokumentummodellben lévő adatok általában denormalizáltak; továbbra sem kívánja ugyanabból a beágyazott dokumentumból több másolatot tárolni, és az aldokumentumoknak általában nincs azonosítójuk;
Másrészt a dokumentum-DBMS-ek ideológiája az, hogy a dokumentumok kész „aggregátumok”, amelyeket nem kell minden alkalommal újra felépíteni. A gráfmodellnek biztosítania kell azt a képességet, hogy gyorsan megkapja a kész dokumentumnak megfelelő részgráfot.

Némi reklám

A cikk szerzője a NitrosBase DBMS fejlesztéséhez kapcsolódik, melynek belső modellje a gráf, a külső - relációs és dokumentum - modellek pedig reprezentációi. Minden modell egyenlő: szinte bármilyen adat elérhető bármelyikben a számára természetes lekérdezési nyelv használatával. Sőt, az adatok bármely nézetben módosíthatók. A változások a belső modellben és ennek megfelelően más nézetekben is megjelennek.

Remélhetőleg a következő cikkek egyikében leírom, hogyan néz ki a modellillesztés a NitrosBase-ben.

Következtetés

Remélem, hogy az úgynevezett multi-modellezés általános körvonalai többé-kevésbé világosak az olvasó számára. A többmodell DBMS-ek meglehetősen eltérőek, és a „több modell támogatása” másképp nézhet ki. Ahhoz, hogy megértsük, mit nevezünk „többmodellnek” minden konkrét esetben, hasznos megválaszolni a következő kérdéseket:

A hagyományos modellek támogatásáról beszélünk, vagy valamilyen „hibrid” modellről?
A modellek „egyenrangúak”, vagy egyikük a többi tárgya?
A modellek „közömbösek” egymás iránt? Az egyik modellben írt adatok beolvashatók egy másikban, vagy akár felülírhatók?

Azt gondolom, hogy a többmodelles DBMS-ek relevanciájával kapcsolatos kérdésre már most is pozitívan lehet válaszolni, de az érdekes kérdés, hogy melyik típusra lesz nagyobb kereslet a közeljövőben. Úgy tűnik, hogy a hagyományos, elsősorban relációs modelleket támogató többmodell DBMS-ekre nagyobb lesz a kereslet; A többmodelles DBMS-ek népszerűsége, amelyek új modelleket kínálnak, amelyek egyesítik a különféle hagyományosok előnyeit, a távolabbi jövő kérdése.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.