Nútíma upplýsingakerfi eru frekar flókin. Flækjustig þeirra stafar ekki síst af því hversu flókin gögn eru unnin í þeim. Flækjustig gagna liggur oft í fjölbreytileika gagnalíkana sem notuð eru. Svo, til dæmis, þegar gögn verða „stór“, er eitt af erfiðu einkennunum ekki aðeins rúmmál þess ("rúmmál"), heldur einnig fjölbreytni þess ("fjölbreytni").

Ef þú finnur ekki enn galla í röksemdafærslunni, lestu þá áfram.

efni

Fjölhyggja þrautseigja
Fjölmódel
Multi-módel DBMS byggt á vensla líkaninu
     Skjalalíkan í MS SQL Server
     Graflíkan í MS SQL Server
Multi-módel DBMS byggt á skjalalíkaninu
     Venslalíkan í MarkLogic
     Graflíkan í MarkLogic
Marggerða DBMS „án aðallíköns“
     ArangoDB
     OrientDB
     Azure CosmosDB
Multi-módel DBMS byggt á línuritslíkani?
Ályktun
Опрос

Fjölhyggja þrautseigja

Ofangreint leiðir til þess að stundum er jafnvel innan ramma eins kerfis nauðsynlegt að nota nokkrar mismunandi DBMS til að geyma gögn og leysa ýmis vandamál við vinnslu þeirra, sem hver um sig styður sitt gagnalíkan. Með léttri hendi M. Fowler, höfundurinn fjölda frægra bóka og ein af meðhöfunda Agile Manifesto, þetta ástand er kallað geymsla með mörgum afbrigðum ("fjölhyggja þrautseigja").

Fowler hefur einnig eftirfarandi dæmi um að skipuleggja gagnageymslu í fullkomnu og mikið hlaða forriti á sviði rafrænna viðskipta.

Þetta dæmi er að sjálfsögðu nokkuð ýkt, en nokkur atriði sem lúta að því að velja einn eða annan DBMS í samsvarandi tilgangi má finna, t.d. hér.

Það er ljóst að það er ekki auðvelt að vera þjónn í slíkum dýragarði.

Magn kóða sem framkvæmir gagnageymslu vex í hlutfalli við fjölda DBMS sem notuð eru; magn kóða sem samstillir gögn er gott ef ekki í réttu hlutfalli við veldi þessarar tölu.
Sem margfeldi af fjölda DBMS sem notaðar eru eykst kostnaður við að útvega fyrirtækiseiginleika (sveigjanleika, bilunarþol, mikið aðgengi) hvers DBMS sem notað er.
Það er ómögulegt að tryggja fyrirtækiseiginleika geymsluundirkerfisins í heild - sérstaklega viðskipti.

Frá sjónarhóli dýragarðsstjóra lítur allt svona út:

Margföld hækkun á kostnaði við leyfi og tæknilega aðstoð frá DBMS framleiðanda.
Ofmönnun og auknir frestir.
Beint fjárhagslegt tap eða viðurlög vegna ósamræmis gagna.

Veruleg aukning er á heildarkostnaði kerfisins við eignarhald (TCO). Er einhver leið út úr stöðu „margra geymsluvalkosta“?

Fjölmódel

Hugtakið „fjölþætt geymsla“ kom í notkun árið 2011. Meðvitund um vandamál nálgunarinnar og leit að lausn tók nokkur ár, og árið 2015, með munni Gartner greinenda, var svarið mótað:

Frá "Markaðsleiðbeiningar fyrir NoSQL DBMS - 2015'

Framtíð DBMS, arkitektúr þeirra og leiðir til að nota þá er marglíkön.
Frá "Magic Quadrant fyrir ODBMS - 2016'

Leiðandi rekstrarlegar DBMSs munu bjóða upp á margar gerðir - venslabundin og ekki - sem hluti af einum vettvangi.

Svo virðist sem greiningaraðilar Gartner hafi haft rétt fyrir sér með spá sína að þessu sinni. Ef þú ferð á síðuna með aðaleinkunn DBMS á DB-Engines, þú getur séð þaðоFlestir leiðtogar þess staðsetja sig sérstaklega sem multi-módel DBMS. Það sama má sjá á síðunni með hvaða einkaeinkunn sem er.

