Sistemet moderne të informacionit janë mjaft komplekse. Mbi të gjitha, kompleksiteti i tyre është për shkak të kompleksitetit të të dhënave të përpunuara në to. Kompleksiteti i të dhënave shpesh qëndron në shumëllojshmërinë e modeleve të të dhënave të përdorura. Kështu, për shembull, kur të dhënat bëhen "të mëdha", një nga karakteristikat problematike nuk është vetëm vëllimi i tyre ("vëllimi"), por edhe shumëllojshmëria e tyre ("larmia").

Nëse ende nuk keni gjetur ndonjë të metë në arsyetim, atëherë lexoni më tej.

Përmbajtje

Këmbëngulja poliglote
Multi-model
DBMS me shumë modele bazuar në modelin relacional
     Modeli i dokumentit në MS SQL Server
     Modeli i grafikut në MS SQL Server
DBMS me shumë modele bazuar në modelin e dokumentit
     Modeli relacional në MarkLogic
     Modeli i grafikut në MarkLogic
DBMS me shumë modele "pa një model kryesor"
     ArangoDB
     OrientDB
     Azure CosmosDB
DBMS me shumë modele bazuar në një model grafik?
Përfundim
Опрос

Këmbëngulja poliglote

Sa më sipër çon në faktin se ndonjëherë edhe brenda kornizës së një sistemi është e nevojshme të përdoren disa DBMS të ndryshme për ruajtjen e të dhënave dhe zgjidhjen e problemeve të ndryshme të përpunimit të tyre, secila prej të cilave mbështet modelin e vet të të dhënave. Me dorën e lehtë të M. Fowler, autori një numër librash të famshëm dhe një prej bashkautorë Manifesti i shkathët, kjo situatë quhet ruajtje me shumë variante ("Këmbëngulja e poligloteve").

Fowler ka gjithashtu shembullin e mëposhtëm të organizimit të ruajtjes së të dhënave në një aplikacion me funksione të plota dhe me ngarkesë të lartë në fushën e tregtisë elektronike.

Ky shembull, natyrisht, është disi i ekzagjeruar, por mund të gjenden disa konsiderata në favor të zgjedhjes së një ose një tjetër DBMS për qëllimin përkatës, për shembull, këtu.

Është e qartë se të jesh shërbëtor në një kopsht të tillë zoologjik nuk është e lehtë.

Sasia e kodit që kryen ruajtjen e të dhënave rritet në përpjesëtim me numrin e DBMS-ve të përdorura; sasia e të dhënave që sinkronizojnë kodin është e mirë nëse jo proporcionale me katrorin e këtij numri.
Si shumëfish i numrit të DBMS-ve të përdorura, rriten kostot e sigurimit të karakteristikave të ndërmarrjes (shkallëzueshmëria, toleranca ndaj gabimeve, disponueshmëria e lartë) e secilit prej DBMS-ve të përdorura.
Është e pamundur të sigurohen karakteristikat e ndërmarrjes të nënsistemit të ruajtjes në tërësi - veçanërisht transaksionaliteti.

Nga këndvështrimi i drejtorit të kopshtit zoologjik, gjithçka duket kështu:

Një rritje e shumëfishtë në koston e licencave dhe mbështetjes teknike nga prodhuesi i DBMS.
Mbi personel dhe afate të shtuara.
Humbje të drejtpërdrejta financiare ose gjoba për shkak të mospërputhjes së të dhënave.

Ka një rritje të konsiderueshme në koston totale të pronësisë së sistemit (TCO). A ka ndonjë rrugëdalje nga situata e "opsioneve të shumëfishta të ruajtjes"?

Multi-model

Termi "ruajtje me shumë variacione" hyri në përdorim në 2011. Ndërgjegjësimi për problemet e qasjes dhe kërkimi i një zgjidhjeje zgjati disa vjet dhe deri në vitin 2015, përmes gojës së analistëve të Gartner, përgjigja u formulua:

