Kaasaegsed teabevõrgustikud on piisavalt keerulised. Nende keerukust põhjustab osaliselt ka töötlemiseks kasutatavate andmete keerukus. Andmete keerukus seisneb sageli kasutatavate andmemudelite mitmekesisuses. Näiteks, kui andmed muutuvad „suureks”, on üheks ebamugavust tekitavaks tunnuseks mitte ainult nende maht („volume”), vaid ka nende mitmekesisus („variety”).

Kui te ei leia veel arutlustest puudusi, siis lugege edasi.

Sisukord

Polyglot persistence
Multimodaalsus
Multimodaalsed andmebaasisüsteemid relatsioonilisest mudelist
     Dokumendimudel MS SQL Serveris
     Graafikamudel MS SQL Serveris
Multimodaalsed andmebaasisüsteemid dokumendimudelist
     Relatsiooniline mudel MarkLogicis
     Graafikamudel MarkLogicis
Multimodaalsed andmebaasisüsteemid „ilma põhimmudelta”
     ArangoDB
     OrientDB
     Azure CosmosDB
Multimodaalsed andmebaasisüsteemid graafikamudelist?
Kokkuvõte
Küsitlus

Polyglot persistence

Ülaltoodust tuleneb, et sageli tuleb isegi ühe süsteemi raames andmete hoidmiseks ja nende töötlemise erinevate ülesannete lahendamiseks kasutada mitmeid erinevaid andmebaasisüsteeme, millest igaüks toetab oma andmemudelit. Tänu M. Fowlerile, autor mitme tuntud raamatu ja ühe kaasautori Agile Manifesto, sai see olukord nimeks polüglot-hoidmine „(polyglot persistence)”.

Fowlerile kuulub ka järgmine näide andmete hoidmise korraldamisest funktsionaalses ja kõrgelt koormatud rakenduses e-kaubanduse vallas.

See näide on loomulikult veidi liialdatud, kuid mõningaid kaalutlusi vastava andmebaasisüsteemi valiku kasuks võib leida näiteks siin.

Selge on, et olla teenistuses sellises loomaaia süsteemis ei ole kerge.

• Andmete salvestamise koodi maht kasvab proportsionaalselt kasutatavate andmebaasisüsteemide arvuga; andmete sünkroniseerimise koodi maht — hea, kui mitte proportsionaalselt selle arvu ruuduga.
• Kasutatavate andmebaasisüsteemide arvu suurenemisega kasvavad ka kulud enterprise-omaduste (skaaleeritavuse, rikke suhtes vastupidavuse, kõrge saadavuse) tagamiseks iga kasutatava andmebaasisüsteemi jaoks.
• Ei ole võimalik tagada enterprise-omadusi andmete hoidmise all­süsteemi jaoks – eriti tehingute osas.

Loomaaia direktori vaatepunktist näeb see välja nii:

• Suurenenud litsentside ja andmebaasisüsteemi tootja toe kulude kordamine.
• Riigi töötajate arvu suurenemine ja tähtaegade pikenemine.
• Otsesed rahalised kahjud või karistusmeetmed andmete kokkusobimatuse tõttu.

Kogutud süsteemi omamise kogu maksumuse (TCO) märkimisväärne kasvu. Kas olukorrast „mitme variandi hoidmine” on mingisugune väljapääs?

Multimodaalsus

Mõisted „mitme variandi hoidmine” said laiemalt tuntuks 2011. aastal. Probleemide mõistmine ja lahenduse leidmine võttis mitu aastat ning 2015. aastaks oli Gartneri analüütikute poolt vastus välja pakutud:

• Käes on „Market Guide for NoSQL DBMSs — 2015»:
  

  Tulevik andmebaasidest, nende arhitektuuridest ja kasutusviisidest — multimudelisus.

• Käes on „Magic Quadrant for ODBMS — 2016»:
  

  Tippkvaliteediga opereerivad andmebaasid pakuvad mitmeid mudeleid — nii relatsioonilisi kui ka mittesuhteid — ühes platvormis.

Tundub, et seekord ei eksinud Gartneri analüütikud prognoosimisega. Kui vaadata lehte, kus asub peamine reiting andmebaaside kohta DB-Engines, on näha, etilotkaenamik nende liidritest positsioneerib end just multimudelisena. Sama võib näha ka igas eraldi reitingus.

