Kaasaegsed infotehnoloogia süsteemid on piisavalt keerulised. Nende keerukuse põhjuseks on osaliselt ka andmete keerukus, mida neist süsteemidest töödeldakse. Andmete keerukus peitub sageli andmemudelite mitmekesisuses. Näiteks, kui andmed muutuvad "suurteks", ei ole nende maht ("volume") ainus ebamugavustunne, vaid ka nende mitmekesisus ("variety").

Kui te ei leia veel antud arutlustes puudusi, siis lugege edasi.

Sisu

Polyglot persistents
Multimodaalsus
Multimudelilised andmebaasisüsteemid, mis põhinevad relatsioonimudelil
     Dokumendimudel MS SQL Serveris
     Graafimudel MS SQL Serveris
Multimudelilised andmebaasisüsteemid, mis põhinevad dokumendimudelil
     Relatsioonimudel MarkLogicis
     Graafimudel MarkLogicis
Multimudelilised andmebaasisüsteemid "ilma põhiraamideta"
     ArangoDB
     OrientDB
     Azure CosmosDB
Multimudelilised andmebaasisüsteemid, mis põhinevad graafimudelil?
Kokkuvõte
Küsitlus

Polyglot persistents

Ülaltoodud viitab sellele, et teinekord tuleb isegi ühes süsteemis andmete salvestamiseks ja nende töötlemiseks kasutada mitmeid erinevaid andmebaasisüsteeme, millest igaühel on oma andmemudel. M. Fowleri kergelt öeldes, autori paljude tuntud raamatute ja ühe kaasautori Agile Manifesto, sellist olukorda nimetatakse mitme variandi säilitamiseks («polyglot persistence»).

Fowler tõi välja järgmise näite andmete hoidmise korraldamisest täisfunktsionaalses ja kõrge koormusega rakenduses e-kaubanduse valdkonnas.

See näide on muidugi veidi liialdatud, kuid mõningaid kaalutlusi, miks valida sobiv andmebaas vastava eesmärgi jaoks, võib leida näiteks, siit.

Selge on, et sellises loomaaias teenimine ei ole kerge.

• Andmete säilitamiseks vajalik koodihulk kasvab proportsionaalselt kasutatavate andmebaaside arvuga; andmete sünkroonimiseks vajalik kood — oleks hea, kui see ei kasva ruudus selle arvu järgi.
• Kasutatavate andmebaaside arvu tõttu suurenevad kulud enterprise-omaduste tagamiseks (skaalautuvus, katkestustele vastupidavus, kõrge kättesaadavus) iga kasutatava andmebaasi puhul.
• Enterprise-omaduste tagamine kogu salvestussüsteemi ulatuses — eriti tehinguliste omaduste puhul — on võimatu.

Zooloodi direktori silmis paistab kõik välja järgmine:

• Tarkvara litsentside ja tugiteenuste hinnatõus tootjalt.
• Töötajate arvu suurenemine ja tähtaegade pikenemine.
• Otsesed rahalised kaotused või trahvid andmete ebakõlade tõttu.

Kokkuvõtlikuks süsteemi omamiskulude (TCO) märkimisväärne kasv. Kas olukorrast "mitme variandi hoidmine" on mingit väljapääsu?

Multimodaalsus

Mõisted "mitme variandi hoidmine" on saanud tuntuks 2011. aastal. Probleemide teadlikkus ja lahenduste leidmine võttis aastaid, ning 2015. aastaks sõnastasid analüütikud Gartner, et

• Väljavõte "Market Guide for NoSQL DBMSs — 2015»:
  

  Andmebaasi tulevik, nende arhitektuur ja kasutusviisid — multimudeelsus.

• Väljavõte "Magic Quadrant for ODBMS — 2016»:
  

  Juhtivad operatiivsed andmebaasid pakuvad mitmeid mudeleid — nii relationaalset kui ka mitte-relationaalset — ühel platvormil.

