Sistemele informatice moderne sunt destul de complexe. Nu în ultimul rând, complexitatea lor se datorează complexității datelor prelucrate în ele. Complexitatea datelor constă adesea în varietatea modelelor de date utilizate. Deci, de exemplu, atunci când datele devin „mari”, una dintre caracteristicile problematice nu este doar volumul („volumul”), ci și varietatea („varietatea”).

Dacă nu găsiți încă un defect în raționament, citiți mai departe.

Conținut

Persistență poliglotă
Multi-model
SGBD multimodel bazat pe modelul relațional
     Model de document în MS SQL Server
     Model grafic în MS SQL Server
SGBD multimodel bazat pe modelul documentului
     Model relațional în MarkLogic
     Model grafic în MarkLogic
SGBD cu mai multe modele „fără un model principal”
     ArangoDB
     OrientDB
     Azure CosmosDB
SGBD multimodel bazat pe un model grafic?
Concluzie
Опрос

Persistență poliglotă

Cele de mai sus duce la faptul că, uneori, chiar și în cadrul unui singur sistem, este necesar să se utilizeze mai multe SGBD-uri diferite pentru a stoca date și a rezolva diverse probleme de prelucrare a acestora, fiecare dintre acestea suportând propriul model de date. Cu mâna ușoară a lui M. Fowler, autor o serie de cărţi celebre şi una dintre co-autori Manifest Agile, se numește această situație stocare cu mai multe variante („persistență poliglotă”).

Fowler are, de asemenea, următorul exemplu de organizare a stocării datelor într-o aplicație cu funcții complete și cu încărcare mare în domeniul comerțului electronic.

Acest exemplu, desigur, este oarecum exagerat, dar pot fi găsite unele considerații în favoarea alegerii unuia sau altuia DBMS în scopul corespunzător, de exemplu, aici.

Este clar că a fi servitor într-o astfel de grădină zoologică nu este ușor.

Cantitatea de cod care realizează stocarea datelor crește proporțional cu numărul de SGBD-uri utilizate; cantitatea de date de sincronizare a codului este bună dacă nu este proporțională cu pătratul acestui număr.
Ca multiplu al numărului de SGBD utilizate, costurile furnizării caracteristicilor întreprinderii (scalabilitate, toleranță la erori, disponibilitate ridicată) ale fiecărui SGBD-uri utilizate cresc.
Este imposibil să se asigure caracteristicile întreprinderii ale subsistemului de stocare în ansamblu - în special tranzacționalitatea.

Din punctul de vedere al directorului grădinii zoologice, totul arată așa:

O creștere multiplă a costului licențelor și al suportului tehnic de la producătorul DBMS.
Excesul de personal și termenele limită crescute.
Pierderi financiare directe sau penalități din cauza inconsecvenței datelor.

Există o creștere semnificativă a costului total de proprietate (TCO) al sistemului. Există vreo cale de ieșire din situația „opțiunilor de stocare multiple”?

Multi-model

Termenul „stocare multivariată” a intrat în uz în 2011. Conștientizarea problemelor abordării și căutarea unei soluții a durat câțiva ani, iar până în 2015, prin gura analiștilor Gartner, s-a formulat răspunsul:

De la "Ghid de piață pentru SGBD-uri NoSQL - 2015»:
Viitorul SGBD-urilor, arhitecturile lor și modalitățile de utilizare a acestora este multi-model.
De la "Magic Quadrant pentru ODBMS - 2016»:
SGBD-urile operaționale de vârf vor oferi mai multe modele - relaționale și non-relaționale - ca parte a unei singure platforme.

Se pare că de data aceasta analiștii Gartner au avut dreptate cu prognoza lor. Daca mergi la pagina cu rating principal DBMS pe DB-Engines, puteți vedea astaоMajoritatea liderilor săi se poziționează în mod specific ca SGBD-uri cu mai multe modele. Același lucru poate fi văzut pe pagina cu orice rating privat.

Tabelul de mai jos prezintă DBMS - liderii în fiecare dintre ratingurile private, care pretind a fi multi-model. Pentru fiecare SGBD sunt indicate modelul suportat inițial (care a fost cândva singurul) și împreună cu acesta modelele suportate în prezent. De asemenea, sunt enumerate SGBD-urile care se poziționează ca „inițial multi-model” și, conform creatorilor, nu au niciun model moștenit inițial.