Taflan hér að neðan sýnir DBMS - leiðtogana í hverri einkaeinkunn, sem segjast vera multi-módel. Fyrir hverja DBMS er upprunalega studda líkanið (sem einu sinni var það eina) og ásamt því líkön sem nú eru studd tilgreind. Einnig eru taldar upp DBMS sem staðsetja sig sem „upphaflega multi-módel“ og, að sögn höfunda, hafa enga upphaflega erfða líkan.

DBMS	Upphafleg fyrirmynd	Fleiri gerðir
Oracle	Vensla	Línurit, skjal
MS SQL	Vensla	Línurit, skjal
PostgreSQL	Vensla	Graf*, skjal
MarkLogic	Heimildarmynd	Graf, vensla
MongoDB	Heimildarmynd	Lykilgildi, línurit*
DataStax	Breiður dálkur	Heimildarmynd, graf
Redis	Lykill-gildi	Heimildarmynd, graf*
ArangoDB	-	Línurit, skjal
OrientDB	-	Graf, skjal, vensla
Azure CosmosDB	-	Graf, skjal, vensla

Skýringar á borði

Stjörnumerki í töflunni merkja yfirlýsingar sem krefjast fyrirvara:

PostgreSQL DBMS styður ekki línuritsgagnalíkanið, en þessi vara styður það byggt á því, eins og AgensGraph.
Í sambandi við MongoDB er réttara að tala um tilvist línurita á fyrirspurnarmálinu ($lookup, $graphLookup) heldur en um að styðja línuritslíkanið, þó auðvitað hafi innleiðing þeirra krafist nokkurrar hagræðingar á líkamlegu geymslustigi í þá átt að styðja við línuritslíkanið.
Í sambandi við Redis er átt við framlenginguna RedisGraph.

Næst, fyrir hvern flokk, munum við sýna hvernig stuðningur fyrir nokkrar gerðir er útfærður í DBMS frá þessum flokki. Við munum líta á tengsla-, skjala- og graflíkönin sem mikilvægustu og nota dæmi um sérstakar DBMS til að sýna hvernig „þau sem vantar“ eru útfærð.

Multi-módel DBMS byggt á vensla líkaninu

Leiðandi DBMS eru nú tengsl; Spá Gartner gæti ekki talist sönn ef RDBMSs sýndu ekki hreyfingu í átt að fjöllíkanagerð. Og þeir sýna. Nú er hægt að beina hugmyndinni um að fjölmódel DBMS sé eins og svissneskur hníf, sem getur ekki gert neitt vel, beint til Larry Ellison.

Höfundur kýs hins vegar frekar útfærslu á fjöllíkönum í Microsoft SQL Server, þar sem RDBMS stuðningi við skjala- og línuritslíkön verður lýst.

Skjalalíkan í MS SQL Server

Það hafa þegar verið tvær frábærar greinar um Habré um hvernig MS SQL Server útfærir stuðning við skjalalíkanið; Ég mun takmarka mig við stutta endursögn og athugasemd:

Leiðin til að styðja við skjalalíkanið í MS SQL Server er nokkuð dæmigerð fyrir vensla DBMS: Lagt er til að JSON skjöl séu geymd í venjulegum textareitum. Stuðningur við skjalalíkanið er að veita sérstökum rekstraraðilum til að þátta þetta JSON:

JSON_VALUE til að draga út stærðareiginleikagildi,
JSON_QUERY að draga út undirskjöl.

Önnur röksemdafærsla beggja rekstraraðila er tjáning í JSONPath-líkri setningafræði.

Í stuttu máli getum við sagt að skjöl sem geymd eru á þennan hátt séu ekki „fyrsta flokks einingar“ í DBMS tengsla, ólíkt tuples. Nánar tiltekið, í MS SQL Server eru engar vísitölur sem stendur á sviðum JSON skjala, sem gerir það erfitt að sameina töflur með því að nota gildi þessara reita og jafnvel velja skjöl sem nota þessi gildi. Hins vegar er hægt að búa til reiknaðan dálk fyrir slíkan reit og vísitölu á hann.

