I sistemi d'infurmazione muderni sò abbastanza cumplessi. No menu di tutti, a so cumplessità hè duvuta à a cumplessità di i dati trattati in elli. A cumplessità di e dati spessu si trova in a varietà di mudelli di dati utilizati. Cusì, per esempiu, quandu i dati diventanu "grande", una di e caratteristiche problematiche ùn hè micca solu u so voluminu ("volume"), ma ancu a so varietà ("varietà").

Se ùn avete micca truvatu un difettu in u ragiunamentu, allora leghje.

Cuntenuti

Persistenza poliglotta
Multi-mudellu
DBMS multi-mudellu basatu annantu à u mudellu relazionale
     Modellu di documentu in MS SQL Server
     Mudellu di graficu in MS SQL Server
DBMS multi-mudellu basatu annantu à u mudellu di documentu
     U mudellu relazionale in MarkLogic
     U mudellu di graficu in MarkLogic
DBMS multi-mudellu "senza un mudellu principale"
     ArangoDB
     OrientDB
     Azure CosmosDB
DBMS multi-mudellu basatu annantu à un mudellu graficu?
cunchiusioni
Poll

Persistenza poliglotta

Ciò chì sopra porta à u fattu chì qualchì volta ancu in u quadru di un sistema hè necessariu di utilizà parechji DBMS diffirenti per almacenà e dati è risolve diversi prublemi di trasfurmà elli, ognunu sustene u so propiu mudellu di dati. Cù a manu ligera di M. Fowler, autore un numeru di libri famosi è unu di co-autori Manifestu Agile, sta situazione hè chjamata almacenamiento multi-variante ("persistenza poliglotta").

Fowler hà ancu u seguitu esempiu di urganizà l'almacenamiento di dati in una applicazione cumpleta è alta carica in u campu di e-commerce.

Stu esempiu, sicuru, hè un pocu esageratu, ma certi cunsiderazioni in favore di sceglie unu o un altru DBMS per u scopu currispundenti pò esse trovu, per esempiu, ccà.

Hè chjaru chì esse un servitore in un tali zoo ùn hè micca faciule.

A quantità di codice chì esegue l'almacenamiento di dati cresce in proporzione à u numeru di DBMS utilizati; a quantità di dati di sincronia di codice hè bona s'ellu ùn hè micca proporzionale à u quadru di stu numeru.
Cum'è un multiplu di u numeru di DBMS utilizati, i costi di furnisce e caratteristiche di l'impresa (scalabilità, tolleranza à i difetti, alta dispunibilità) di ognuna di i DBMS utilizati aumentanu.
Hè impussibile di assicurà e caratteristiche di l'impresa di u subsistema di almacenamiento in generale - in particulare a transazzione.

Da u puntu di vista di u direttore di u zoo, tuttu pare cusì:

Un aumentu multiplu di u costu di licenze è supportu tecnicu da u fabricatore DBMS.
Overstaffing è e scadenze aumentate.
Perdite finanziarie dirette o penalità per incoerenza di dati.

Ci hè un aumentu significativu in u costu tutale di pruprietà (TCO) di u sistema. Ci hè una manera di esce da a situazione di "opzioni di almacenamiento multiple"?

Multi-mudellu

U terminu "almacenamiento multivariate" hè ghjuntu in usu in u 2011. A cuscenza di i prublemi di l'approcciu è a ricerca di una suluzione pigghiò parechji anni, è da 2015, per bocca di l'analista Gartner, a risposta hè stata formulata:

da "Guida di u Mercatu per i DBMS NoSQL - 2015»:
U futuru di i DBMS, e so architetture è i modi di usà sò multi-mudellu.
da "Magic Quadrant per ODBMS - 2016»:
I DBMS operativi di punta offreranu parechji mudelli - relazionali è micca relazionali - cum'è parte di una sola piattaforma.

Sembra chì sta volta l'analisti di Gartner anu ghjustu cù a so previsione. Sè vo andate à a pagina cun valutazione principale DBMS nantu à DB-Engines, pudete vede chìоA maiò parte di i so dirigenti si ponenu specificamente cum'è DBMS multi-mudellu. U listessu pò esse vistu nantu à a pagina cù qualsiasi qualificazione privata.