SGBD	Modelul initial	Modele suplimentare
Oracol	Relațional	Grafic, document
MS SQL	Relațional	Grafic, document
PostgreSQL	Relațional	Grafic*, document
MarkLogic	Film documentar	Grafic, relațional
MongoDB	Film documentar	Valoare-cheie, grafic*
DataStax	Coloană largă	Documentar, grafic
Redis	Valoare cheie	Documentar, grafic*
ArangoDB	-	Grafic, document
OrientDB	-	Grafic, document, relațional
Azure CosmosDB	-	Grafic, document, relațional

Note pe masă

Asteriscurile din tabel marchează afirmațiile care necesită rezerve:

SGBD PostgreSQL nu acceptă modelul de date grafice, dar acest produs îl acceptă pe baza ei, cum ar fi AgensGraph.
În ceea ce privește MongoDB, este mai corect să vorbim despre prezența operatorilor grafici în limbajul de interogare ($lookup, $graphLookup) decât despre susținerea modelului graf, deși, desigur, introducerea lor a necesitat unele optimizări la nivel de stocare fizică în direcția susținerii modelului graf.
În legătură cu Redis, ne referim la extensie RedisGraph.

În continuare, pentru fiecare dintre clase, vom arăta cum este implementat suportul pentru mai multe modele în DBMS din această clasă. Vom considera modelele relaționale, documentare și grafice ca fiind cele mai importante și vom folosi exemple de SGBD-uri specifice pentru a arăta cum sunt implementate „cele lipsă”.

SGBD multimodel bazat pe modelul relațional

Principalele SGBD-uri în prezent sunt relaționale, prognoza Gartner nu ar putea fi considerată adevărată dacă SGBD-urile nu ar prezenta mișcare în direcția modelării multiple. Și ei demonstrează. Acum ideea că un DBMS cu mai multe modele este ca un cuțit elvețian, care nu poate face nimic bine, poate fi direcționată direct către Larry Ellison.

Autorul, însă, preferă implementarea modelării multiple în Microsoft SQL Server, pe exemplul căruia va fi descris suportul RDBMS pentru modele de documente și grafice.

Model de document în MS SQL Server

Au existat deja două articole excelente despre Habré despre modul în care MS SQL Server implementează suportul pentru modelul de document, mă voi limita la o scurtă repovestire și un comentariu:

Modul de susținere a modelului de document în MS SQL Server este destul de tipic pentru SGBD-urile relaționale: documentele JSON sunt propuse a fi stocate în câmpuri de text obișnuite. Suportul pentru modelul de document este de a oferi operatori speciali pentru a analiza acest JSON:

JSON_VALUE pentru a extrage valorile atributelor scalare,
JSON_QUERY pentru a extrage subdocumente.

Al doilea argument al ambilor operatori este o expresie în sintaxă asemănătoare JSONPath.

În mod abstract, putem spune că documentele stocate în acest fel nu sunt „entități de primă clasă” într-un SGBD relațional, spre deosebire de tupluri. Mai exact, în MS SQL Server nu există în prezent indici pe câmpurile documentelor JSON, ceea ce face dificilă unirea tabelelor folosind valorile acestor câmpuri și chiar selectarea documentelor folosind aceste valori. Cu toate acestea, este posibil să creați o coloană calculată pentru un astfel de câmp și un index pe acesta.

În plus, MS SQL Server oferă posibilitatea de a construi în mod convenabil un document JSON din conținutul tabelelor folosind operatorul FOR JSON PATH - o posibilitate, într-un anumit sens, opusă celei anterioare, stocarea convențională. Este clar că, oricât de rapid este un RDBMS, această abordare contrazice ideologia SGBD-urilor de documente, care stochează, în esență, răspunsuri gata făcute la interogările populare și nu pot decât să rezolve problemele de ușurință de dezvoltare, dar nu de viteză.

În cele din urmă, MS SQL Server vă permite să rezolvați problema opusă a construcției documentelor: puteți descompune JSON în tabele folosind OPENJSON. Dacă documentul nu este complet plat, va trebui să îl utilizați CROSS APPLY.

Model grafic în MS SQL Server

Suportul pentru modelul grafic (LPG) este implementat complet și în Microsoft SQL Server previzibil: Se propune utilizarea tabelelor speciale pentru a stoca noduri și pentru a stoca marginile graficului. Astfel de tabele sunt create folosind expresii CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectiv.

Tabelele de primul tip sunt similare cu tabelele obișnuite pentru stocarea înregistrărilor, singura diferență externă fiind că tabelul conține un câmp de sistem $node_id — identificatorul unic al unui nod grafic din baza de date.