Að auki veitir MS SQL Server möguleika á að smíða JSON skjal á þægilegan hátt úr innihaldi taflna með því að nota stjórnandann FOR JSON PATH - möguleiki, í vissum skilningi, andstæður fyrri, hefðbundin geymslu. Það er ljóst að sama hversu hratt RDBMS er, þá stangast þessi nálgun á hugmyndafræði DBMS skjala, sem geyma í raun tilbúin svör við vinsælum fyrirspurnum og geta aðeins leyst vandamál sem auðvelda þróun, en ekki hraða.

Að lokum, MS SQL Server gerir þér kleift að leysa hið gagnstæða vandamál við gerð skjala: þú getur sundrað JSON í töflur með því að nota OPENJSON. Ef skjalið er ekki alveg flatt þarftu að nota CROSS APPLY.

Graflíkan í MS SQL Server

Stuðningur við línurit (LPG) líkanið er einnig að fullu útfært í Microsoft SQL Server fyrirsjáanlegt: Lagt er til að nota sérstakar töflur til að geyma hnúta og til að geyma línuritsbrúnir. Slíkar töflur eru búnar til með tjáningu CREATE TABLE AS NODE и CREATE TABLE AS EDGE sig.

Töflur af fyrstu gerð eru svipaðar venjulegum töflum til að geyma færslur, með eini ytri munurinn er sá að taflan inniheldur kerfisreit $node_id — einstakt auðkenni grafhnúts í gagnagrunninum.

Á sama hátt eru töflur af annarri gerðinni með kerfisreitum $from_id и $to_id, færslur í slíkum töflum skilgreina greinilega tengingar milli hnúta. Sérstök tafla er notuð til að geyma tengsl af hverri gerð.

Við skulum útskýra þetta með dæmi. Láttu línuritsgögnin hafa skipulag eins og það sem sýnt er á myndinni. Síðan til að búa til samsvarandi uppbyggingu í gagnagrunninum þarftu að keyra eftirfarandi DDL fyrirspurnir:

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