A tavula sottu mostra u DBMS - i capi in ognuna di e valutazioni private, chì pretendenu esse multi-mudellu. Per ogni DBMS, u mudellu originale supportatu (chì era una volta l'unicu) è cun ellu i mudelli attualmente supportati sò indicati. Ci sò ancu listati i DBMS chì si ponenu cum'è "originalmente multi-mudellu" è, sicondu i creatori, ùn anu micca un mudellu ereditatu iniziale.

DBMS	U mudellu iniziale	Modelli supplementari
oraculu	relazionale	Graficu, documentu
MS SQL	relazionale	Graficu, documentu
PostgreSQL	relazionale	Graph*, document
MarkLogic	Documentariu	Graficu, relazionale
MongoDB	Documentariu	Chjave-valore, graficu*
DataStax	Culonna larga	Documentariu, graficu
Redis	Chjave-valore	Documentariu, gràficu*
ArangoDB	-	Graficu, documentu
OrientDB	-	Graficu, documentu, rilazioni
Azure CosmosDB	-	Graficu, documentu, rilazioni

Note nantu à a tavula

L'asterischi in a tavula marcanu dichjarazioni chì necessitanu riservazioni:

U DBMS PostgreSQL ùn sustene micca u mudellu di dati di gràficu, ma stu pruduttu ùn sustene micca basatu annantu à questu, cum'è AgensGraph.
In relazione à MongoDB, hè più currettu di parlà di a prisenza di l'operatori grafichi in a lingua di query ($lookup, $graphLookup) cà di u sustegnu di u mudellu di gràficu, ancu s'è, sicuru, a so intruduzioni necessitava alcune ottimisazioni à u livellu di almacenamentu fisicu in a direzzione di sustene u mudellu di gràficu.
In relazione à Redis, significhemu l'estensione RedisGraph.

In seguitu, per ognuna di e classi, mustraremu cumu u supportu per parechji mudelli hè implementatu in u DBMS da questa classe. Avemu da cunsiderà i mudelli relazionale, di documentu è di gràficu per esse u più impurtante è aduprà esempi di DBMS specifichi per vede cumu si sò implementati "i mancanti".

DBMS multi-mudellu basatu annantu à u mudellu relazionale

I DBMS principali attualmente sò relazionali A previsione di Gartner ùn puderia micca esse cunsiderata vera se RDBMS ùn mostranu micca u muvimentu in a direzzione di multi-modelamentu. È dimustranu. Avà l'idea chì un DBMS multi-mudellu hè cum'è un cuteddu svizzeru, chì ùn pò micca fà nunda bè, pò esse diretta direttamente à Larry Ellison.

L'autore, però, preferisce l'implementazione di multi-modeling in Microsoft SQL Server, nantu à l'esempiu di quale u supportu RDBMS per i mudelli di documentu è gràficu serà descrittu.

Modellu di documentu in MS SQL Server

Ci hè digià statu dui articuli eccellenti nantu à Habré nantu à cumu u MS SQL Server implementa u supportu per u mudellu di documentu, mi limiteraghju à un brevi ricordu è cummentariu:

A manera di sustene u mudellu di documentu in MS SQL Server hè abbastanza tipica per i DBMS relazionali: i ducumenti JSON sò pruposti per esse guardati in i campi di testu ordinali. U supportu per u mudellu di documentu hè di furnisce operatori speciali per analizà stu JSON:

JSON_VALUE per estrarre i valori di attributi scalari,
JSON_QUERY per estrarre i sottodocumenti.

U sicondu argumentu di i dui operatori hè una espressione in sintassi simile à JSONPath.

In modu astrattu, pudemu dì chì i ducumenti almacenati in questu modu ùn sò micca "entità di prima classe" in un DBMS relazionale, à u cuntrariu di tuple. In particulare, in MS SQL Server ùn ci sò attualmente indici nantu à i campi di i ducumenti JSON, chì rende difficiuli di unisce à e tavule cù i valori di sti campi è ancu selezziunate documenti cù questi valori. In ogni casu, hè pussibule di creà una colonna calculata per un tali campu è un indice nantu à questu.

Inoltre, MS SQL Server furnisce l'abilità di custruisce cunvenemente un documentu JSON da u cuntenutu di e tavule cù l'operatore. FOR JSON PATH - una pussibilità, in un certu sensu, oppostu à u precedente, u almacenamentu convenzionale. Hè chjaru chì ùn importa micca quantu un RDBMS hè veloce, questu approcciu contraddisci l'ideulugia di i DBMS di documentu, chì essenzialmente guardanu risposte pronti à e dumande populari, è ponu solu risolve i prublemi di facilità di sviluppu, ma micca di rapidità.

Infine, MS SQL Server permette di risolve u prublema inversu di a custruzzione di documenti: pudete scumpressà JSON in tavule cù OPENJSON. Se u documentu ùn hè micca cumpletamente pianu, avete bisognu di utilizà CROSS APPLY.

Mudellu di graficu in MS SQL Server

U supportu per u mudellu di graficu (LPG) hè ancu implementatu cumplettamente in Microsoft SQL Server prevedibile: Hè prupostu d'utilizà tavule speciale per almacenà i nodi è per almacenà i bordi di u graficu. Tali tavule sò creati cù espressioni CREATE TABLE AS NODE и CREATE TABLE AS EDGE rispettivament.

I tavulini di u primu tipu sò simili à e tavule ordinarie per almacenà i registri, cù l'unica diferenza esterna chì a tavula cuntene un campu di sistema. $node_id - identificatore unicu di un nodu graficu in a basa di dati.

In listessu modu, i tavulini di u sicondu tipu anu campi di sistema $from_id и $to_id, entrate in tali tavule definiscenu chjaramente e cunnessione trà i nodi. Una tavola separata hè aduprata per almacenà relazioni di ogni tipu.

Illustremu questu cun un esempiu. Chì i dati di u graficu anu un layout cum'è quellu mostratu in a figura. Allora per creà a struttura currispondente in a basa di dati avete bisognu di eseguisce e seguenti dumande 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);

A specificità principale di tali tabelle hè chì in e dumande contru à elli hè pussibule aduprà mudelli di graficu cù sintassi simile à Cypher (in ogni modu, "*"ecc. ùn sò ancu supportati). Basatu nantu à e misurazioni di u rendiment, si pò ancu suppone chì a manera in cui i dati sò almacenati in queste tabelle hè diversu da a manera chì i dati sò almacenati in tavule regulare è hè ottimizzatu per eseguisce tali dumande di graficu.

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

Inoltre, hè abbastanza difficiuli di ùn utilizà sti mudelli di gràficu quandu travaglianu cù tali tavule, postu chì in e dumande SQL ordinali per risolve prublemi simili, serà necessariu di fà sforzi supplementari per ottene identificatori di nodi "graficu" di u sistema ($node_id, $from_id, $to_id; Per u listessu mutivu, e dumande per l'inserimentu di dati ùn sò micca mostrati quì perchè sò inutilmente ingombranti).

Per sintetizà a descrizzione di l'implementazione di u documentu è i mudelli di gràficu in MS SQL Server, aghju nutatu chì tali implementazioni di un mudellu sopra à l'altru ùn pare micca successu, soprattuttu da u puntu di vista di u disignu di lingua. Hè necessariu allargà una lingua cù l'altru, e lingue ùn sò micca cumplettamente "ortogonali", e regule di cumpatibilità ponu esse abbastanza strane.

DBMS multi-mudellu basatu annantu à u mudellu di documentu

In questa sezione, vogliu illustrà l'implementazione di multi-mudellu in DBMS di documentu cù l'esempiu di u più populari di elli, MongoDB (cum'è hè statu dettu, hà solu operatori di gràficu cundizionale). $lookup и $graphLookup, ùn travaglia micca nantu à cullezzione sharded), ma cù l'esempiu di un DBMS più maturu è "impresa" MarkLogic.

Dunque, lasciate chì a cullizzioni cuntene un inseme di documenti XML di u tipu seguente (MarkLogic permette ancu di almacenà documenti JSON):

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

U mudellu relazionale in MarkLogic

Una vista relazionale di una cullizzioni di documenti pò esse creata usendu mudellu di mostra (cuntenutu di elementi value in l'esempiu quì sottu pò esse un XPath arbitrariu):

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

Pudete indirizzà a vista creata cù una dumanda SQL (per esempiu, via ODBC):

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

Sfortunatamente, a vista relazionale creata da u mudellu di visualizazione hè di sola lettura. Quandu prucessa una dumanda per questu, MarkLogic pruverà à aduprà indici di documenti. In precedenza, MarkLogic avia una vista relazionale limitata, interamente basatu in indice è scrivibili, ma avà sò cunsiderate obsoleti.

U mudellu di graficu in MarkLogic

Cù supportu per u mudellu di graficu (RDF), tuttu hè u listessu. Di novu cù l'aiutu mudellu di mostra Pudete creà una rappresentazione RDF di una cullizzioni di documenti da l'esempiu sopra:

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

Pudete indirizzà u graficu RDF resultante cù una query SPARQL:

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

A cuntrariu di u relazionale, MarkLogic sustene u mudellu di gràficu in duie altre manere:

Un DBMS pò esse un almacenamentu separatu cumpletu di dati RDF (triplets in questu seranu chjamati hà sappiutu in cuntrastu à quelli descritti sopra estratti).
RDF in serializazione speciale pò esse simpliciamente inseritu in documenti XML o JSON (è i triplets seranu allora chjamati senza gestione). Questu hè probabilmente una alternativa à i miccanismi idref è altri.

Una bona idea di cumu funziona "veramente" e cose in MarkLogic hè datu da API Optical, in questu sensu, hè di livellu bassu, ancu s'è u so scopu hè piuttostu u cuntrariu - per pruvà à astrazione da u mudellu di dati utilizatu, per assicurà un travagliu coherente cù dati in diversi mudelli, transazzione, etc.

DBMS multi-mudellu "senza un mudellu principale"

Ci sò ancu DBMS nantu à u mercatu chì si ponenu cum'è inizialmente multi-mudellu, senza nisun mudellu principale ereditatu. Questi includenu ArangoDB, OrientDB (dapoi u 2018 a cumpagnia di sviluppu appartene à SAP) è CosmosDB (serviziu cum'è parte di a piattaforma cloud Microsoft Azure).

In fatti, ci sò mudelli "core" in ArangoDB è OrientDB. In i dui casi, questi sò i so mudelli di dati, chì sò generalizazioni di u documentu unu. I generalizazioni sò principarmenti per facilità l'abilità di fà dumande di natura grafica è relazionale.

Questi mudelli sò l'unichi dispunibuli per l'usu in u DBMS specificatu e so propria lingua di dumanda sò pensati per travaglià cun elli. Di sicuru, tali mudelli è DBMS sò promettenti, ma a mancanza di cumpatibilità cù mudelli standard è lingue rende impussibile di utilizà sti DBMS in sistemi legacy - per rimpiazzà i DBMS digià utilizati.

Ci era digià un articulu maravigliu nantu à ArangoDB è OrientDB nantu à Habré: JOIN in basa di dati NoSQL.

ArangoDB

ArangoDB riclama un supportu per un mudellu di dati di graficu.

I nodi di un gràficu in ArangoDB sò documenti ordinali, è i bordi sò documenti di un tipu speciale chì, cù i campi di sistema regulare, anu (_key, _id, _rev) campi di sistema _from и _to. I documenti in i DBMS di documenti sò tradizionalmente cumminati in cullezzione. I cullezzione di documenti chì rapprisentanu i bordi sò chjamati cullezzione di bordu in ArangoDB. In modu, i ducumenti di cullezzione di bordu sò ancu documenti, cusì i bordi in ArangoDB ponu ancu agisce cum'è nodi.

Dati iniziali

Facemu una cullizzioni persons, chì i ducumenti pareanu cusì:

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

Chì ci sia ancu una cullizzioni cafes:

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

Allora a cullezzione likes puderia vede cusì:

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

Quistioni è risultati

Una quistione di stile di graficu in a lingua AQL utilizata in ArangoDB, rinviendu in forma leggibile da l'omu infurmazione nantu à quale piace chì cafe, pare cusì:

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

In un stile relazionale, induve simu "calculate" relazioni piuttostu cà di almacenà, sta dumanda pò esse riscritta cusì (per via, senza a cullizzioni. likes puderia fà senza):

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 }

U risultatu in i dui casi serà u listessu:

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

Più dumande è risultati

Se u furmatu di u risultatu sopra pare esse più tipicu per un DBMS relazionale cà per un DBMS di documentu, pudete pruvà sta dumanda (o pudete aduprà COLLECT):

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

U risultatu sarà cusì:

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

OrientDB

A basa per implementà un mudellu di gràficu nantu à un mudellu di documentu in OrientDB hè uppurtunità campi di documentu, in più di valori scalari più o menu standard, anu ancu valori di tipi cum'è LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. I valori di sti tipi sò ligami o cullezzione di ligami à identificatori di u sistema ducumenti.

L'identificatore di documentu assignatu da u sistema hà un "significatu fisicu", chì indica a pusizione di u registru in a basa di dati, è pare cusì cusì: @rid : #3:16. Cusì, i valori di e pruprietà di riferimentu sò veramente puntatori (cum'è in u mudellu di graficu) piuttostu cà e cundizioni di selezzione (cum'è in u mudellu relazionale).

Cum'è ArangoDB, i bordi in OrientDB sò rapprisentati cum'è documenti separati (ancu se un bordu ùn hà micca e so proprietà, pò esse fattu. ligeru, è ùn currisponde micca à un documentu separatu).

Dati iniziali

In un formatu vicinu à furmatu di dump A basa di dati OrientDB, i dati da l'esempiu precedente per ArangoDB pareranu cusì cusì:

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

Comu pudemu vede, i vertici anu ancu almacenatu infurmazioni nantu à i bordi entranti è in uscita. À aduprendu L'API Document hà da monitorà l'integrità referenziale stessu, è l'API Graph assume stu travagliu. Ma vedemu ciò chì pare l'accessu à OrientDB in lingue di ricerca "pure" chì ùn sò micca integrate in lingue di prugrammazione.

Quistioni è risultati

Una dumanda simile in u scopu à a dumanda da l'esempiu per ArangoDB in OrientDB pare cusì:

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

U risultatu serà ottenutu in a forma seguente:

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

Sè u furmatu di u risultatu pari torna troppu "relazionale", vi tocca à caccià a linea cù UNWIND():

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

A lingua di quistione di OrientDB pò esse descritta cum'è SQL cù inserti simili à Gremlin. In a versione 2.2, hè apparsu una forma di dumanda cum'è 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

U furmatu di u risultatu serà u listessu cum'è in a dumanda precedente. Pensate à ciò chì deve esse eliminatu per fà più "relazionale", cum'è in a prima dumanda.

Azure CosmosDB

À un puntu più minimu, ciò chì hè dettu sopra à ArangoDB è OrientDB s'applica à Azure CosmosDB. CosmosDB furnisce i seguenti API d'accessu di dati: SQL, MongoDB, Gremlin è Cassandra.

SQL API è MongoDB API sò usati per accede à e dati in u mudellu di documentu. Gremlin API è Cassandra API - per accede à e dati in formati di graficu è di colonna, rispettivamente. I dati in tutti i mudelli sò salvati in u furmatu di u mudellu internu CosmosDB: ARS ("atom-record-sequence"), chì hè ancu vicinu à u documentu unu.

Ma u mudellu di dati sceltu da l'utilizatore è l'API utilizata sò fissi à u mumentu di creà un contu in u serviziu. Ùn hè micca pussibule di accede à e dati caricati in un mudellu in u formatu di un altru mudellu, cum'è illustratu da qualcosa cum'è questu:

Cusì, multi-mudellu in Azure CosmosDB oghje hè solu l'abilità di utilizà parechje basa di dati chì supportanu mudelli diffirenti da un fabricatore, chì ùn risolve micca tutti i prublemi di almacenamiento multi-variante.

DBMS multi-mudellu basatu annantu à un mudellu graficu?

Da nutà hè u fattu chì ùn ci hè micca un DBMS multi-mudellu nantu à u mercatu, ma chì sò basati nantu à un mudellu di graficu (eccettu u supportu multi-mudellu per simultaneamente dui mudelli di graficu: RDF è LPG; vede questu in pubblicazione precedente). I più grandi difficultà sò causati da l'implementazione di un mudellu di documentu nantu à un mudellu di gràficu, piuttostu cà un relazionale.

A quistione di cumu implementà un mudellu relazionale nantu à u mudellu di gràficu hè stata cunsiderata ancu durante a furmazione di l'ultimi. Cumu parlavaper esempiu David McGovern:

Ùn ci hè nunda inerente in l'approcciu di u graficu chì impedisce a creazione di una strata (per esempiu, per l'indicizzamentu adattatu) nantu à una basa di dati di graficu chì permette una vista relazionale cù (1) ricuperazione di tuple da i soliti coppie di valori chjave è (2) raggruppamenti di tuple per tipu di relazione.

Quandu implementate un mudellu di documentu nantu à un mudellu di graficu, avete bisognu di mantene in mente, per esempiu, i seguenti:

Elementi di un array JSON sò cunsiderati urdinati, ma quelli chì emananu da u vertice di un bordu di u graficu ùn sò micca;
I dati in u mudellu di documentu sò generalmente denormalizati, ùn vulete micca almacenà parechje copie di u stessu documentu incrustatu, è i sottodocumenti ùn anu micca identificatori;
Per d 'altra banda, l'ideulugia di i DBMS di documentu hè chì i ducumenti sò "agregati" pronti chì ùn anu micca bisognu di esse custruitu ogni volta. Hè necessariu di furnisce u mudellu di gràficu cù a capacità di ottene rapidamente un subgrafu chì currisponde à u documentu finitu.

Un pocu di publicità

L'autore di l'articulu hè in relazione cù u sviluppu di u DBMS NitrosBase, u mudellu internu di quale hè graficu, è i mudelli esterni - relazionale è documentu - sò i so rapprisintazioni. Tutti i mudelli sò uguali: quasi tutti i dati sò dispunibuli in qualsiasi di elli utilizendu una lingua di quistione chì hè naturali per ellu. Inoltre, in ogni vista, i dati ponu esse cambiati. I cambiamenti seranu riflessi in u mudellu internu è, per quessa, in altri punti di vista.

Spergu di spiegà ciò chì currisponde à u mudellu in NitrosBase in unu di l'articuli seguenti.

cunchiusioni

Spergu chì i contorni generali di ciò chì hè chjamatu multi-modelu sò diventati più o menu chjaru à u lettore. I DBMS multi-mudelli sò assai diffirenti, è u "supportu multi-mudellu" pò vede diverse. Per capisce ciò chì hè chjamatu "multi-mudellu" in ogni casu specificu, hè utile per risponde à e seguenti dumande:

Parlemu di sustegnu mudelli tradiziunali o di qualchì tipu di mudellu "ibridu"?
Sò i mudelli "uguali", o hè unu di elli u sughjettu di l'altri?
Sò i mudelli "indifferenti" à l'altri? E dati scritti in un mudellu ponu esse letti in un altru o ancu sovrascritti?

Pensu chì a quistione nantu à a pertinenza di DBMS multi-mudellu pò esse digià rispostu positivamenti, ma a quistione interessante hè chì tippi di elli seranu più dumandati in un futuru vicinu. Sembra chì i DBMS multi-mudelli chì sustenenu mudelli tradiziunali, principarmenti relazionali, seranu in più dumanda; A pupularità di DBMS multi-mudellu, chì offre novi mudelli chì combina i vantaghji di parechji tradiziunali, hè una materia di u futuru più distante.

Solu l'utilizatori registrati ponu participà à l'indagine. Firmà lu, per piacè.

Aduprate DBMS multi-mudellu?

Ùn avemu micca aduprà, guardamu tuttu in un DBMS è in un mudellu
Avemu aduprà capacità multi-mudellu di DBMS tradiziunali
Pratichemu a persistenza poliglotta
Utilizemu un novu DBMS multi-mudellu (Arango, Orient, CosmosDB)

19 utilizatori anu vutatu. 4 utilizatori si sò astenuti.

Source: www.habr.com

DBMS multi-mudellu - a basa di i sistemi d'infurmazione muderni?