În mod similar, tabelele de al doilea tip au câmpuri de sistem $from_id и $to_id, intrările din astfel de tabele definesc clar conexiunile dintre noduri. Un tabel separat este folosit pentru a stoca relațiile de fiecare tip.

Să ilustrăm acest lucru cu un exemplu. Lăsați datele din grafic să aibă un aspect ca cel prezentat în figură. Apoi, pentru a crea structura corespunzătoare în baza de date, trebuie să rulați următoarele interogări DDL:

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

Principala specificitate a unor astfel de tabele este că, în interogările împotriva lor, este posibil să se utilizeze modele grafice cu sintaxă asemănătoare Cypher (cu toate acestea, „*„etc. nu sunt încă suportate). Pe baza măsurătorilor de performanță, se poate presupune, de asemenea, că modul în care datele sunt stocate în aceste tabele este diferit de modul în care datele sunt stocate în tabelele obișnuite și este optimizat pentru executarea unor astfel de interogări grafice.

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

Mai mult decât atât, este destul de dificil să nu folosiți aceste modele de grafic atunci când lucrați cu astfel de tabele, deoarece în interogările SQL obișnuite pentru a rezolva probleme similare va fi necesar să depuneți eforturi suplimentare pentru a obține identificatori de noduri „graf” de sistem ($node_id, $from_id, $to_id; Din același motiv, interogările pentru inserarea datelor nu sunt afișate aici, deoarece sunt inutil de greoaie).

Pentru a rezuma descrierea implementărilor modelelor de documente și grafice în MS SQL Server, aș observa că astfel de implementări ale unui model peste altul nu par de succes, în primul rând din punctul de vedere al designului limbajului. Este necesar să extindeți o limbă cu alta, limbile nu sunt complet „ortogonale”, regulile de compatibilitate pot fi destul de bizare.

SGBD multimodel bazat pe modelul documentului

În această secțiune, aș dori să ilustrez implementarea multi-modelului în SGBD-urile documentelor folosind exemplul celui mai puțin popular dintre ele, MongoDB (cum s-a spus, are doar operatori de grafică condiționată $lookup и $graphLookup, nu lucrează la colecții fragmentate), ci folosind exemplul unui SGBD mai matur și „întreprindere” MarkLogic.

Deci, lăsați colecția să conțină un set de documente XML de următorul tip (MarkLogic vă permite și să stocați documente JSON):

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

Model relațional în MarkLogic

O vedere relațională a unei colecții de documente poate fi creată folosind șablon de afișare (conținutul elementelor value în exemplul de mai jos poate exista un XPath arbitrar):

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

Puteți adresa vizualizarea creată cu o interogare SQL (de exemplu, prin ODBC):

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

Din păcate, vizualizarea relațională creată de șablonul de afișare este doar pentru citire. Când procesează o solicitare pentru aceasta, MarkLogic va încerca să o folosească indexurile documentelor. Anterior, MarkLogic avea viziuni relaționale limitate, în întregime bazat pe index și inscriptibile, dar acum sunt considerate depreciate.

Model grafic în MarkLogic

Cu suport pentru modelul grafic (RDF), totul este aproximativ la fel. Din nou cu ajutorul șablon de afișare Puteți crea o reprezentare RDF a unei colecții de documente din exemplul de mai sus:

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

Puteți adresa graficul RDF rezultat cu o interogare SPARQL:

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

Spre deosebire de cel relațional, MarkLogic acceptă modelul grafic în alte două moduri:

Un DBMS poate fi o stocare separată cu drepturi depline a datelor RDF (tripleții din acesta vor fi denumiti gestionate spre deosebire de cele descrise mai sus extras).
RDF în serializare specială poate fi pur și simplu inserat în documente XML sau JSON (și vor fi apoi apelați tripleți neadministrat). Aceasta este probabil o alternativă la mecanisme idref etc

O idee bună despre cum funcționează „cu adevărat” lucrurile în MarkLogic este dată de API optic, în acest sens, este de nivel scăzut, deși scopul său este mai degrabă opus - să încerce să facă abstracție de la modelul de date folosit, să asigure lucrul consistent cu datele din diferite modele, tranzacționalitate etc.

SGBD cu mai multe modele „fără un model principal”

Există și SGBD-uri pe piață care se poziționează inițial ca multi-model, fără niciun model principal moștenit. Acestea includ ArangoDB, OrientDB (din 2018 compania de dezvoltare apartine SAP) si CosmosDB (serviciu ca parte a platformei cloud Microsoft Azure).