nga "Udhëzues tregu për NoSQL DBMS - 2015'

E ardhmja e DBMS-ve, arkitekturave të tyre dhe mënyrave të përdorimit të tyre është multimodel.
nga "Kuadranti Magjik për ODBMS - 2016'

DBMS-të kryesore operative do të ofrojnë modele të shumta - relacionale dhe jo-relacionale - si pjesë e një platforme të vetme.

Duket se këtë herë analistët e Gartner kishin të drejtë me parashikimin e tyre. Nëse shkoni në faqen me vlerësimi kryesor DBMS në DB-Engines, ju mund ta shihni këtëоShumica e drejtuesve të saj pozicionohen në mënyrë specifike si DBMS me shumë modele. E njëjta gjë mund të shihet në faqen me çdo vlerësim privat.

Tabela e mëposhtme tregon DBMS - liderët në secilin prej vlerësimeve private, të cilat pretendojnë të jenë shumë modele. Për çdo DBMS, tregohet modeli origjinal i mbështetur (i cili dikur ishte i vetmi) dhe së bashku me të modelet e mbështetura aktualisht. Gjithashtu renditen DBMS-të që pozicionohen si "fillimisht shumë-modele" dhe, sipas krijuesve, nuk kanë ndonjë model fillestar të trashëguar.

DBMS	Modeli fillestar	Modele shtesë
Orakull	Relacionale	Grafiku, dokumenti
MS SQL	Relacionale	Grafiku, dokumenti
PostgreSQL	Relacionale	Grafik*, dokument
MarkLogic	Dokumentar	Grafiku, relacional
MongoDB	Dokumentar	Vlera kryesore, grafiku*
DataStax	Kolonë e gjerë	Dokumentar, grafik
Redis	Çelës-vlerë	Dokumentar, grafik*
ArangoDB	-	Grafiku, dokumenti
OrientDB	-	Grafik, dokument, relacional
Azure CosmosDB	-	Grafik, dokument, relacional

Shënime në tryezë

Yjet në tabelë shënojnë deklarata që kërkojnë rezerva:

PostgreSQL DBMS nuk e mbështet modelin e të dhënave të grafikut, por ky produkt e mbështet atë bazuar në të, të tilla si AgensGraph.
Në lidhje me MongoDB, është më e saktë të flasim për praninë e operatorëve grafikë në gjuhën e pyetjes ($lookup, $graphLookup) se sa për mbështetjen e modelit të grafikut, megjithëse, natyrisht, futja e tyre kërkonte disa optimizime në nivelin e ruajtjes fizike në drejtim të mbështetjes së modelit të grafikut.
Në lidhje me Redis nënkuptojmë zgjatjen RedisGraph.

Më pas, për secilën nga klasat, ne do të tregojmë se si mbështetja për disa modele zbatohet në DBMS nga kjo klasë. Ne do t'i konsiderojmë modelet relacionale, të dokumenteve dhe të grafikëve si më të rëndësishmet dhe do të përdorim shembuj të DBMS-ve specifike për të treguar se si zbatohen "ato që mungojnë".

DBMS me shumë modele bazuar në modelin relacional

DBMS-të kryesore aktualisht janë relacionale; parashikimi i Gartner nuk mund të konsiderohet i vërtetë nëse RDBMS-të nuk tregojnë lëvizje në drejtim të shumë-modelimit. Dhe ata demonstrojnë. Tani ideja që një DBMS me shumë modele është si një thikë zvicerane, e cila nuk mund të bëjë asgjë mirë, mund t'i drejtohet drejtpërdrejt Larry Ellison.

Autori, megjithatë, preferon zbatimin e multi-modelimit në Microsoft SQL Server, në shembullin e të cilit do të përshkruhet mbështetja RDBMS për modelet e dokumenteve dhe grafikëve.

Modeli i dokumentit në MS SQL Server