Tundub, et seekord analüütikud Gartner ei eksinud. Kui minna lehele peamiseks reitinguks andmebaaside DB-Engines, võib näha, etoenamus selle liidreid positsioneerivad end just kui multimudeelsed andmebaasid. Sama on nähtav ka igal eraldi reitingu lehel.

Alljärgnevas tabelis on toodud andmebaasid, mis on liidrid igas eraldi klassifikatsioonis ja väidavad oma multimudelit. Iga andmebaasi puhul on märgitud algne toetatud mudel (mis kunagi oli ainus) ja koos sellega ka mudelid, mida toetatakse praegu. Samuti on esitatud andmebaasid, mis positsioneerivad end kui "algusest peale multimudelilised", millel ei ole arendajate väidete kohaselt mingit algset pärandmudelit.

Märgid tabelis

Tabelis on tärniga märgitud väited, mis vajavad täpsustamist:

• Andmebaas PostgreSQL ei toeta graafimudeleid, kuid sellel toetab seda toode alusel, nagu näiteks AgensGraph.
• MongoDB puhul on korrektsem rääkida pigem graafilistest operaatoritest päringukeeles ($lookup, $graphLookup), kui räägitakse graafimudeli toest, kuigi selle kasutuselevõtt nõudis füüsilise salvestuse optimeerimist graafimudeli toetamise suunas.
• Redis'i kontekstis räägitakse laiendusest RedisGraph.

Edasi näitame igas klassis, kuidas erinevate mudelite toetamine andmebaasides sellest klassist on teostatav. Olulisemateks peame suhete, dokumentide ja graafimudeleid ning näitame konkreetsete andmebaaside näidete põhjal, kuidas teostatakse 'puuduolevaid'.

Multimudelilised andmebaasisüsteemid, mis põhinevad relatsioonimudelil

Praegu on juhtivad andmebaasid suhete andmebaasid, Gartneri ennustus ei oleks täidetud, kui relatsioonilised andmebaasid ei näitaks liikumist mitmemudelisuse suunas. Ja nad tõepoolest näitavad. Nüüd võib arvesse võtta sõnavõtte selle kohta, et mitmemudeliline andmebaas on nagu Šveitsi armee nuga, millega ei saa mitte midagi hästi teha, suunata otse Larry Ellisonile.

Kuid autorile meeldib rohkem mitmemudelisuse rakendamine Microsoft SQL Serveris, mille näitel kirjeldame dokumentide ja graafimudelite toetust relatsioonilistes andmebaasides.

Dokumendimudel MS SQL Serveris

Kuidas MS SQL Server toetab dokumentide mudelit, on Habr siiski kaks suurepärast artiklit, piirduksin lühikese kokkuvõtte ja kommentaariga:

• Töötame JSON-iga SQL Server 2016-s
• SQL Server 2017 JSON

Dokumentide mudeli toetus MS SQL Serveris on piisavalt tüüpiline relaatsiooniandmebaaside jaoks: JSON-dokumente pakutakse tavalistes tekstiväljade kaudu salvestamiseks. Dokumentide mudeli toetus seisneb spetsiaalsete operaatorite pakkumises nende JSON-i analüüsimiseks:

• JSON_VALUE skaalaarsete atribuute väärtuste väljatõmbamiseks,
• JSON_QUERY alusdokumentide väljatõmbamiseks.

Mõlema operaatoriga on teiseks argumendiks väljend JSONPath-taolises süntaksis.

Üldiselt võib öelda, et sellisel viisil salvestatud dokumendid ei ole relaatsiooniandmebaasis "esmaklassilised üksused", erinevalt k Tup väärtustest. Konkreetsetes MS SQL Serveri versioonides puuduvad hetkel JSON-dokumentide väljade indeksid, mis raskendab tabelite ühendamise operatsioonide tegemist nende väljade väärtuste põhjal ja isegi dokumentide valimist nende väärtuste järgi. Siiski on võimalik luua selle välja põhjal arvutatud veerg ja indeks.