Allpool on tabel, kus on näidatud andmebaasid — liidrid igas eraldi reitingus, kes väidavad oma multimudelisust. Iga andmebaasi puhul on näidatud algne toetatud mudel (mis kunagi oli ainus) ja koos sellega mudelid, mida toetatakse praegu. Samuti on esitatud andmebaasid, kes positsioneerivad end „alguses multimudelisena”, ilma algse pärandmudelita, nagu väidavad nende loojad.

Märkused tabelisse

Tabelis on tähistatud tähtedega väited, mis vajavad ettevaatust:

• Andmebaas PostgreSQL ei toeta graafikamudeleid, kuid selline toode toetab seda sellel alusel, nagu näiteks AgensGraph.
• MongoDB puhul oleks õigem rääkida pigem graafikute operaatorite olemasolust päringute keeles ($lookup, $graphLookup), kui graafikamudeli toetamisest, kuigi nende loomine nõudis mõningaid optimeerimisi füüsilise salvestamise tasandil graafikamudeli toetamiseks.
• Redis'e puhul räägitakse laiendamisest. RedisGraph.

Edasi vaatame iga klassi puhul, kuidas toetatakse mitmeid mudeleid andmebaasis, mis kuulub sellesse klassi. Olulisimateks mudeliteks peame suhtelist, dokumendi- ja graafikamudeleid ning toome näiteid konkreetsest andmebaasist, et näidata, kuidas „puuduvad“ mudelid on rakendatud.

Multimodaalsed andmebaasisüsteemid relatsioonilisest mudelist

Peamisteks andmebaasides praegu on suhtelised, Gartneri prognoosi kohaselt ei saaks pidada täitunuks, kui RDBMS ei näitaks suundi mitmemudelilisuse suunas. Ja nad näitavad. Nüüd võib mõtteid selle kohta, et mitmemudeliline RDBMS on nagu Šveitsi armee nuga, millega ei saa midagi hästi teha, suunata otse Larry Ellisonile.

Autorile meeldib siiski rohkem mitmemudelilisuse rakendamine Microsoft SQL Serveris, mille näitel kirjeldatakse dokumentide ja graafikamudelite toetust RDBMS-is.

Dokumendimudel MS SQL Serveris

MS SQL Serveris, kuidas on rakendatud dokumentide mudeli tugi, on juba olnud kaks suurepärast artiklit Habrist, piirdun lühikese kokkuvõtte ja kommentaariga:

• Töötamine JSON-iga SQL Serveris 2016
• SQL Server 2017 JSON

Dokumentide mudeli toetamise viis MS SQL Serveris on piisavalt tüüpiline suhteliste andmebaaside jaoks: JSON-dokumendid on soovitatav salvestada tavalistesse tekstiväljadele. Dokumentide mudeli tugi seisneb selles, et pakutakse spetsiaalseid operaatorite JSON-i analüüsimiseks:

• JSON_VALUE atribuutide skalaarsed väärtused väljavõtmiseks,
• JSON_QUERY alamdokumendi väljavõtmiseks.

Mõlema operaatori teine argument on väljend JSONPath-sarnases süntaksis.

Üldiselt võib öelda, et selle viisil salvestatud dokumendid ei ole suhtelises andmebaasis „esimese klassi entiteedid“, erinevalt kinnitusest. Konkreetsemalt puuduvad MS SQL Serveris praegu indeksid JSON-dokumentide väljade jaoks, mis raskendab tabelite ühendamise operatsioone nende väli väärtuste järgi ja isegi dokumentide väljavõtmist nende väärtuste järgi. Siiski on võimalik luua kalkuleeritud veerg nii välja kui ka indeks selle piirkonna peale.

Lisaks pakub MS SQL Server mugavat võimalust koostada JSON-dokument tabelite sisust operaatori abil FOR JSON PATH — võimalus, mis on teatud mõttes vastupidine tavapärasele salvestamisele. On selge, et ükskõik kui kiire ka ei oleks RDBMS, on see lähenemine vastupidine dokumentide DBMS ideoloogiale, mis sisuliselt salvestavad valmis vastuseid populaarsetele päringutele ning lahendab vaid arenduse mugavuse, kuid mitte kiirusprobleeme.