Helsta sérstaða slíkra taflna er að í fyrirspurnum gegn þeim er hægt að nota grafmynstur með Cypher-líka setningafræði (þó „*"o.s.frv. eru ekki enn studdir). Byggt á frammistöðumælingum má líka gera ráð fyrir að hvernig gögn eru geymd í þessum töflum sé frábrugðin því hvernig gögn eru geymd í venjulegum töflum og eru fínstillt til að framkvæma slíkar línuritafyrirspurnir.

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

Þar að auki er frekar erfitt að nota ekki þessi grafmynstur þegar unnið er með slíkar töflur, þar sem í venjulegum SQL fyrirspurnum til að leysa svipuð vandamál verður nauðsynlegt að gera frekari tilraunir til að fá kerfis „graf“ hnútauðkenni ($node_id, $from_id, $to_id; Af sömu ástæðu eru fyrirspurnir um innsetningu gagna ekki sýndar hér þar sem þær eru óþarflega fyrirferðarmiklar).

Til að draga saman lýsinguna á útfærslum skjala- og graflíkana í MS SQL Server, þá tek ég fram að slíkar útfærslur á einu líkani ofan á annað virðast ekki heppnast, fyrst og fremst frá sjónarhóli málhönnunar. Það er nauðsynlegt að lengja eitt tungumál með öðru, tungumálin eru ekki alveg „rétthyrnd“, eindrægnireglurnar geta verið ansi furðulegar.

Multi-módel DBMS byggt á skjalalíkaninu

Í þessum hluta langar mig að sýna útfærslu á fjöllíkönum í DBMS skjala með því að nota dæmið um þann ekki vinsælasta þeirra, MongoDB (eins og sagt var, það hefur aðeins skilyrta línuritsrekstraraðila $lookup и $graphLookup, ekki að vinna í rifnum söfnum), en nota dæmi um þroskaðara og „fyrirtæki“ DBMS MarkLogic.

Svo, láttu safnið innihalda safn af XML skjölum af eftirfarandi gerð (MarkLogic gerir þér einnig kleift að geyma JSON skjöl):

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

Venslalíkan í MarkLogic

Hægt er að búa til venslasýn yfir safn skjala með því að nota sýna sniðmát (innihald þátta value í dæminu hér að neðan getur verið handahófskennt XPath):

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

Þú getur tekið á stofnuðu yfirliti með SQL fyrirspurn (til dæmis í gegnum ODBC):

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

Því miður er samskiptayfirlitið sem búið er til með skjásniðmátinu skrifvarið. Þegar unnið er úr beiðni um það mun MarkLogic reyna að nota skjalaskrár. Áður hafði MarkLogic takmarkaðar skoðanir á samskiptum, algjörlega miðað við vísitölu og skrifanleg, en nú eru þau talin úrelt.

Graflíkan í MarkLogic

Með stuðningi við graf (RDF) líkanið er allt um það sama. Aftur með hjálp sýna sniðmát þú getur búið til RDF framsetningu á safni skjala úr dæminu hér að ofan:

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

Þú getur tekið á RDF línuritinu sem myndast með SPARQL fyrirspurn:

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

Ólíkt því sem tengist, styður MarkLogic línuritslíkanið á tvo aðra vegu:

DBMS getur verið fullgild aðskilin geymsla RDF gagna (tríletur í því verður kallaður tókst öfugt við þá sem lýst er hér að ofan dregin út).
RDF í sérstakri serialization er einfaldlega hægt að setja inn í XML eða JSON skjöl (og þríburar verða þá kallaðir stjórnlaus). Þetta er líklega valkostur við kerfi idref o.fl.

Góð hugmynd um hvernig hlutirnir „raunverulega“ virka í MarkLogic er gefin af Optical API, í þessum skilningi er það lágt stigi, þó tilgangur þess sé frekar öfugur - að reyna að draga úr gagnalíkaninu sem notað er, til að tryggja samræmda vinnu með gögn í mismunandi gerðum, viðskipti o.s.frv.

Marggerða DBMS „án aðallíköns“

Það eru líka DBMS á markaðnum sem staðsetja sig sem upphaflega fjölmódel, án nokkurrar erfðrar aðallíköns. Þar á meðal eru ArangoDB, OrientDB (síðan 2018 tilheyrir þróunarfyrirtækinu SAP) og CosmosDB (þjónusta sem hluti af Microsoft Azure skýjapalli).

Reyndar eru til „kjarna“ líkön í ArangoDB og OrientDB. Í báðum tilfellum eru þetta þeirra eigin gagnalíkön, sem eru alhæfingar á skjalinu eitt. Alhæfingarnar eru aðallega til að auðvelda getu til að framkvæma fyrirspurnir af línuriti og venslaeðli.

Þessar gerðir eru þær einu sem eru tiltækar til notkunar í tilgreindu DBMS; þeirra eigin fyrirspurnartungumál eru hönnuð til að vinna með þeim. Auðvitað eru slík líkön og DBMS efnileg, en skortur á samhæfni við staðlaðar gerðir og tungumál gerir það ómögulegt að nota þessar DBMS í eldri kerfum - til að skipta um DBMS sem þegar eru notuð þar.

Það var þegar frábær grein um ArangoDB og OrientDB á Habré: JOIN í NoSQL gagnagrunna.

ArangoDB

ArangoDB krefst stuðnings við línuritsgagnalíkan.

Hnútar línurits í ArangoDB eru venjuleg skjöl og brúnirnar eru skjöl af sérstakri gerð sem ásamt venjulegum kerfisreitum hafa (_key, _id, _rev) kerfisreitir _from и _to. Skjöl í DBMS skjala eru venjulega sameinuð í söfn. Söfn skjala sem tákna brúnir eru kölluð brúnsöfn í ArangoDB. Við the vegur, brún safn skjöl eru líka skjöl, svo brúnir í ArangoDB geta líka virkað sem hnútar.

Upphafleg gögn

Leyfðu okkur að hafa safn persons, þar sem skjölin líta svona út:

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

Látum það líka vera söfnun cafes:

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

Síðan söfnunin likes gæti litið svona út:

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

Fyrirspurnir og niðurstöður

Fyrirspurn í línuritstíl á AQL tungumálinu sem notað er í ArangoDB, sem skilar á mönnum læsilegu formi upplýsingum um hverjum líkar við hvaða kaffihús, lítur svona út:

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

Í tengslastíl, þar sem við erum að „reikna“ tengsl frekar en að geyma þau, er hægt að endurskrifa þessa fyrirspurn svona (við the vegur, án safnsins likes gæti verið án):

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 }

Niðurstaðan í báðum tilfellum verður sú sama:

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

Fleiri fyrirspurnir og niðurstöður

Ef niðurstöðusniðið hér að ofan virðist vera meira dæmigert fyrir vensla DBMS en fyrir skjal DBMS, geturðu prófað þessa fyrirspurn (eða þú getur notað COLLECT):

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

Útkoman mun líta svona út:

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

OrientDB

Grunnurinn að því að útfæra línuritslíkan ofan á skjalalíkan í OrientDB er tækifæri skjalareitir, til viðbótar við meira eða minna staðlaða mælikvarðagildi, hafa einnig gildi af gerðum eins og LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Gildi þessara tegunda eru tenglar eða söfn af tenglum á kerfisauðkenni skjöl.

Skjalauðkennið sem kerfið úthlutar hefur „líkamlega merkingu“ sem gefur til kynna staðsetningu færslunnar í gagnagrunninum og lítur einhvern veginn svona út: @rid : #3:16. Þannig eru gildi viðmiðunareiginleika í raun vísbendingar (eins og í línuritslíkaninu) frekar en valskilyrði (eins og í venslalíkaninu).

Eins og ArangoDB eru brúnir í OrientDB sýndar sem aðskilin skjöl (þó að ef brún hefur ekki sína eigin eiginleika er hægt að búa hana til léttur, og það mun ekki samsvara sérstöku skjali).

Upphafleg gögn

Í sniði nálægt dump snið OrientDB gagnagrunnur, gögnin úr fyrra dæminu fyrir ArangoDB myndu líta eitthvað svona út:

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

Eins og við sjáum geyma hornpunktar einnig upplýsingar um komandi og útleiðandi brúnir. Kl að nota Skjal API þarf sjálft að fylgjast með tilvísunarheilleika og Graph API tekur að sér þessa vinnu. En við skulum sjá hvernig aðgangur að OrientDB lítur út í „hreinum“ fyrirspurnarmálum sem eru ekki samþætt forritunarmál.

Fyrirspurnir og niðurstöður

Fyrirspurn með svipaðan tilgang og fyrirspurnin úr dæminu fyrir ArangoDB í OrientDB lítur svona út:

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

Niðurstaðan verður fengin á eftirfarandi formi:

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

Ef niðurstöðusniðið virðist aftur of „vennlegt“ þarftu að fjarlægja línuna með UNWIND():

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

Fyrirspurnartungumáli OrientDB má lýsa sem SQL með Gremlin-líkum innskotum. Í útgáfu 2.2 birtist eyðublað sem líkist 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

Niðurstöðusniðið verður það sama og í fyrri beiðni. Hugsaðu um hvað þarf að fjarlægja til að gera það „vennslara“, eins og í fyrstu fyrirspurninni.

Azure CosmosDB

Í minna mæli, það sem sagt var hér að ofan um ArangoDB og OrientDB á við um Azure CosmosDB. CosmosDB veitir eftirfarandi gagnaaðgangs API: SQL, MongoDB, Gremlin og Cassandra.

SQL API og MongoDB API eru notuð til að fá aðgang að gögnum í skjalalíkaninu. Gremlin API og Cassandra API - til að fá aðgang að gögnum í línuriti og dálkasniði, í sömu röð. Gögn í öllum gerðum eru vistuð á CosmosDB innra líkanasniði: ARS ("atóm-skrá-röð"), sem er líka nálægt skjalinu eitt.

En gagnalíkanið sem notandinn velur og API sem notað er eru fast á þeim tíma sem reikningur er stofnaður í þjónustunni. Það er ekki hægt að nálgast gögn sem eru hlaðin í einu líkani á sniði annars líkans, eins og sýnt er með eitthvað á þessa leið:

Þannig er fjölmódel í Azure CosmosDB í dag aðeins hæfileikinn til að nota nokkra gagnagrunna sem styðja mismunandi gerðir frá einum framleiðanda, sem leysir ekki öll vandamálin við geymslu með mörgum afbrigðum.

Multi-módel DBMS byggt á línuritslíkani?