De fapt, există modele „de bază” în ArangoDB și OrientDB. În ambele cazuri, acestea sunt propriile modele de date, care sunt generalizări ale celui document. Generalizările sunt în principal pentru a facilita capacitatea de a efectua interogări de natură grafică și relațională.

Aceste modele sunt singurele disponibile pentru utilizare în SGBD-urile specificate, propriile limbaje de interogare sunt concepute pentru a funcționa cu ele. Desigur, astfel de modele și SGBD-uri sunt promițătoare, dar lipsa de compatibilitate cu modelele și limbaje standard face imposibilă utilizarea acestor SGBD-uri în sistemele moștenite - pentru a înlocui SGBD-urile deja folosite acolo.

Exista deja un articol minunat despre ArangoDB și OrientDB pe Habré: JOIN în bazele de date NoSQL.

ArangoDB

ArangoDB revendică suport pentru un model de date grafice.

Nodurile unui graf din ArangoDB sunt documente obișnuite, iar marginile sunt documente de tip special care, împreună cu câmpurile de sistem obișnuite, au (_key, _id, _rev) câmpuri de sistem _from и _to. Documentele din SGBD-urile de documente sunt în mod tradițional combinate în colecții. Colecțiile de documente care reprezintă margini sunt numite colecții de margini în ArangoDB. Apropo, documentele de colectare a marginilor sunt și ele documente, așa că marginile din ArangoDB pot acționa și ca noduri.

Datele brute

Hai să avem o colecție persons, ale căror documente arată astfel:

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

Să fie și o colecție cafes:

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

Apoi colecția likes ar putea arăta astfel:

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

Interogări și rezultate

O interogare în stil grafic în limbajul AQL folosit în ArangoDB, care returnează în formă lizibilă informații despre cine îi place cafeneaua, arată astfel:

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

Într-un stil relațional, în care „calculăm” relații în loc să le stocăm, această interogare poate fi rescrisă astfel (apropo, fără colecția likes ar putea face fara):

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 }

Rezultatul în ambele cazuri va fi același:

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

Mai multe interogări și rezultate

Dacă formatul rezultat de mai sus pare a fi mai tipic pentru un SGBD relațional decât pentru un SGBD document, puteți încerca această interogare (sau puteți utiliza COLLECT):

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

Rezultatul va arăta astfel:

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

OrientDB

Baza pentru implementarea unui model grafic peste un model de document în OrientDB este oportunitate câmpurile de document, pe lângă valorile scalare mai mult sau mai puțin standard, au și valori de tipuri precum LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Valorile acestor tipuri sunt link-uri sau colecții de link-uri către identificatori de sistem documente.

Identificatorul documentului atribuit de sistem are o „semnificație fizică”, indicând poziția înregistrării în baza de date și arată cam așa: @rid : #3:16. Astfel, valorile proprietăților de referință sunt cu adevărat pointeri (ca în modelul grafic) mai degrabă decât condiții de selecție (ca în modelul relațional).

Ca și ArangoDB, muchiile din OrientDB sunt reprezentate ca documente separate (deși dacă o muchie nu are proprietăți proprii, poate fi făcută ușoară, și nu va corespunde unui document separat).

Datele brute

Într-un format apropiat de format dump Baza de date OrientDB, datele din exemplul anterior pentru ArangoDB ar arăta cam așa:

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

După cum putem vedea, vârfurile stochează și informații despre marginile de intrare și de ieșire. La folosind API-ul Document trebuie să monitorizeze integritatea referențială în sine, iar API-ul Graph își asumă această activitate. Dar să vedem cum arată accesul la OrientDB în limbaje de interogare „pure” care nu sunt integrate în limbaje de programare.

Interogări și rezultate

O interogare similară ca scop cu interogarea din exemplul pentru ArangoDB în OrientDB arată astfel:

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

Rezultatul va fi obținut sub următoarea formă:

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

Dacă formatul rezultat pare din nou prea „relațional”, trebuie să eliminați linia cu UNWIND():

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

Limbajul de interogare al OrientDB poate fi descris ca SQL cu inserții asemănătoare Gremlin. În versiunea 2.2, a apărut un formular de solicitare asemănător 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

Formatul rezultatului va fi același ca în cererea anterioară. Gândiți-vă la ce trebuie eliminat pentru a o face mai „relațională”, ca în prima interogare.

Azure CosmosDB

