ProHoster > Blogs > interneta ziņas > Vai vairāku modeļu DBVS ir mūsdienu informācijas sistēmu pamats?

Vai vairāku modeļu DBVS ir mūsdienu informācijas sistēmu pamats?

MÅ«sdienu informācijas sistēmas ir diezgan sarežģītas. Ne mazāk svarÄ«gi ir tas, ka to sarežģītÄ«ba ir saistÄ«ta ar tajos apstrādāto datu sarežģītÄ«bu. Datu sarežģītÄ«ba bieži ir saistÄ«ta ar izmantoto datu modeļu dažādÄ«bu. Tā, piemēram, kad dati kļūst ā€œlieliā€, viens no problemātiskajiem raksturlielumiem ir ne tikai to apjoms (ā€œvolumeā€), bet arÄ« daudzveidÄ«ba (ā€œvarietyā€).

Ja argumentācijā vēl neatrodat trūkumu, lasiet tālāk.

Vai vairāku modeļu DBVS ir mūsdienu informācijas sistēmu pamats?


saturs

Poliglota noturība
Daudzmodelis
Vairāku modeļu DBVS, kuru pamatā ir relāciju modelis
     Dokumenta modelis MS SQL Server
     Grafika modelis MS SQL Server
Vairāku modeļu DBVS, pamatojoties uz dokumenta modeli
     Relāciju modelis MarkLogic
     Grafika modelis programmā MarkLogic
Vairāku modeļu DBVS ā€œbez galvenā modeļaā€
     ArangoDB
     OrientDB
     Azure CosmosDB
Vairāku modeļu DBVS, kuru pamatā ir diagrammas modelis?
Secinājums
ŠžŠæрŠ¾Ń

Poliglota noturība

IepriekÅ”minētais noved pie tā, ka dažkārt pat vienas sistēmas ietvaros datu glabāŔanai un dažādu to apstrādes problēmu risināŔanai ir nepiecieÅ”ams izmantot vairākas dažādas DBVS, no kurām katra atbalsta savu datu modeli. Ar M. Faulera vieglo roku, autors vairākas slavenas grāmatas un viena no lÄ«dzautori Agile Manifesto, Å”o situāciju sauc vairāku variantu krātuve (ā€œpoliglota neatlaidÄ«baā€).

Fauleram ir arÄ« Ŕāds piemērs datu glabāŔanas organizÄ“Å”anai pilnvērtÄ«gā un lielas slodzes lietojumprogrammā e-komercijas jomā.

Vai vairāku modeļu DBVS ir mūsdienu informācijas sistēmu pamats?

Å is piemērs, protams, ir nedaudz pārspÄ«lēts, taču daži apsvērumi par labu vienas vai otras DBVS izvēlei atbilstoÅ”ajam mērÄ·im ir atrodami, piemēram, Å”eit.

Skaidrs, ka būt par kalpu Ŕādā zoodārzā nav viegli.

  • Koda apjoms, kas veic datu uzglabāŔanu, pieaug proporcionāli izmantoto DBVS skaitam; kodu sinhronizÄ“Å”anas datu apjoms ir labs, ja nav proporcionāls Ŕī skaitļa kvadrātam.
  • Kā reizinot izmantoto DBVS skaitu, palielinās katras izmantotās DBVS uzņēmuma raksturlielumu (mērogojamÄ«ba, kļūdu tolerance, augsta pieejamÄ«ba) nodroÅ”ināŔanas izmaksas.
  • Nav iespējams nodroÅ”ināt visas krātuves apakÅ”sistēmas uzņēmuma Ä«paŔības - Ä«paÅ”i transakciju.

No zoodārza direktora viedokļa viss izskatās Ŕādi:

  • Daudzkārtējs licenču izmaksu pieaugums un DBVS ražotāja tehniskais atbalsts.
  • PārmērÄ«gs darbinieku skaits un pagarināti termiņi.
  • TieÅ”ie finansiālie zaudējumi vai sodi datu neatbilstÄ«bas dēļ.