Athyglisvert er sú staðreynd að enn eru engar DBMS-kerfi með mörgum gerðum á markaðnum sem eru byggðar á línuritslíkani (nema stuðningur við fjölmódel fyrir tvö línuritslíkön samtímis: RDF og LPG; sjá þetta í fyrri útgáfu). Mestu erfiðleikarnir stafa af innleiðingu skjalalíkans ofan á línuritslíkan, frekar en tengslalíkan.

Spurningin um hvernig ætti að útfæra venslalíkan ofan á línuritslíkanið var velt upp jafnvel við myndun þess síðarnefnda. Hvernig talaði, til dæmis, David McGovern:

Það er ekkert innbyggt í línuritsaðferðinni sem kemur í veg fyrir að búið sé til lag (td með viðeigandi flokkun) á línuritagagnagrunni sem gerir tengslasýn kleift með (1) endurheimt á túllum frá venjulegum lykilgildapörum og (2) flokkun á túllur eftir tegund tengsla.

Þegar skjalalíkan er útfært ofan á línuritslíkan þarftu td að hafa eftirfarandi í huga:

Hlutir í JSON fylki eru taldir raðaðir, en þeir sem koma frá hornpunkti brúnar línuritsins eru það ekki;
Gögn í skjalalíkaninu eru venjulega óeðlileg; þú vilt samt ekki geyma nokkur eintök af sama innfellda skjali og undirskjöl hafa venjulega ekki auðkenni;
Á hinn bóginn er hugmyndafræði DBMS skjala að skjöl eru tilbúnir „samlagnir“ sem ekki þarf að smíða upp á nýtt hverju sinni. Nauðsynlegt er að útvega línuritslíkaninu getu til að fá fljótt undirrit sem samsvarar fullbúnu skjali.

Smá auglýsingar

Greinarhöfundur tengist þróun NitrosBase DBMS, innra líkan þess er graf, og ytri líkön - vensla og skjal - eru framsetning þess. Öll líkön eru jöfn: næstum öll gögn eru fáanleg í hverju þeirra með því að nota fyrirspurnartungumál sem er eðlilegt fyrir það. Þar að auki, í hvaða sýn sem er, er hægt að breyta gögnunum. Breytingar munu endurspeglast í innra líkaninu og í samræmi við það í öðrum viðhorfum.

Ég mun vonandi lýsa því hvernig módelsamsvörun lítur út í NitrosBase í einni af eftirfarandi greinum.

Ályktun

Ég vona að almennar útlínur þess sem kallað er fjöllíkanagerð hafi orðið lesanda nokkurn veginn ljós. Marggerða DBMS eru nokkuð mismunandi og „stuðningur fyrir fjölmódel“ getur litið öðruvísi út. Til að skilja hvað er kallað "fjöllíkan" í hverju tilteknu tilviki er gagnlegt að svara eftirfarandi spurningum:

Erum við að tala um að styðja við hefðbundnar gerðir eða einhvers konar „blending“ líkan?
Eru módelin „jöfn“ eða er ein þeirra viðfangsefni hinna?
Eru módelin „afskiptalaus“ um hvort annað? Er hægt að lesa gögn sem eru skrifuð í einu líkani í öðru eða jafnvel yfirskrifa?

Ég held að nú þegar sé hægt að svara spurningunni um mikilvægi DBMS með mörgum gerðum, en áhugaverð spurning er hvaða tegundir þeirra verða eftirsóttari í náinni framtíð. Svo virðist sem DBMS-kerfi með mörgum gerðum sem styðja hefðbundin líkön, fyrst og fremst tengsl, verði eftirsóttari; Vinsældir fjölgerða DBMS, sem bjóða upp á nýjar gerðir sem sameina kosti ýmissa hefðbundinna, eru spurning um fjarlægari framtíð.

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Notar þú multi-model DBMS?

Við notum það ekki, við geymum allt í einu DBMS og í einni gerð
Við notum margs konar getu hefðbundinna DBMS
Við æfum margræðu þrautseigju
Við notum nýja fjölmódel DBMS (Arango, Orient, CosmosDB)

19 notendur greiddu atkvæði. 4 notendur sátu hjá.

Heimild: www.habr.com

Eru marglíka DBMS undirstaða nútíma upplýsingakerfa?