Lõpuks võimaldab MS SQL Server lahendada ülesande, mis on vastupidine dokumendi konstruerimisele: JSONi saab jagada tabeliteks, kasutades OPENJSON. Kui dokument ei ole täiesti tasane, tuleb kasutada PIVOT.

Graafikamudel MS SQL Serveris

Graafimudeli (LPG) toetust on Microsoft SQL Serveris ka täiesti ettearvatav: soovitatakse kasutada spetsiaalseid tabeleid sõlmede salvestamiseks ja graafi servade salvestamiseks. Sellised tabelid luuakse väljendite abil CREATE TABLE AS NODE ja CREATE TABLE AS EDGE vastavalt.

Esimese tüübi tabelid sarnanevad tavalistele salvestustabelitele, ainsa väljendatud erinevusega, et tabelis on süsteemiväli $node_id — ainulaadne graafi sõlme identifikaator andmebaasi piires.

Sarnaselt on teise tüübi tabelitel süsteemiväljad $from_id ja $to_id, selliste tabelite kirjed määravad selgelt sidemed sõlmede vahel. Iga tüübi sidemete salvestamiseks kasutatakse eraldi tabelit.

Illustreerime öeldut näitega. Oletame, et graafialased andmed omavad skeemi, nagu on kujutatud antud joonisel. Siis, et luua vastav struktuur andmebaasis, tuleb täita järgmised DDL-päringud:

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

Selliste tabelite peamine eripära on see, et nendele päringutes on võimalik kasutada graafimustreid Cypher-sarnase süntaksiga (kuid "*" jne ei ole veel toetatud). Tootlikkuse mõõtmise põhjal võib samuti eeldada, et andmete salvestamise viis nende tabelites erineb tavapärastest tabelitest ja on optimeeritud selliste graafipäringute täitmiseks.

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

Lisaks on üsna raske töötada selliste tabelitega, ilma et kasutada graafikupatente, sest tavapärastes SQL-päringutes analoogsete probleemide lahendamiseks on vaja teha lisapingutusi, et saada süsteemi 'graafik' sõlmede identifikaatoreid ($node_id, $from_id, $to_id; sama põhjusel ei ole siin toodud andmete sisestamise päringud, kuna need on liiga mahukad).

Kokkuvõtteks MS SQL Serveris dokumentide ja graafimudelite rakenduste kirjeldamisest tahan märkida, et ühe mudeli peal teise rakendamine ei tundu esmajärgulise keelekujunduse seisukohalt õnnestunud. Üht keelt tuleb laiendada teisega, keeled ei ole täielikult 'ortoonaalsed', ühilduvuse reeglid võivad olla üsna kummalised.

Multimodaalsed andmebaasisüsteemid dokumendimudelist

Selles jaotises tahaksin illustreerida mult mudeli rakendust dokumentide andmebaasides, kasutades näidet mitte kõige populaarsemast MongoDB-st (nagu mainitud, sisaldab see vaid tinglikult graafilisi operaatorite $lookup ja $graphLookup, mis ei tööta partiteeritud kogumites), vaid küpsemast ja 'ettevõtte' andmebaasist. MarkLogic.

Nii et oletame, et koguja sisaldab XML-dokumentide kogumit järgmisel kujul (MarkLogic võimaldab ka JSON-dokumentide salvestamist):

John
  Smith

Relatsiooniline mudel MarkLogicis

Dokumentide koguse relatsiooniline esitus võib olla loodud kujundusmalli (elementide sisu value allolevas näites võib olla mis tahes XPath):

/Person
  
    
      Person
      
        
          SSN
          @SSN
          string
        
        
          name
          name
        
        
          surname
          surname

Loodud esitlusele saab viidata SQL-päringuga (näiteks ODBC kaudu):

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

Kahjuks on malliga loodud relatsiooniline esitus ainult lugemiseks. Päringut tööteldes püüab MarkLogic kasutada dokumendi indekseid. Varasemalt oli MarkLogic’il piiratud relatsioonilised esitlused, mis põhinesid täielikult indeksitele ja olid kirjutatav, kuid neid peetakse nüüd aeglaseks.