Sistēmas kopējās Ä«paÅ”umtiesÄ«bu izmaksas (TCO) ir ievērojami palielinājuŔās. Vai ir kāda izeja no ā€œvairāku uzglabāŔanas iespējuā€ situācijas?

Daudzmodelis

Termins ā€œdaudzfaktoru krātuveā€ tika lietots 2011. gadā. Pieejas problēmu apzināŔanās un risinājuma meklÄ“Å”ana ilga vairākus gadus, un lÄ«dz 2015. gadam ar Gartner analÄ«tiÄ·u mutēm tika formulēta atbilde:

Å Ä·iet, ka Å”oreiz Gartner analÄ«tiÄ·iem bija taisnÄ«ba ar savām prognozēm. Ja dodaties uz lapu ar galvenais vērtējums DBVS uz DB-Engines, jÅ«s to varat redzētŠ¾Lielākā daļa tās vadÄ«tāju sevi pozicionē kā vairāku modeļu DBVS. To paÅ”u var redzēt lapā ar jebkuru privātu vērtējumu.

Zemāk esoÅ”ajā tabulā ir parādÄ«ta DBVS ā€” katra privātā reitinga lÄ«deri, kas pretendē uz vairāku modeļu modeli. Katrai DBVS ir norādÄ«ts sākotnējais atbalstÄ«tais modelis (kas kādreiz bija vienÄ«gais) un kopā ar to paÅ”laik atbalstÄ«tie modeļi. UzskaitÄ«tas arÄ« DBVS, kas sevi pozicionē kā ā€œsākotnēji vairāku modeļuā€ un, pēc veidotāju domām, tām nav sākotnēji mantota modeļa.

DBVS Sākotnējais modelis Papildu modeļi
Orākuls Relāciju Grafiks, dokuments
MS SQL Relāciju Grafiks, dokuments
PostgreSQL Relāciju Grafiks*, dokuments
MarkLogic Dokumentālā filma Grafiks, relāciju
MongoDB Dokumentālā filma Atslēgas vērtība, diagramma*
DataStax Plata kolonna Dokumentālā filma, grafiks
Redis Atslēgas vērtība dokumentālā filma, grafiks*
ArangoDB Sākot no Grafiks, dokuments
OrientDB Sākot no Grafiks, dokuments, relāciju
Azure CosmosDB Sākot no Grafiks, dokuments, relāciju

Piezīmes uz galda

Ar zvaigznÄ«tēm tabulā tiek atzÄ«mēti apgalvojumi, kuriem nepiecieÅ”amas atrunas:

  • PostgreSQL DBVS neatbalsta diagrammas datu modeli, taču Å”is produkts to atbalsta pamatojoties uz to, piemēram, AgensGraph.
  • SaistÄ«bā ar MongoDB ir pareizāk runāt par grafiku operatoru klātbÅ«tni vaicājuma valodā ($lookup, $graphLookup) nekā par grafika modeļa atbalstÄ«Å”anu, lai gan, protams, to ievieÅ”ana prasÄ«ja dažas optimizācijas fiziskās krātuves lÄ«menÄ« grafika modeļa atbalsta virzienā.
  • SaistÄ«bā ar Redis mēs domājam paplaÅ”inājumu RedisGraph.

Tālāk, katrai no klasēm, mēs parādÄ«sim, kā atbalsts vairākiem modeļiem tiek Ä«stenots DBVS no Ŕīs klases. Mēs uzskatÄ«sim relāciju, dokumentu un grafiku modeļus par vissvarÄ«gākajiem un izmantosim konkrētu DBVS piemērus, lai parādÄ«tu, kā tiek Ä«stenoti ā€œtrÅ«kstoÅ”ieā€.

Vairāku modeļu DBVS, kuru pamatā ir relāciju modelis