Într-o măsură mai mică, ceea ce s-a spus mai sus despre ArangoDB și OrientDB se aplică Azure CosmosDB. CosmosDB oferă următoarele API-uri de acces la date: SQL, MongoDB, Gremlin și Cassandra.

SQL API și MongoDB API sunt folosite pentru a accesa datele din modelul de document. Gremlin API și Cassandra API - pentru accesarea datelor în formate de grafic și, respectiv, de coloană. Datele din toate modelele sunt salvate în formatul intern al modelului CosmosDB: ARS („atom-record-secvență”), care este, de asemenea, apropiată de cea a documentului.

Dar modelul de date ales de utilizator și API-ul utilizat sunt fixate în momentul creării unui cont în serviciu. Nu este posibil să accesați datele încărcate într-un model în formatul altui model, așa cum este ilustrat de ceva de genul acesta:

Astfel, multi-modelul din Azure CosmosDB este astăzi doar capacitatea de a utiliza mai multe baze de date care acceptă modele diferite de la un producător, ceea ce nu rezolvă toate problemele stocării multivariante.

SGBD multimodel bazat pe un model grafic?

De remarcat este faptul că pe piață nu există SGBD-uri cu mai multe modele, dar care se bazează pe un model grafic (cu excepția suportului pentru mai multe modele pentru două modele de grafice simultan: RDF și LPG; vezi asta în publicația anterioară). Cele mai mari dificultăți sunt cauzate de implementarea unui model de document peste un model grafic, mai degrabă decât de unul relațional.

Întrebarea modului de implementare a unui model relațional peste modelul grafic a fost luată în considerare chiar și în timpul formării acestuia din urmă. Cum vorbitDe exemplu, David McGovern:

Nu există nimic inerent în abordarea grafică care să împiedice crearea unui strat (de exemplu, prin indexare adecvată) pe o bază de date grafică care să permită o vizualizare relațională cu (1) recuperarea tuplurilor din perechile obișnuite de valori cheie și (2) gruparea de tupluri după tipul de relație.

Când implementați un model de document peste un model de grafic, trebuie să aveți în vedere, de exemplu, următoarele:

Elementele unui tablou JSON sunt considerate ordonate, dar cele care emană de la vârful unei margini a graficului nu sunt;
Datele din modelul de document sunt de obicei denormalizate; tot nu doriți să stocați mai multe copii ale aceluiași document încorporat, iar subdocumentele de obicei nu au identificatori;
Pe de altă parte, ideologia SGBD-urilor de documente este că documentele sunt „agregate” gata făcute care nu trebuie să fie construite din nou de fiecare dată. Este necesar să se ofere modelului grafic capacitatea de a obține rapid un subgraf corespunzător documentului finit.

Niște reclame

Autorul articolului este legat de dezvoltarea DBMS NitrosBase, al cărui model intern este grafic, iar modelele externe - relaționale și documentare - sunt reprezentările sale. Toate modelele sunt egale: aproape orice date este disponibilă în oricare dintre ele folosind un limbaj de interogare care este firesc. Mai mult, în orice vedere, datele pot fi modificate. Schimbările se vor reflecta în modelul intern și, în consecință, în alte puncte de vedere.

Sper că voi descrie cum arată potrivirea modelului în NitrosBase într-unul dintre următoarele articole.

Concluzie

Sper că liniile generale ale ceea ce se numește multi-modelare au devenit mai mult sau mai puțin clare pentru cititor. SGBD-urile cu mai multe modele sunt destul de diferite, iar „suportul pentru mai multe modele” poate arăta diferit. Pentru a înțelege ceea ce se numește „multi-model” în fiecare caz specific, este util să răspundeți la următoarele întrebări:

Vorbim despre susținerea modelelor tradiționale sau a unui fel de model „hibrid”?
Modelele sunt „egale”, sau unul dintre ele este subiectul celorlalți?
Sunt modelele „indiferente” unul față de celălalt? Datele scrise într-un model pot fi citite în altul sau chiar suprascrise?

Cred că întrebarea despre relevanța DBMS-ului cu mai multe modele poate primi deja un răspuns pozitiv, dar întrebarea interesantă este ce tipuri de ele vor fi mai solicitate în viitorul apropiat. Se pare că SGBD-urile cu mai multe modele care suportă modele tradiționale, în primul rând relaționale, vor avea o cerere mai mare; Popularitatea SGBD-urilor cu mai multe modele, care oferă modele noi care combină avantajele diverselor tradiționale, este o chestiune de viitor mai îndepărtat.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.