MS SQL Server pakub võimalust mugavalt koostada JSON-dokumenti tabeli sisust operatöriga FOR JSON PATH — võimalus, mis on teatud mõttes vastand eelmisele, tavapärasele säilitamisele. Selge, et ükskõik kui kiire ka poleks RDBMS, on selline lähenemine vastupidine dokumentide DB ideoloogiale, mis põhimõtteliselt salvestab valmis vastused populaarsetele päringutele, ja võib lahendada vaid arendamise mugavuse, mitte kiirusprobleeme.

Lõpuks võimaldab MS SQL Server lahendada ülesande, mis on vastupidine dokumendi koostamisele: JSON-i saab tabelitesse jagada operatöriga OPENJSON. Kui dokument pole täiesti tasane, tuleb kasutada RISTSÜND APPLY.

Graafimudel MS SQL Serveris

Graafilise (LPG) mudeli tugi on Microsoft SQL Serveris samuti täiesti ennustatav: soovitatakse kasutada spetsiaalseid tabeleid sõlmede ja kaare hoidmiseks. Sellised tabelid luuakse väljendite abil CREATE TABLE AS NODE ja CREATE TABLE AS EDGE vastavalt.

Esimese tüübi tabelid on sarnased tavapärastele tabelitele, mis salvestavad kirjeid, ainsa välise erinevusega, et tabelis on süsteemne väli $node_id — unikaalne graafi sõlme identifikaator andmebaasis.

Sarnaselt, teise tüübi tabelitel on süsteemi väljad $from_id ja $to_id, sellistes tabelites määratlevad kirjed selgelt seosed sõlmede vahel. Iga tüübi seoste salvestamiseks kasutatakse eraldi tabelit.

Illustreerime seda näitega. Oletame, et graafilised andmed on skeemiga nagu eespool toodud joonisel. Vastava struktuuri loomine andmebaasis nõuab järgmiste DDL-käskude täitmist:

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 graafilisi mustreid Cypher-tüüpi süntaksiga (kuigi "*" jms hetkel ei toetata). Tootlikkuse mõõtmiste põhjal võib ka eeldada, et nende tabelite andmete salvestamise viis erineb tavapäraste tabelite andmete salvestamise mehhanismist ning on optimeeritud selliste graafiliste päringute täitmiseks.

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

Lisaks on üsna keeruline selliste tabelitega töötades neid graafipattern'e mitte kasutada, kuna traditsioonilistes SQL-päringutes sarnaste ülesannete lahendamiseks tuleb teha täiendavaid samme süsteemsete "graafiliste" sõlmede identifikaatorite saamiseks ($node_id, $from_id, $to_id; sama põhjusel ei ole siin andmete sisestamise päringud välja toodud, kuna need oleksid liiga mahukad).

Kokkuvõttes MS SQL Serveri dokumendi- ja graafimudelite rakenduste kirjeldamisel tahaksin märkida, et sarnaste mudelite realiseerimine üksteise peal ei tundu esimese jao keelelise disaini seisukohast eriti õnnestunud. Ühe keele laiendamine teisega on vajalik, keeled ei ole täielikult "ortogonaalsed", ja ühilduvuse reeglid võivad olla üsna veidrad.

Multimudelilised andmebaasisüsteemid, mis põhinevad dokumendimudelil

Selles osas soovin illustreerida multimudelisust dokumendivaatide SÜB-de näitel, kasutades selleks mitte kõige populaarsemat neist, MongoDB-d (nagu mainitud, on seal ainult tinglikult graafilised operaatorid $lookup ja $graphLookup, mis ei toimi jagatud kogumites), vaid näitheks küpsem SÜB. MarkLogic.

Olgu, oletame, et kogu kollektsioon sisaldab järgmise vormingu XML-dokumente (MarkLogic toetab ka JSON-dokumentide salvestamist):

John
  Smith

Relatsioonimudel MarkLogicis

Dokumentide kollektsiooni suhtelise esitluse saab luua kuvašabloni (elementide sisu value alltoodud näites võib olla soovitud XPath):

/Person
  
    
      Person
      
        
          SSN
          @SSN
          string
        
        
          name
          name
        
        
          surname
          surname

Loodud esitlusele saab suunata SQL-päringu (näiteks ODBC kaudu):

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

Kahjuks on kuvašabloni abil loodud suhteline esitus ainult lugemiseks. Päringu töötlemisel püüab MarkLogic kasutada dokumentide indekseid. Varasemalt olid MarkLogicis ka piiratud suhtelised esitused, mis põhinesid täielikult indeksite peal ja on kirjalik, kuid praegu on need arvatud vananenuks.

Graafimudel MarkLogicis

Grafitehnoloogia (RDF) mudel toetab sama põhimõtteid. Jälle on selle saavutamiseks võimalik kuvašabloni luua RDF-esitlus ülaltoodud dokumentide kogumist:

/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 relatsioonilisest mudelist toetab MarkLogic graafimudelit veel kahel muul viisil:

1. Andmebaas võib olla täielik iseseisev RDF-andmete ladustamine (tripleid nimetatakse seal managed vastandina ülaltoodule extracted).
2. RDF er spetsialiseeritud serialiseerimises võib lihtsalt olla kantud XML- või JSON-dokumentidesse (ja tripletid nimetatakse siis haldamata). Tõenäoliselt on see alternatiiv mehhanismidele idref ja sarnased.

Hea ülevaade sellest, kuidas MarkLogic tegelikult töötab, annab Optic API, selle mõttes on see madala taseme, kuigi selle eesmärk on pigem vastupidine — püüda abstraheerida kasutatavast andmemudelist, tagada andmete järjepidev töö erinevates mudelites, tehingulisus jne.

Multimudelilised andmebaasisüsteemid "ilma põhiraamideta"

Turul on ka andmebaase, mis positsioneerivad end kui algselt multiamoodulised, ilma igasuguse pärandatud põhistruktuurita. Nende hulka kuuluvad ArangoDB, OrientDB (alates 2018. aastast kuulub arendav ettevõte SAP-le) ja CosmosDB (teenus Microsoft Azure'i pilveplatvormi koostisosana).

Tegelikult on ArangoDB ja OrientDB-l „põhilised” mudelid. Mõlemal juhul on need omapärased andmemudelid, mis on dokumentide üldistused. Üldistused seisnevad peamiselt selles, et kergendada graafi- ja suhteliselt tõhusaid päringute tegemise võimalusi.

Need valikud on nimetatud andmebaasides ainsad, mida saab kasutada, ning nende jaoks on mõeldud spetsiaalsed päringukeeled. Absoluutselt, sellised mudelid ja andmebaasid on perspektiivikad, kuid standardmudelite ja keeltes puuduv ühilduvus muudab nende andmebaaside integreerimise pärandtehnoloogiatega võimatuks.

Habr's on juba olnud suurepärane artikkel ArangoDB ja OrientDB kohta: JOIN NoSQL andmebaasides.

ArangoDB

ArangoDB kinnitab graafimudeli toe.

ArangoDB graafi sõlmed on tavalised dokumendid, ja servad on spetsiaalse liigi dokumendid, mis omavad tavapäraste süsteemsete väljadega (_key, _id, _rev) süsteemseid välju _from ja _to. Dokumente dokumentide andmebaasides tavaliselt grupeeritakse kogudesse. Graafide esindavad dokumentide kogud, mida ArangoDB-s nimetatakse servade kogudeks. Muide, servade kogude dokumendid on samuti dokumendid, nii et servad ArangoDB-s võivad toimida ka sõlmedena.

Algandmed

Olgu meil kogum persons, mille dokumendid näevad välja järgmisugused:

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

Olgu ka kogum cafes:

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

Siis kogu kollektsioon meeldimised võib välja näha järgmine:

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

Päringud ja tulemused

Graalistiilis päring ArangoDB AQL keeles, mis tagastab arusaadaval kujul andmed selle kohta, kellele milline kohvik meeldib, näeb välja nii:

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

Suhete arvutamisel rikka stilistika puhul, mitte nende salvestamisel, võiks selle päringu kirjutada nii (muide, ilma kollektsioonita meeldimised võiks ka hakkama saada):

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 }

Mõlemas olukorras on tulemus sama:

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

Veel päringud ja tulemused

Kui tundub, et ülaltoodud tulemusformaat on pigem iseloomulik alumisele relatsioonilisele DB asemel dokumendi andmebaasile, siis võib proovida sellist päringut (või kasutada COLLECT):

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

Tulemus näeb välja järgmine:

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

OrientDB

Dokumendimudeli peal graafikumudeli rakendamine OrientDB-s põhineb võimalus dokumendi väljad, mis sisaldavad peale enam-vähem standardsete skaalarväärtuste ka selliste tüüpide väärtusi, nagu LINK, LINKLIST, LINKSET, LINKMAP ja LINKBAG. Nende tüüpide väärtused on viidud või viidud kollektsioonidele süsteemi identifikaatoritele dokumentide.

Süsteemi määratud dokumendi identifikaator omab „füüsilist tähendust“, näidates kirje positsiooni andmebaasis ja näeb välja umbes nii: @rid : #3:16. Seega on viidatud omaduste väärtused tõepoolest pigem näidikud (nagu graafikumudelis), mitte valikutingimused (nagu relatsioonilistes).

Nagu ArangoDB-s, esindatakse OrientDB-s servad eraldi dokumentidega (kuigi kui serval ei ole omadusi, saab selle teha kergekaaluliseks, ja sellele ei ole eraldi dokumenti vastavuses).

Algandmed

Formaat, mis on lähedane dumpi formaadile OrientDB-st, eelneva näite andmed ArangoDB-s näeksid välja umbes nii:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Alice",
      "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, salvestavad tipud samuti teavet sisenemise ja väljamineva servade kohta. Kasutamisel kolmandate osapoolte Dokumendi API lingvistiline terviklikkus peab jälgima ise, kuid Graph API teeb selle töö sinu eest. Vaadakem, kuidas näeb välja päring OrientDB-s "puhtalt", programmeerimiskeeltesse integreerimata päringute keeltes.

Päringud ja tulemused

Päring, mis on mõeldud sama eesmärgi saavutamiseks nagu ArangoDB näites, 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ärgmises vormis:

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

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

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

OrientDB päringukeelt võib iseloomustada kui SQL Gremlin-sarnaste lisanditega. Versioonis 2.2 ilmus Cypher-sarnane päringu vorm, 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

Tulemuse formaat on sama, mis eelmises päringus. Mõelge, mida tuleks eemaldada, et muuta see rohkem "relatsiooniliseks", nagu kõige esimeses päringus.

Azure CosmosDB

Vähemal määral kehtib eelnevalt öeldu ArangoDB ja OrientDB kohta ka Azure CosmosDB-le. CosmosDB pakub järgmisi andmete ligipääsu API-sid: SQL, MongoDB, Gremlin ja Cassandra.

SQL API ja MongoDB API kasutatakse andmete ligipääsuks dokumendimudelile. Gremlin API ja Cassandra API - vastavalt graafi- ja veergmudelile. Kõikide mudelite andmed salvestatakse CosmosDB sisemise mudeli formaadis: ARS („atom-record-sequence“), mis on samuti lähedane dokumendile.

Kuid kasutaja valitud andmemudel ja kasutatav API fikseeritakse konto loomisel teenuses. Ühe mudeli formati andmetele ei ole võimalik ligipääsu saada teise mudeli formaadis, mida illustreeriks ligikaudu järgmine joonis:

Seega esindab Azure CosmosDB tänapäeval multimudelisus lihtsalt võimalust kasutada mitut andmebaasi, mis toetavad erinevaid mudeleid ühelt tootjalt, mis ei lahenda kõiki variatiivse salvestamise probleeme.

Multimudelilised andmebaasisüsteemid, mis põhinevad graafimudelil?

Rõhutab, et turul pole veel mitmemudelseid andmebaase, mille aluseks oleks graafimudel (v.a. mitmemudelsuse alla kuulub kahe graafimudelilise toe, RDF ja LPG, olemasolu; vt selle kohta eelnevas postituses). Suurimad raskused tekivad dokumentaarse, mitte relatsioonilise mudeli rakendamisel graafimudeli kohal.

Küsimust, kuidas rakendada relatsioonilist mudelit graafimudeli kohal, arutati juba relatsioonilise mudeli algusaegadel. Nagu ütles, näiteks David McGovern:

Graafi lähenemisviisis ei ole midagi sellist, mis takistaks graafandmebaasi põhjal kihi loomist (nt sobiva indekseerimise abil), mis võimaldaks relatsioonilist vaadet koos (1) tavapäraste võtmeväärtuste paari põhjal tupplike taastamisega ja (2) tupplike rühmitamisega suhte tüübi järgi.

Dokumentaarse mudeli rakendamisel graafimudeli kohal tuleb arvestada näiteks järgmist:

• JSON-massiivi elemendid loetakse järjestatud, graafi serva tipust lähtuvad — ei;
• Dokumentaarses mudelis on andmed tavaliselt denormeeritud, ei soovi ikkagi hoida mitmeid koopiaid samast siserese dokumentist, ja aladokumentide identifikaatorid puuduvad tavaliselt.
• Teiselt poolt, dokumentide andmebaaside ideoloogia seisneb selles, et dokumendid on valmis "kogumid", mida ei pea iga kord uuesti üles ehitama. On vajalik tagada graafimudelis võimalus kiiresti saada alagraaf, mis vastab valminud dokumendile.

Natuke reklaami

Artikli autor on seotud andmebaasi NitrosBase arendamisega, mille sisemine mudel on graafiline ja välismudelid — relatsiooniline ja dokumentaalne — on selle representatsioonid. Kõik mudelid on võrdsed: praktiliselt kõik andmed on saadaval igas neist, kasutades loomulikku selle keele päringu jaoks. Veelgi enam, igas representatsioonis saab andmeid muuta. Muudatused kajastuvad sisemodelis ja vastavalt ka teistes representatsioonides.

Kuidas mudelite vastavus NitrosBase'is välja näeb — kirjeldan, loodan, ühes järgmistest artiklitest.

Kokkuvõte

Loodetavasti on nüüd saanud lugejale selgeks, mida mõistetakse muldimudeli all. Multimudeliteks nimetatakse erinevaid andmebaasisüsteeme ning "mitme mudeli toetamine" võib välja näha erinevalt. Selle mõistmiseks, mida mõistetakse "multimudeli" all konkreetses kontekstis, on kasulik vastata järgmistele küsimustele:

1. Kas räägitakse traditsiooniliste mudelite toetamises või on tegu mingi "hübriidse" mudeliga?
2. Kas mudelid on "võrdsetes tingimustes" või on üks neist teistest üle?
3. Kas mudelid on üksteise suhtes "ükskikud"? Kas ühe mudeli alla kirjutatud andmed saavad olla loetavad teises või isegi ümberkirjutatud?

Ma arvan, et nüüdsaegsete mitmemudelite andmebaaside (SУБД) asjakohasuse küsimusele saab juba positiivselt vastata, kuid huvitav on see, milliseid nende sorte nõutakse lähitulevikus. Tundub, et nõudlus suureneb traditsiooniliste mudelite, eelkõige relatsiooniliste, toetavate mitmemudelite andmebaaside järele; mitmemudelite andmebaaside populaarsus, mis pakuvad uusi mudeleid, kombineerides erinevate traditsiooniliste omadusi, on asi, mis kuulub rohkem kaugemasse tulevikku.

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

Kas kasutate mitmemudelite andmebaase?

• Ei kasuta, hoiame kõike ühes andmebaasis ja ühes mudelis

• Kasutame traditsiooniliste andmebaaside mitmemudelite võimalusi

• Harjutame mitmehargalist salvestamist (polyglot persistence)

• Kasutame uusi mitmemudelite andmebaase (Arango, Orient, CosmosDB)

Hääletas 19 kasutajat. 4 kasutajat jäi erapooletuks.

Allikas: habr.com