PaÅ”laik vadoŔās DBVS ir relācijas; Gartnera prognozi nevarētu uzskatÄ«t par patiesām, ja RDBVS neuzrādÄ«tu kustÄ«bu vairāku modelÄ“Å”anas virzienā. Un viņi demonstrē. Tagad domu, ka vairāku modeļu DBVS ir kā Å veices nazis, kas neko labu nevar izdarÄ«t, var novirzÄ«t tieÅ”i uz Leriju Elisonu.

Autors tomēr dod priekÅ”roku vairāku modelÄ“Å”anas ievieÅ”anai Microsoft SQL Server, uz kura piemēra tiks aprakstÄ«ts RDBMS atbalsts dokumentu un grafiku modeļiem.

Dokumenta modelis MS SQL Server

Par HabrĆ© jau ir bijuÅ”i divi lieliski raksti par to, kā MS SQL Server ievieÅ” atbalstu dokumenta modelim; Es aprobežoÅ”os ar Ä«su pārstāstÄ«jumu un komentāriem:

Veids, kā atbalstÄ«t dokumentu modeli MS SQL Server, ir diezgan tipisks relāciju DBVS: JSON dokumentus tiek piedāvāts glabāt parastos teksta laukos. Dokumenta modeļa atbalsts ir nodroÅ”ināt Ä«paÅ”us operatorus Ŕī JSON parsÄ“Å”anai:

  • JSON_VALUE lai iegÅ«tu skalāro atribÅ«tu vērtÄ«bas,
  • JSON_QUERY lai izvilktu apakÅ”dokumentus.

Otrais abu operatoru arguments ir izteiksme JSONPath līdzīgā sintaksē.

Abstrakti, mēs varam teikt, ka Ŕādi glabātie dokumenti atŔķirÄ«bā no relāciju DBVS nav ā€œpirmās klases entÄ«tijasā€. Konkrēti, MS SQL Server paÅ”laik nav indeksu JSON dokumentu laukos, kas apgrÅ«tina tabulu savienoÅ”anu, izmantojot Å”o lauku vērtÄ«bas, un pat atlasÄ«t dokumentus, izmantojot Ŕīs vērtÄ«bas. Tomēr Ŕādam laukam ir iespējams izveidot aprēķinātu kolonnu un indeksu uz tā.

Turklāt MS SQL Server nodroÅ”ina iespēju ērti izveidot JSON dokumentu no tabulu satura, izmantojot operatoru FOR JSON PATH - iespēja noteiktā nozÄ«mē, kas ir pretēja iepriekŔējai, parastajai uzglabāŔanai. Ir skaidrs, ka neatkarÄ«gi no tā, cik ātra ir RDBVS, Ŕī pieeja ir pretrunā ar dokumentu DBVS ideoloÄ£iju, kas bÅ«tÄ«bā glabā gatavas atbildes uz populāriem vaicājumiem, un var atrisināt tikai izstrādes viegluma, bet ne ātruma problēmas.

Visbeidzot, MS SQL Server ļauj atrisināt pretēju dokumentu veidoÅ”anas problēmu: varat sadalÄ«t JSON tabulās, izmantojot OPENJSON. Ja dokuments nav pilnÄ«bā plakans, jums bÅ«s jāizmanto CROSS APPLY.

Grafika modelis MS SQL Server

Grafika (LPG) modeļa atbalsts ir pilnÄ«bā ieviests arÄ« Microsoft SQL Server paredzams: Tiek ierosināts izmantot Ä«paÅ”as tabulas mezglu un grafu malu saglabāŔanai. Šādas tabulas tiek veidotas, izmantojot izteiksmes CREATE TABLE AS NODE Šø CREATE TABLE AS EDGE attiecÄ«gi.

Pirmā tipa tabulas ir lÄ«dzÄ«gas parastajām tabulām ierakstu glabāŔanai, un vienÄ«gā ārējā atŔķirÄ«ba ir tā, ka tabulā ir sistēmas lauks $node_id ā€” datu bāzē esoŔā grafika mezgla unikālais identifikators.

LÄ«dzÄ«gi otrā tipa tabulām ir sistēmas lauki $from_id Šø $to_id, ieraksti Ŕādās tabulās skaidri definē savienojumus starp mezgliem. Katra veida attiecÄ«bu glabāŔanai tiek izmantota atseviŔķa tabula.