Graafikamudel MarkLogicis

Graafimudeli (RDF) toetusega on olukord enam-vähem sama. Jällegi on võimalik kujundusmalli luua RDF-esitlus ülaltoodud dokumentide kollektsioonist:

/Person
    
      
        PREFIX
        "http://example.org/example#"
      
    
  
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || surname )
      
    
    
      sem:iri( $PREFIX || @SSN )
      sem:iri( $PREFIX || name )
      

Saadud RDF-graafile saab esitada SPARQL-päringu:

PREFIX : 
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

Erinevalt suhtelisest mudelist toetab MarkLogic graafimudelit ka kahes muus vormis:

1. Andmebaas võib olla täisväärtuslik eraldiseisev RDF-andmete hoidla (kolmnurgad nimetatakse selles managed vastandina ülaltoodud kirjeldusele extracted).
2. RDF eriserealiseerimises võib lihtsalt sisestada XML- või JSON-dokumentidesse (ja kolmnurgasid nimetatakse siis unmanaged). Tõenäoliselt on see alternatiiv mehhanismidele idref ja nii edasi.

Hea ülevaade sellest, kuidas kõik MarkLogicis "päriselt" toimib, annab Optic API, sellega on see madala tasemega, kuigi selle eesmärk on pigem vastupidine — proovida abstraheerida kasutatavast andmemudelist, tagada andmete järgelemine erinevates mudelites, tehingulisus jne.

Multimodaalsed andmebaasisüsteemid „ilma põhimmudelta”

Turul on ka andmebaase, mis positeerivad end algselt multimeedia mudelitena, millel ei ole mingit pärandatud põhimuudelit. Nende hulka kuuluvad ArangoDB, OrientDB (alates 2018. aastast kuulub arendajaettevõte SAPile) ja CosmosDB (teenus osa Microsoft Azure'i pilveplatvormist).

Tegelikult on ArangoDB-l ja OrientDB-l "põhimudelid" olemas. Nii ühes kui teises kaetakse oma andmemudelitega, mis on dokumendi üldistused. Üldistused seisnevad peamiselt võimaluse hõlbustamises esitada graafikuid ja suhetega seotud päringuid.

Need to productively utilize specified DBMS models, their own query languages are designed for this. These models and DBMS are certainly promising, but the lack of compatibility with standard models and languages makes it impossible to use these DBMS in legacy systems — replacing already used DBMS there.

A wonderful article about ArangoDB and OrientDB has already appeared on Habr: JOIN in NoSQL databases.

ArangoDB

ArangoDB claims support for graph data model.

Graph nodes in ArangoDB are regular documents, while edges are special types of documents that have standard system fields along with:_key, _id, _rev) system fields _from ja _to. In document-oriented DBMS, documents are traditionally grouped into collections. Collections of documents representing edges in ArangoDB are called edge collections. It's worth noting that edge collection documents are also documents, so edges in ArangoDB can also act as nodes.

Algandmed

Let us have a collection persons, the documents of which look like this:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Alice"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Bob"  
  }
]

Let there also be a collection cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "John Donne"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Jean-Jacques"
  }
]

Then the collection likes might look like this:

[
  {
    "_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 and results

A graph-style query in the AQL language used in ArangoDB, returning in human-readable form the information about who likes which cafe, looks like this:

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

In relational style, where we rather 'compute' relationships instead of storing them, this query could be rewritten like this (by the way, it could be done without the collection): 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 }

The result in both cases will be the same:

[ { "person" : "Alice" , likes : "Jean-Jacques" } , { "person" : "Alice" , likes : "John Donne" } , { "person" : "Bob" , likes : "John Donne" } ]

More queries and results

Еще запросы и результаты

Kui tundub, et ülaltoodud väljundiformaat sobib pigem relatsioonilise andmebaasi kui dokumentidepõhise andmebaasi jaoks, siis võib proovida sellist päringut (või kasutada) KOGU):

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

Tulemuseks on järgmine formaat:

[
  { "person" : "Alisa" , likes : ["Jean-Jacques" , "John Donne"]  } ,
  { "person" : "Bob" , likes : ["John Donne"] }
]

OrientDB

Graafi mudeli rakendamine dokumentidepõhise OrientDB kohal põhineb võimaluse dokumentide väljadele, millel on lisaks enam-vähem standardsetele skalaarsetele väärtustele ka selliste tüüpide väärtused, nagu LINK, LINKLIST, LINKSET, LINKMAP ja LINKBAG. Need tüübid — viidatud või viidete kogud süsteemi идентификаторid dokumentide.

Dokumendi määratud süsteemi идентификаторil on "füüsiline tähendus", näidates salvestuse positsiooni andmebaasis, ja see näeb välja ligikaudu nii: @rid : #3:16. Seega on viidatud omaduste väärtused tõeliselt pigem viidud (nagu graafimudel), mitte valiku tingimused (nagu relatsiooniline).

Nagu ArangoDB-s, esindatakse OrientDB-s servi eraldi dokumentidena (kuigi kui serval ei ole oma omadusi, võib selle teha kergekaaluliseks, ja sellele ei vasta eraldi dokument).

Algandmed

Sellises formaadis, mis on ligikaudu dumpi formaat andmed eelmisest näitest ArangoDB jaoks näeksid välja ligikaudu niimoodi:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Alisa",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Bob",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Jean-Jacques",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "John Donne",
      "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"
    }
  ]

Nagu näeme, säilitavad tipud ka teavet sisse- ja väljaminevate servade kohta. Kui kasutamist Dokumendi API lingivõrgustiku terviklikkuse jälgimine peab toimuma käsitsi, kuid Graph API teeb selle töö teie eest. Kuid vaatame, kuidas näevad välja päringud OrientDB-s "puhtates", programmeerimiskeeltesse integreerimata päringute keeltes.

Queries and results

Päring, mis on samalaadne ArangoDB näite päringule, näeb OrientDB-s välja järgmine:

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

Tulemus saadakse järgmise kujul:

[
  { "person_name": "Alice", "cafe_name": "John Donne" },
  { "person_name": "Alice", "cafe_name": "Jean-Jacques" },
  { "person_name": "Bob",  "cafe_name": "Jean-Jacques" }
]

Kui tulemuse formaat tundub taas liiga "suhteline", tuleb eemaldada rida, mis sisaldab UNWIND():

[
  { "person_name": "Alice", "cafe_name": [ "John Donne", "Jean-Jacques" ] },
  { "person_name": "Bob",  "cafe_name": [ "Jean-Jacques" ] }
]

OrientDB päringukeelt saab iseloomustada kui SQL-i Gremlin-taoliste lisanditega. Versioonis 2.2 ilmus Cypher-taoline päringuvorm. MÄRKUS :

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

Tulemuse formaat on sama, mis eelnevas päringus. Mõelge, mida on vaja eemaldada, et muuta see rohkem "suhteliseks", nagu esimeses päringus.

Azure CosmosDB

Vähemalt osas kehtib eelpool öeldu ArangoDB ja OrientDB kohta Azure CosmosDB suhtes. CosmosDB pakub järgmisi API-sid andmetele juurdepääsuks: SQL, MongoDB, Gremlin ja Cassandra.

SQL API ja MongoDB API kasutatakse andmete juurdepääsuks dokumendi mudelis. Gremlin API ja Cassandra API kasutavad andmete juurdepääsuks vastavalt graafika ja veergude mudel. Andmed kõigis mudelites salvestatakse CosmosDB sisemises mudelis: ARS ("atom-record-sequence"), mis on samuti lähedane dokumentide mudelile.

Kuid kasutaja valitud andmemudel ja kasutatav API kinnitatakse konto loomise hetkeks teenuses. Andmetele, mis on laaditud ühes mudelis, ei saa juurde pääseda teises mudelis, lahendust illustreerimiseks võiks välja pakkuda järgmise joonise:

Seega tähendab mitmekesisus Azure CosmosDB-s tänapäeval vaid võimalust kasutada mitut andmebaasi, mis toetavad erinevaid mudeleid, ühe tootja käest, mis ei lahenda kõiki multifunktsionaalse salvestamise probleeme.

Multimodaalsed andmebaasisüsteemid graafikamudelist?