Ka pasur tashmë dy artikuj të shkëlqyer në Habré rreth mënyrës se si MS SQL Server zbaton mbështetjen për modelin e dokumentit; unë do të kufizohem në një ritregim dhe koment të shkurtër:

Mënyra për të mbështetur modelin e dokumentit në MS SQL Server është mjaft tipike për DBMS-të relacionale: Dokumentet JSON propozohen të ruhen në fusha të zakonshme teksti. Mbështetja për modelin e dokumentit është të sigurojë operatorë të veçantë për të analizuar këtë JSON:

JSON_VALUE për të nxjerrë vlerat skalare të atributeve,
JSON_QUERY për nxjerrjen e nën-dokumenteve.

Argumenti i dytë i të dy operatorëve është një shprehje në sintaksën e ngjashme me JSONPath.

Në mënyrë abstrakte, mund të themi se dokumentet e ruajtura në këtë mënyrë nuk janë "entitete të klasit të parë" në një DBMS relacionale, ndryshe nga tuplet. Konkretisht, në MS SQL Server aktualisht nuk ka indekse në fushat e dokumenteve JSON, gjë që e bën të vështirë bashkimin e tabelave duke përdorur vlerat e këtyre fushave dhe madje edhe zgjedhjen e dokumenteve duke përdorur këto vlera. Sidoqoftë, është e mundur të krijohet një kolonë e llogaritur për një fushë të tillë dhe një indeks në të.

Për më tepër, MS SQL Server ofron mundësinë për të ndërtuar me lehtësi një dokument JSON nga përmbajtja e tabelave duke përdorur operatorin FOR JSON PATH - një mundësi, në një kuptim të caktuar, e kundërt me atë të mëparshme, ruajtje konvencionale. Është e qartë se sado i shpejtë të jetë një RDBMS, kjo qasje bie ndesh me ideologjinë e DBMS-ve të dokumenteve, të cilat në thelb ruajnë përgjigje të gatshme për pyetjet e njohura dhe mund të zgjidhin vetëm problemet e lehtësisë së zhvillimit, por jo shpejtësisë.

Së fundi, MS SQL Server ju lejon të zgjidhni problemin e kundërt të ndërtimit të dokumentit: ju mund të zbërtheni JSON në tabela duke përdorur OPENJSON. Nëse dokumenti nuk është plotësisht i sheshtë, do t'ju duhet ta përdorni CROSS APPLY.

Modeli i grafikut në MS SQL Server

Mbështetja për modelin e grafikut (LPG) është implementuar plotësisht edhe në Microsoft SQL Server e parashikueshme: Propozohet përdorimi i tabelave speciale për ruajtjen e nyjeve dhe për ruajtjen e skajeve të grafikut. Tabelat e tilla krijohen duke përdorur shprehje CREATE TABLE AS NODE и CREATE TABLE AS EDGE respektivisht.

Tabelat e llojit të parë janë të ngjashme me tabelat e zakonshme për ruajtjen e të dhënave, me ndryshimin e vetëm të jashtëm që tabela përmban një fushë sistemi $node_id — identifikues unik i një nyje grafiku brenda bazës së të dhënave.

Në mënyrë të ngjashme, tabelat e llojit të dytë kanë fusha të sistemit $from_id и $to_id, hyrjet në tabela të tilla përcaktojnë qartë lidhjet ndërmjet nyjeve. Një tabelë e veçantë përdoret për të ruajtur marrëdhëniet e secilit lloj.

Le ta ilustrojmë këtë me një shembull. Lërini të dhënat e grafikut të kenë një plan urbanistik si ai i paraqitur në figurë. Pastaj për të krijuar strukturën përkatëse në bazën e të dhënave, duhet të ekzekutoni pyetjet e mëposhtme 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);

Specifikimi kryesor i tabelave të tilla është se në pyetjet kundër tyre është e mundur të përdoren modele grafiku me sintaksë të ngjashme me Cypher (megjithatë, "*"etj nuk janë ende të mbështetur). Bazuar në matjet e performancës, mund të supozohet gjithashtu se mënyra se si ruhen të dhënat në këto tabela është e ndryshme nga mënyra se si ruhen të dhënat në tabelat e rregullta dhe janë të optimizuara për ekzekutimin e pyetjeve të tilla grafike.

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

Për më tepër, është mjaft e vështirë të mos përdoren këto modele grafiku kur punoni me tabela të tilla, pasi në pyetjet e zakonshme SQL për të zgjidhur probleme të ngjashme do të jetë e nevojshme të bëhen përpjekje shtesë për të marrë identifikuesit e nyjeve "grafike" të sistemit ($node_id, $from_id, $to_id; Për të njëjtën arsye, pyetjet për futjen e të dhënave nuk shfaqen këtu pasi janë të panevojshme të rënda).

Për të përmbledhur përshkrimin e zbatimeve të modeleve të dokumenteve dhe grafikëve në MS SQL Server, do të vëreja se zbatime të tilla të një modeli mbi tjetrin nuk duken të suksesshme, kryesisht nga pikëpamja e dizajnit të gjuhës. Është e nevojshme të zgjerohet një gjuhë me një tjetër, gjuhët nuk janë plotësisht "ortogonale", rregullat e përputhshmërisë mund të jenë mjaft të çuditshme.

DBMS me shumë modele bazuar në modelin e dokumentit

Në këtë seksion, unë do të doja të ilustroja zbatimin e shumë modeleve në DBMS-të e dokumenteve duke përdorur shembullin e jo më të njohurit prej tyre, MongoDB (siç u tha, ai ka vetëm operatorë grafik të kushtëzuar $lookup и $graphLookup, duke mos punuar në koleksione të copëtuara), por duke përdorur shembullin e një DBMS më të pjekur dhe "sipërmarrëse" MarkLogic.

Pra, le të përmbajë koleksioni një grup dokumentesh XML të llojit të mëposhtëm (MarkLogic ju lejon gjithashtu të ruani dokumente JSON):

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

Modeli relacional në MarkLogic

Një pamje relacionale e një koleksioni dokumentesh mund të krijohet duke përdorur shabllonin e shfaqjes (përmbajtja e elementeve value në shembullin e mëposhtëm mund të ketë një XPath arbitrar):

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

Ju mund të adresoni pamjen e krijuar me një pyetje SQL (për shembull, nëpërmjet ODBC):

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

Fatkeqësisht, pamja relacionale e krijuar nga shablloni i ekranit është vetëm për lexim. Kur përpunon një kërkesë për të, MarkLogic do të përpiqet ta përdorë indekset e dokumenteve. Më parë, MarkLogic kishte pikëpamje të kufizuara relacionale, tërësisht bazuar në indeks dhe të shkrueshme, por tani ato konsiderohen të zhvlerësuara.

Modeli i grafikut në MarkLogic

Me mbështetjen për modelin e grafikut (RDF), gjithçka është pothuajse e njëjtë. Përsëri me ndihmën shabllonin e shfaqjes ju mund të krijoni një paraqitje RDF të një koleksioni dokumentesh nga shembulli i mësipërm:

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

Ju mund të adresoni grafikun RDF që rezulton me një pyetje SPARQL:

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

Ndryshe nga ai relacional, MarkLogic mbështet modelin e grafikut në dy mënyra të tjera:

Një DBMS mund të jetë një ruajtje e plotë e veçantë e të dhënave RDF (treshe në të do të quhen menaxhuar në ndryshim nga ato të përshkruara më sipër ekstraktuar).
RDF në serializimin special thjesht mund të futet në dokumentet XML ose JSON (dhe trinjakët do të thirren më pas unmanaged). Kjo është ndoshta një alternativë ndaj mekanizmave idref etj

Një ide e mirë se si funksionojnë gjërat "me të vërtetë" në MarkLogic jepet nga API optike, në këtë kuptim, ai është i nivelit të ulët, megjithëse qëllimi i tij është më tepër i kundërt - të përpiqet të abstragojë nga modeli i të dhënave të përdorur, të sigurojë punë konsistente me të dhënat në modele të ndryshme, transaksionalitet, etj.

DBMS me shumë modele "pa një model kryesor"

Në treg ka edhe DBMS që pozicionohen fillimisht si multimodele, pa asnjë model kryesor të trashëguar. Kjo perfshin ArangoDB, OrientDB (që nga viti 2018 kompania e zhvillimit i përket SAP) dhe CosmosDB (shërbim si pjesë e platformës cloud të Microsoft Azure).

Në fakt, ka modele "thelbësore" në ArangoDB dhe OrientDB. Në të dyja rastet, këto janë modelet e tyre të të dhënave, të cilat janë përgjithësime të një dokumenti. Përgjithësimet janë kryesisht për të lehtësuar aftësinë për të kryer pyetje të një natyre grafike dhe relacionale.

Këto modele janë të vetmet të disponueshme për përdorim në DBMS të specifikuara; gjuhët e tyre të pyetjeve janë krijuar për të punuar me to. Sigurisht, modele të tilla dhe DBMS janë premtuese, por mungesa e përputhshmërisë me modelet dhe gjuhët standarde e bën të pamundur përdorimin e këtyre DBMS-ve në sistemet e trashëgimisë - për të zëvendësuar DBMS-të e përdorura tashmë atje.

Kishte tashmë një artikull të mrekullueshëm rreth ArangoDB dhe OrientDB në Habré: BASHKOHU në bazat e të dhënave NoSQL.

ArangoDB

ArangoDB pretendon mbështetje për një model të të dhënave grafike.

Nyjet e një grafiku në ArangoDB janë dokumente të zakonshme, dhe skajet janë dokumente të një lloji të veçantë që, së bashku me fushat e rregullta të sistemit, kanë (_key, _id, _rev) fushat e sistemit _from и _to. Dokumentet në DBMS-të e dokumenteve kombinohen tradicionalisht në koleksione. Koleksionet e dokumenteve që përfaqësojnë skajet quhen koleksione të skajeve në ArangoDB. Nga rruga, dokumentet e mbledhjes së skajeve janë gjithashtu dokumente, kështu që skajet në ArangoDB mund të veprojnë gjithashtu si nyje.

Të dhënat fillestare

Le të kemi një koleksion persons, dokumentet e të cilit duken kështu:

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

Le të ketë edhe një koleksion cafes:

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

Pastaj koleksioni likes mund të duket kështu:

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

Pyetjet dhe rezultatet

Një pyetje e stilit grafik në gjuhën AQL e përdorur në ArangoDB, që kthen informacione në formë të lexueshme nga njeriu se kush pëlqen cilën kafene, duket kështu:

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

Në një stil relacional, ku ne jemi duke "llogaritur" marrëdhëniet në vend që t'i ruajmë ato, kjo pyetje mund të rishkruhet kështu (nga rruga, pa koleksionin likes mund të bënte pa):

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 }

Rezultati në të dyja rastet do të jetë i njëjtë:

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

Më shumë pyetje dhe rezultate

Nëse formati i rezultatit të mësipërm duket të jetë më tipik për një DBMS relacionale sesa për një DBMS dokumenti, mund të provoni këtë pyetje (ose mund të përdorni COLLECT):

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

Rezultati do të duket si ky:

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

OrientDB

Baza për zbatimin e një modeli grafiku në krye të një modeli dokumenti në OrientDB është mundësi fushat e dokumentit, përveç vlerave pak a shumë standarde skalare, kanë edhe vlera të llojeve si p.sh LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Vlerat e këtyre llojeve janë lidhje ose koleksione lidhjesh në identifikuesit e sistemit dokumentet.

Identifikuesi i dokumentit i caktuar nga sistemi ka një "kuptim fizik", që tregon pozicionin e regjistrimit në bazën e të dhënave dhe duket diçka si kjo: @rid : #3:16. Kështu, vlerat e vetive të referencës janë në të vërtetë tregues (si në modelin e grafikut) sesa kushte përzgjedhjeje (si në modelin relacional).

Ashtu si ArangoDB, skajet në OrientDB përfaqësohen si dokumente të veçanta (edhe pse nëse një skaj nuk ka vetitë e veta, ai mund të bëhet peshë e lehtë, dhe nuk do të korrespondojë me një dokument të veçantë).

Të dhënat fillestare

Në një format të afërt me format hale Baza e të dhënave OrientDB, të dhënat nga shembulli i mëparshëm për ArangoDB do të dukeshin diçka si kjo:

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

Siç mund ta shohim, kulmet gjithashtu ruajnë informacione për skajet hyrëse dhe dalëse. Në duke përdorur Document API duhet të monitorojë vetë integritetin e referencës dhe Graph API merr përsipër këtë punë. Por le të shohim se si duket qasja në OrientDB në gjuhët e pyetjeve "të pastra" që nuk janë të integruara në gjuhët e programimit.

Pyetjet dhe rezultatet

Një pyetje e ngjashme në qëllim me pyetjen nga shembulli për ArangoDB në OrientDB duket si kjo:

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

Rezultati do të merret në formën e mëposhtme:

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

Nëse formati i rezultatit përsëri duket shumë "relativ", duhet të hiqni rreshtin me UNWIND():

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

Gjuha e pyetjeve të OrientDB mund të përshkruhet si SQL me inserte të ngjashme me Gremlin. Në versionin 2.2, u shfaq një formular kërkese si 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

Formati i rezultatit do të jetë i njëjtë si në kërkesën e mëparshme. Mendoni se çfarë duhet hequr për ta bërë atë më "relacionale", si në pyetjen e parë.

Azure CosmosDB

Në një masë më të vogël, ajo që u tha më lart për ArangoDB dhe OrientDB vlen për Azure CosmosDB. CosmosDB ofron API-të e mëposhtme të aksesit të të dhënave: SQL, MongoDB, Gremlin dhe Cassandra.

SQL API dhe MongoDB API përdoren për të aksesuar të dhënat në modelin e dokumentit. Gremlin API dhe Cassandra API - për aksesin e të dhënave në formatet e grafikëve dhe kolonave, përkatësisht. Të dhënat në të gjitha modelet ruhen në formatin e modelit të brendshëm CosmosDB: ARS (“atom-record-sequence”), i cili është gjithashtu i afërt me atë të dokumentit.

Por modeli i të dhënave të zgjedhur nga përdoruesi dhe API i përdorur janë fiksuar në momentin e krijimit të një llogarie në shërbim. Nuk është e mundur të aksesoni të dhënat e ngarkuara në një model në formatin e një modeli tjetër, siç ilustrohet nga diçka si kjo:

Kështu, shumë-modeli në Azure CosmosDB sot është vetëm aftësia për të përdorur disa baza të dhënash që mbështesin modele të ndryshme nga një prodhues, gjë që nuk zgjidh të gjitha problemet e ruajtjes me shumë variante.

DBMS me shumë modele bazuar në një model grafik?

Vlen të përmendet fakti se nuk ka ende në treg DBMS me shumë modele që bazohen në një model grafik (përveç mbështetjes me shumë modele për dy modele grafike njëkohësisht: RDF dhe LPG; shih këtë në publikimi i mëparshëm). Vështirësitë më të mëdha shkaktohen nga zbatimi i një modeli dokumenti në krye të një modeli grafik, në vend të një modeli relacional.

Çështja se si të zbatohet një model relacional në krye të modelit grafik është marrë parasysh edhe gjatë formimit të këtij të fundit. Si foli, për shembull, David McGovern:

Nuk ka asgjë të natyrshme në qasjen e grafikut që pengon krijimin e një shtrese (p.sh., me indeksim të përshtatshëm) në një bazë të dhënash grafiku që mundëson një pamje relacionale me (1) rikuperimin e tuples nga çiftet e zakonshme të vlerave kryesore dhe (2) grupimin e tuples sipas llojit të lidhjes.

Kur zbatoni një model dokumenti mbi një model grafiku, duhet të keni parasysh, për shembull, sa vijon:

Elementet e një grupi JSON konsiderohen të renditura, por ato që dalin nga kulmi i një skaji të grafikut nuk janë;
Të dhënat në modelin e dokumentit zakonisht denormalizohen; ju ende nuk dëshironi të ruani disa kopje të të njëjtit dokument të integruar dhe nëndokumentet zakonisht nuk kanë identifikues;
Nga ana tjetër, ideologjia e DBMS-ve të dokumenteve është se dokumentet janë "agregate" të gatshme që nuk kanë nevojë të ndërtohen përsëri çdo herë. Kërkohet të sigurohet modeli i grafikut me aftësinë për të marrë shpejt një nëngraf që korrespondon me dokumentin e përfunduar.

Pak reklamë

Autori i artikullit është i lidhur me zhvillimin e NitrosBase DBMS, modeli i brendshëm i të cilit është grafiku, dhe modelet e jashtme - relacionale dhe dokumentare - janë përfaqësimet e tij. Të gjitha modelet janë të barabarta: pothuajse çdo e dhënë është e disponueshme në cilindo prej tyre duke përdorur një gjuhë pyetjesh që është e natyrshme për të. Për më tepër, në çdo pamje, të dhënat mund të ndryshohen. Ndryshimet do të reflektohen në modelin e brendshëm dhe, në përputhje me rrethanat, në pikëpamje të tjera.

Unë shpresoj se do të përshkruaj se si duket përputhja e modelit në NitrosBase në një nga artikujt e mëposhtëm.

Përfundim

Shpresoj që skicat e përgjithshme të asaj që quhet multimodelim të jenë bërë pak a shumë të qarta për lexuesin. DBMS-të me shumë modele janë mjaft të ndryshme dhe "mbështetja me shumë modele" mund të duket ndryshe. Për të kuptuar atë që quhet "multi-model" në secilin rast specifik, është e dobishme t'i përgjigjeni pyetjeve të mëposhtme:

Po flasim për mbështetjen e modeleve tradicionale apo për një lloj modeli “hibrid”?
A janë modelet “të barabarta”, apo njëri prej tyre është subjekt i të tjerëve?
A janë modelet “indiferente” ndaj njëra-tjetrës? A mund të lexohen të dhënat e shkruara në një model në një tjetër apo edhe të mbishkruhen?

Unë mendoj se pyetja në lidhje me rëndësinë e DBMS me shumë modele tashmë mund të përgjigjet pozitivisht, por pyetja interesante është se cilat lloje të tyre do të jenë më të kërkuara në të ardhmen e afërt. Duket se DBMS me shumë modele që mbështesin modelet tradicionale, kryesisht relacionale, do të jenë më të kërkuara; Popullariteti i DBMS-ve me shumë modele, duke ofruar modele të reja që kombinojnë avantazhet e atyre tradicionale të ndryshme, është një çështje e së ardhmes më të largët.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem

A përdorni DBMS me shumë modele?

Ne nuk e përdorim atë, ne ruajmë gjithçka në një DBMS dhe në një model
Ne përdorim aftësitë shumë-modele të DBMS-ve tradicionale
Ne praktikojmë këmbënguljen poliglote
Ne përdorim DBMS të reja me shumë modele (Arango, Orient, CosmosDB)

19 përdorues votuan. 4 përdorues abstenuan.

Burimi: www.habr.com

A janë DBMS-të me shumë modele baza e sistemeve moderne të informacionit?