Vai vairāku modeļu DBVS ir mÅ«sdienu informācijas sistēmu pamats? Ilustrēsim to ar piemēru. Ä»aujiet diagrammas datiem izveidot tādu izkārtojumu, kāds parādÄ«ts attēlā. Pēc tam, lai izveidotu atbilstoÅ”o struktÅ«ru datu bāzē, ir jāizpilda Ŕādi DDL vaicājumi:

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

Šādu tabulu galvenā specifika ir tāda, ka pret tām vērstos vaicājumos ir iespējams izmantot grafu modeļus ar Å”ifrÄ“Å”anai lÄ«dzÄ«gu sintaksi (tomēr ā€œ*"u.c. vēl netiek atbalstÄ«ti). Pamatojoties uz veiktspējas mērÄ«jumiem, var arÄ« pieņemt, ka veids, kādā dati tiek glabāti Å”ajās tabulās, atŔķiras no datu glabāŔanas veida parastajās tabulās un ir optimizēti Ŕādu grafiku vaicājumu izpildei.

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

Turklāt, strādājot ar Ŕādām tabulām, ir diezgan grÅ«ti neizmantot Å”os grafiku modeļus, jo parastos SQL vaicājumos, lai atrisinātu lÄ«dzÄ«gas problēmas, bÅ«s jāpieliek papildu pÅ«les, lai iegÅ«tu sistēmas ā€œgrafaā€ mezglu identifikatorus ($node_id, $from_id, $to_id; Tā paÅ”a iemesla dēļ datu ievietoÅ”anas vaicājumi Å”eit netiek parādÄ«ti, jo tie ir nevajadzÄ«gi apgrÅ«tinoÅ”i).

Apkopojot MS SQL Server dokumentu un grafu modeļu realizācijas aprakstu, jāatzÄ«mē, ka Ŕādas viena modeļa ievieÅ”anas virs otra neŔķiet veiksmÄ«gas, pirmkārt no valodas dizaina viedokļa. Ir nepiecieÅ”ams paplaÅ”ināt vienu valodu ar citu, valodas nav pilnÄ«bā ā€œortogonālasā€, saderÄ«bas noteikumi var bÅ«t diezgan dÄ«vaini.

Vairāku modeļu DBVS, pamatojoties uz dokumenta modeli

Å ajā sadaļā es vēlos ilustrēt vairāku modeļu ievieÅ”anu dokumentu DBVS, izmantojot ne vispopulārākās no tām MongoDB piemēru (kā tika teikts, tajā ir tikai nosacÄ«juma grafiku operatori $lookup Šø $graphLookup, nestrādājot ar sadalÄ«tām kolekcijām), bet izmantojot nobrieduŔākas un ā€œuzņēmumaā€ DBVS piemēru. MarkLogic.

Tātad, ļaujiet kolekcijā ietvert Ŕāda veida XML dokumentu kopu (MarkLogic ļauj saglabāt arī JSON dokumentus):

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

Relāciju modelis MarkLogic

Dokumentu kolekcijas relāciju skatu var izveidot, izmantojot displeja veidne (elementu saturs value tālāk esoÅ”ajā piemērā var bÅ«t patvaļīgs 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>

Izveidoto skatu var adresēt ar SQL vaicājumu (piemēram, izmantojot ODBC):

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

Diemžēl displeja veidnes izveidotais relāciju skats ir tikai lasāms. Apstrādājot pieprasÄ«jumu, MarkLogic mēģinās izmantot dokumentu indeksi. IepriekÅ” MarkLogic bija pilnÄ«bā ierobežoti relāciju uzskati pamatojoties uz indeksu un rakstāmi, bet tagad tie tiek uzskatÄ«ti par novecojuÅ”iem.

Grafika modelis programmā MarkLogic

Ar grafiku (RDF) modeļa atbalstu viss ir aptuveni vienāds. Atkal ar palÄ«dzÄ«bu displeja veidne jÅ«s varat izveidot dokumentu kolekcijas RDF attēlojumu, izmantojot iepriekÅ” minēto piemēru:

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

Iegūto RDF grafiku varat risināt, izmantojot SPARQL vaicājumu:

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

AtŔķirībā no relāciju modeļa, MarkLogic atbalsta diagrammas modeli divos citos veidos:

  1. DBVS var bÅ«t pilnvērtÄ«ga atseviŔķa RDF datu krātuve (trÄ«nÄ«Å”i tajā tiks saukti pārvalda atŔķirÄ«bā no iepriekÅ” aprakstÄ«tajiem ekstrahēts).
  2. RDF Ä«paŔā serializācijā var vienkārÅ”i ievietot XML vai JSON dokumentos (un tripleti tiks saukti nepārvaldÄ«ts). Tā, iespējams, ir alternatÄ«va mehānismiem idref uc

Labu priekÅ”statu par to, kā lietas ā€œpatiesÄ«bāā€ darbojas MarkLogic, sniedz Optiskā API, Å”ajā ziņā tas ir zema lÄ«meņa, lai gan tā mērÄ·is ir drÄ«zāk pretējs - mēģināt abstrahēties no izmantotā datu modeļa, nodroÅ”ināt konsekventu darbu ar datiem dažādos modeļos, transakciju u.c.

Vairāku modeļu DBVS ā€œbez galvenā modeļaā€

TirgÅ« ir arÄ« DBVS, kas sevi pozicionē kā sākotnēji vairāku modeļu, bez mantota galvenā modeļa. Tie ietver ArangoDB, OrientDB (kopÅ” 2018. gada izstrādes uzņēmums pieder SAP) un CosmosDB (pakalpojums kā daļa no Microsoft Azure mākoņa platformas).

Faktiski ArangoDB un OrientDB ir ā€œpamataā€ modeļi. Abos gadÄ«jumos tie ir savi datu modeļi, kas ir dokumenta vispārinājumi. Vispārinājumi galvenokārt ir paredzēti, lai atvieglotu spēju veikt grafiku un relāciju vaicājumus.

Å ie modeļi ir vienÄ«gie, kas ir pieejami lietoÅ”anai norādÄ«tajā DBVS; viņu paÅ”u vaicājumu valodas ir paredzētas darbam ar tiem. Protams, Ŕādi modeļi un DBVS ir daudzsoloÅ”i, taču saderÄ«bas trÅ«kums ar standarta modeļiem un valodām padara neiespējamu Å”o DBVS izmantot mantotās sistēmās, lai aizstātu tur jau izmantotās DBVS.

Vietnē HabrĆ© jau bija brÄ«niŔķīgs raksts par ArangoDB un OrientDB: JOIN NoSQL datu bāzēm.

ArangoDB

ArangoDB apgalvo, ka atbalsta grafiku datu modeli.

Grafika mezgli ArangoDB ir parastie dokumenti, bet malas ir Ä«paÅ”a veida dokumenti, kuriem kopā ar parastajiem sistēmas laukiem ir (_key, _id, _rev) sistēmas lauki _from Šø _to. Dokumenti dokumentu DBVS tradicionāli tiek apvienoti kolekcijās. Dokumentu kolekcijas, kas attēlo malas, ArangoDB sauc par malu kolekcijām. Starp citu, malu kolekcijas dokumenti arÄ« ir dokumenti, tāpēc malas ArangoDB var darboties arÄ« kā mezgli.

Neapstrādāti dati

Ļaujiet mums izveidot kolekciju persons, kura dokumenti izskatās Ŕādi:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "ŠŠ»ŠøсŠ°"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Š‘Š¾Š±"  
  }
]