Tuleb märkida, et turul pole veel mitme mudeli andmebaase, mille aluseks oleks graafikamudel (kui mitte lugeda mitme mudelina kahe graafikamudeli samal ajal toetamise võimalust: RDF ja LPG; vaata selle kohta. eelmine postitus). Suurimad raskused tekivad dokumendi graafimudeli, mitte relatsioonilise rakendamisel.

Küsimus, kuidas rakendada relatsioonilisi elemente graafimudeli peale, käsitleti juba nõukogude ajal selle viimase kujunemise päevadel. Kuidas ja meie tehniline direktor)., näiteks, David McGovern:

Graafipõhise lähenemisega ei ole seotud midagi, mis takistaks luua kihti (nt sobiva indekseerimise kaudu) graafandmebaasis, mis võimaldab relatsioonilist vaadet, kus (1) taastatakse tupelid tavapärastest võtme-väärtuspaaridest ja (2) grupeeritakse tupelid seose tüübi järgi.

Kuid graafimudeli alusel dokumendimudelit rakendades tuleb meeles pidada näiteks järgmist:

• JSON-massiivi elemendid loetakse järjestatud, graafi serva tipust tulevad - mitte;
• Dokumendimudelis on andmed tavaliselt denormaliseeritud, mitme koopia hoidmine samast sisemiselt dokumendist ei ole soovitav, samas puuduvad alldokumendidel tavaliselt identifikaatorid;
• Teisest küljest on dokumendibaaside ideoloogia see, et dokumendid on valmid "agregaadid", mida ei pea iga kord uuesti koostama. Graafimudelis peab olema võimalik kiiresti saada alagraaf, mis vastab valmisl dokumendile.

Veidi reklaami

Artikli autor on seotud andmebaasi NitrosBase arendamisega, mille sisemine mudel on graafipõhine ja välised mudelid - relatsiooniline ja dokumendipõhine - on selle esitlused. Kõik mudelid on võrdväärsed: praktiliselt kõik andmed on saadaval igas neist, kasutades loomulikku päringukeelt. Veelgi enam, igas esituses saab andmeid muuta. Muudatused kajastuvad sisemises mudelis ja vastavalt ka teistes esitustes.

Kuidas mudelid NitrosBase'is vastavad - loodan kirjeldada ühes järgnevates artiklites.

Kokkuvõte

Loodan, et üldised kontuurid selle kohta, mida nimetatakse mitmemudelilisuseks, on lugejale enam-vähem selged. Mitmemudelist rääkivad andmebaasid on üsna erinevad ja "mitme mudeli toetamine" võib välja näha erinevalt. Selle mõistmiseks, mida mõistetakse "mitmemudelilisuse" all iga konkreetse juhtumi puhul, on kasulik vastata järgmistele küsimustele:

1. Kas on jutt traditsiooniliste mudelite toetamisest või mingist ühest "hübriidmudelist"?
2. Kas mudelid on "võrdväärsed", või on üks neist alluv teistele?
3. Kas on mudelite vahel ükskõik? Kas ühe mudeli andmeid saab lugeda teises või isegi üle kirjutada?

Mõtleksin, et küsimusele multimeetodiliste andmebaasisüsteemide aktuaalsuse kohta saab juba positiivselt vastata, kuid huvitav on küsimus, millised nende variandid saavad lähitulevikus rohkem nõudlust. Tundub, et rohkem küsitakse multimeetodiliste andmebaasisüsteemide järele, mis toetavad traditsioonilisi mudeleid, eelkõige relatsioonilisi; multimeetodiliste andmebaasisüsteemide populaarsus, mis pakuvad uusi mudeleid, kombineerides erinevate traditsiooniliste eeliseid, on kaugema tuleviku küsimus.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kasutate multimeetodilisi andmebaasisüsteeme?

• Ei kasuta, kõik andmed hoitakse ühes andmebaasis ja ühes mudelis

• Kasutame traditsiooniliste andmebaasisüsteemide multimeetodilisi võimalusi

• Praktiliselt rakendame polügloti püsivust (polyglot persistence)

• Kasutame uusi multimeetodilisi andmebaasisüsteeme (Arango, Orient, CosmosDB)

Hääletas 19 kasutajat. 4 kasutajat olid erapooletud.

Allikas: habr.com