Lai ir arī kolekcija cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Š”Š¶Š¾Š½ Š”Š¾Š½Š½"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Š–Š°Š½-Š–Š°Šŗ"
  }
]

Tad kolekcija likes varētu izskatÄ«ties Ŕādi:

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

Vaicājumi un rezultāti

Grafika stila vaicājums ArangoDB izmantotajā AQL valodā, kas cilvēkiem lasāmā veidā atgriež informāciju par to, kam kura kafejnÄ«ca patÄ«k, izskatās Ŕādi:

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

Relāciju stilā, kad mēs ā€œaprēķinamā€ attiecÄ«bas, nevis tās saglabājam, Å”o vaicājumu var pārrakstÄ«t Ŕādi (starp citu, bez kolekcijas likes varētu iztikt bez):

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 }

Rezultāts abos gadījumos būs vienāds:

[
  { "person" : "ŠŠ»ŠøсŠ°" , likes : "Š–Š°Š½-Š–Š°Šŗ" } ,
  { "person" : "ŠŠ»ŠøсŠ°" , likes : "Š”Š¶Š¾Š½ Š”Š¾Š½Š½" } ,
  { "person" : "Š‘Š¾Š±" , likes : "Š”Š¶Š¾Š½ Š”Š¾Š½Š½" }
]

Vairāk vaicājumu un rezultātu

Ja iepriekÅ” minētais rezultātu formāts Ŕķiet raksturÄ«gāks relāciju DBVS, nevis dokumentu DBVS, varat izmēģināt Å”o vaicājumu (vai varat izmantot COLLECT):

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

Rezultāts izskatīsies Ŕādi:

[
  { "person" : "ŠŠ»ŠøсŠ°" , likes : ["Š–Š°Š½-Š–Š°Šŗ" , "Š”Š¶Š¾Š½ Š”Š¾Š½Š½"]  } ,
  { "person" : "Š‘Š¾Š±" , likes : ["Š”Š¶Š¾Š½ Š”Š¾Š½Š½"] }
]

OrientDB

Pamats grafika modeļa ievieÅ”anai virs dokumenta modeļa OrientDB ir iespēja dokumentu laukos papildus vairāk vai mazāk standarta skalārajām vērtÄ«bām ir arÄ« tādu veidu vērtÄ«bas kā, piemēram LINK, LINKLIST, LINKSET, LINKMAP Šø LINKBAG. Å o veidu vērtÄ«bas ir saites vai saiÅ”u kolekcijas uz sistēmas identifikatori dokumentus.

Sistēmas pieŔķirtajam dokumenta identifikatoram ir ā€œfiziska nozÄ«meā€, kas norāda ieraksta pozÄ«ciju datu bāzē, un tas izskatās apmēram Ŕādi: @rid : #3:16. Tādējādi atsauces Ä«paŔību vērtÄ«bas patieŔām ir norādes (kā grafika modelÄ«), nevis atlases nosacÄ«jumi (kā relāciju modelÄ«).

Tāpat kā ArangoDB, arÄ« OrientDB malas tiek attēlotas kā atseviŔķi dokumenti (lai gan, ja malai nav savu rekvizÄ«tu, to var izveidot viegls, un tas neatbildÄ«s atseviŔķam dokumentam).

Neapstrādāti dati

Formātā, kas tuvs izgāztuves formāts OrientDB datubāze, dati no iepriekŔējā ArangoDB piemēra izskatÄ«tos apmēram Ŕādi:

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

Kā redzam, virsotnes glabā informāciju arÄ« par ienākoÅ”ajām un izejoÅ”ajām malām. Plkst izmantojot Dokumentu API paÅ”ai ir jāuzrauga atsauces integritāte, un Graph API uzņemas Å”o darbu. Bet paskatÄ«simies, kā izskatās piekļuve OrientDB ā€œtÄ«rajāsā€ vaicājumu valodās, kas nav integrētas programmÄ“Å”anas valodās.

Vaicājumi un rezultāti

Vaicājums, kas pēc mērÄ·a ir lÄ«dzÄ«gs vaicājumam no ArangoDB piemēra OrientDB, izskatās Ŕādi:

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

Rezultāts tiks iegūts Ŕādā formā:

[
  { "person_name": "ŠŠ»ŠøсŠ°", "cafe_name": "Š”Š¶Š¾Š½ Š”Š¾Š½Š½" },
  { "person_name": "ŠŠ»ŠøсŠ°", "cafe_name": "Š–Š°Š½-Š–Š°Šŗ" },
  { "person_name": "Š‘Š¾Š±",  "cafe_name": "Š–Š°Š½-Š–Š°Šŗ" }
]

Ja rezultāta formāts atkal Ŕķiet pārāk ā€œrelācijuā€, jums ir jānoņem lÄ«nija ar UNWIND():

[
  { "person_name": "ŠŠ»ŠøсŠ°", "cafe_name": [ "Š”Š¶Š¾Š½ Š”Š¾Š½Š½", "Š–Š°Š½-Š–Š°Šŗ" ] },
  { "person_name": "Š‘Š¾Š±",  "cafe_name": [ "Š–Š°Š½-Š–Š°Šŗ" ' }
]

OrientDB vaicājumu valodu var raksturot kā SQL ar Gremlin lÄ«dzÄ«giem ieliktņiem. Versijā 2.2 parādÄ«jās Å”ifram lÄ«dzÄ«ga pieprasÄ«juma veidlapa, 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

Rezultāta formāts bÅ«s tāds pats kā iepriekŔējā pieprasÄ«jumā. Padomājiet par to, kas ir jānoņem, lai padarÄ«tu to ā€œrelācijuā€, tāpat kā pirmajā vaicājumā.

Azure CosmosDB

Mazākā mērā iepriekÅ” teiktais par ArangoDB un OrientDB attiecas uz Azure CosmosDB. CosmosDB nodroÅ”ina Ŕādas datu piekļuves API: SQL, MongoDB, Gremlin un Cassandra.

SQL API un MongoDB API tiek izmantotas, lai piekļūtu datiem dokumenta modelÄ«. Gremlin API un Cassandra API ā€” lai piekļūtu datiem attiecÄ«gi grafiku un kolonnu formātos. Dati visos modeļos tiek saglabāti CosmosDB iekŔējā modeļa formātā: ARS (ā€œatom-ieraksts-secÄ«baā€), kas arÄ« ir tuvu dokumentam.

Vai vairāku modeļu DBVS ir mūsdienu informācijas sistēmu pamats?

Taču lietotāja izvēlētais datu modelis un izmantotā API ir fiksēts konta izveides brÄ«dÄ« pakalpojumā. Nav iespējams piekļūt datiem, kas ielādēti vienā modelÄ« cita modeļa formātā, kā to ilustrē Ŕādi:

Vai vairāku modeļu DBVS ir mūsdienu informācijas sistēmu pamats?

Tādējādi vairāku modeļu Azure CosmosDB mūsdienās ir tikai iespēja izmantot vairākas datu bāzes, kas atbalsta dažādus viena ražotāja modeļus, kas neatrisina visas vairāku variantu krātuves problēmas.

Vairāku modeļu DBVS, kuru pamatā ir diagrammas modelis?

IevērÄ«bas cienÄ«gs ir fakts, ka tirgÅ« vēl nav nevienas vairāku modeļu DBVS, kuru pamatā ir grafu modelis (izņemot vairāku modeļu atbalstu vienlaicÄ«gi diviem grafiku modeļiem: RDF un LPG; skatiet to sadaļā iepriekŔējā publikācija). Vislielākās grÅ«tÄ«bas rada dokumenta modeļa ievieÅ”ana uz grafa modeļa, nevis relāciju modeļa.

Jautājums par to, kā ieviest relāciju modeli virs grafa modeļa, tika apsvērts pat tā veidoÅ”anas laikā. Kā teica, piemēram, Deivids Makgoverns:

Grafika pieejai nav nekas raksturÄ«gs, kas neļautu izveidot slāni (piem., izmantojot atbilstoÅ”u indeksāciju) grafiku datu bāzē, kas nodroÅ”ina relāciju skatu ar (1) korežu atkopÅ”anu no parastajiem atslēgu vērtÄ«bu pāriem un (2) grupÄ“Å”anu korteži pēc attiecÄ«bu veida.

IevieÅ”ot dokumenta modeli virs diagrammas modeļa, jums jāpatur prātā, piemēram, tālāk norādÄ«tais.

  • JSON masÄ«va elementi tiek uzskatÄ«ti par sakārtotiem, bet tie, kas izplÅ«st no diagrammas malas virsotnes, netiek uzskatÄ«ti;
  • Dati dokumenta modelÄ« parasti ir denormalizēti; jÅ«s joprojām nevēlaties saglabāt vairākas viena un tā paÅ”a iegultā dokumenta kopijas, un apakÅ”dokumentiem parasti nav identifikatoru;
  • No otras puses, dokumentu DBVS ideoloÄ£ija ir tāda, ka dokumenti ir gatavi ā€œagregātiā€, kas nav katru reizi jāveido no jauna. Grafa modelim ir jānodroÅ”ina iespēja ātri iegÅ«t gatavajam dokumentam atbilstoÅ”u apakÅ”grafu.

Kaut kāda reklāma

Raksta autors ir saistÄ«ts ar NitrosBase DBVS izstrādi, kuras iekŔējais modelis ir grafs, bet ārējie modeļi - relāciju un dokumentu - ir tā reprezentācijas. Visi modeļi ir vienādi: gandrÄ«z visi dati ir pieejami jebkurā no tiem, izmantojot tai dabisku vaicājumu valodu. Turklāt jebkurā skatā datus var mainÄ«t. Izmaiņas tiks atspoguļotas iekŔējā modelÄ« un attiecÄ«gi arÄ« citos skatÄ«jumos.

Cerams, ka kādā no Å”iem rakstiem es aprakstÄ«Å”u, kā izskatās modeļu saskaņoÅ”ana programmā NitrosBase.

Secinājums

Ceru, ka lasÄ«tājam ir kļuvuÅ”as vairāk vai mazāk skaidras vispārÄ«gās aprises tam, ko sauc par multimodelÄ“Å”anu. Vairāku modeļu DBVS ir diezgan atŔķirÄ«gas, un ā€œvairāku modeļu atbalstsā€ var izskatÄ«ties savādāk. Lai saprastu, ko katrā konkrētajā gadÄ«jumā sauc par "vairāku modeli", ir lietderÄ«gi atbildēt uz Ŕādiem jautājumiem:

  1. Vai mēs runājam par tradicionālo modeļu atbalstÄ«Å”anu vai kādu ā€œhibrÄ«doā€ modeli?
  2. Vai modeļi ir ā€œvienlÄ«dzÄ«giā€, vai arÄ« viens no tiem ir citu priekÅ”mets?
  3. Vai modeļi ir vienaldzīgi viens pret otru? Vai vienā modelī ierakstītos datus var nolasīt citā vai pat pārrakstīt?

Domāju, ka uz jautājumu par vairāku modeļu DBVS aktualitāti jau Å”obrÄ«d var atbildēt pozitÄ«vi, taču interesants ir jautājums, kādi to veidi tuvākajā laikā bÅ«s pieprasÄ«tāki. Å Ä·iet, ka vairāku modeļu DBVS, kas atbalsta tradicionālos modeļus, galvenokārt relāciju, bÅ«s pieprasÄ«tāks; Vairāku modeļu DBVS popularitāte, piedāvājot jaunus modeļus, kas apvieno dažādu tradicionālo priekÅ”rocÄ«bas, ir tālākas nākotnes jautājums.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai izmantojat vairāku modeļu DBVS?

  • Mēs to neizmantojam, mēs visu glabājam vienā DBVS un vienā modelÄ«

  • Mēs izmantojam tradicionālo DBVS vairāku modeļu iespējas

  • Mēs praktizējam poliglota neatlaidÄ«bu

  • Mēs izmantojam jaunu vairāku modeļu DBVS (Arango, Orient, CosmosDB)

Nobalsoja 19 lietotāji. 4 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru