I moderni sistemi informativi sono piuttosto complessi. La loro complessità è dovuta non ultimo alla complessità dei dati in essi trattati. La complessità dei dati spesso risiede nella varietà dei modelli di dati utilizzati. Quindi, ad esempio, quando i dati diventano “grandi”, una delle caratteristiche problematiche non è solo il loro volume (“volume”), ma anche la loro varietà (“variety”).
Se non trovi ancora un difetto nel ragionamento, continua a leggere.
contenuto
Persistenza poliglotta
Quanto sopra porta al fatto che a volte anche nell'ambito di un sistema è necessario utilizzare diversi DBMS diversi per archiviare i dati e risolvere vari problemi di elaborazione, ognuno dei quali supporta il proprio modello di dati. Con la mano leggera di M. Fowler, una serie di libri famosi e uno di Manifesto Agile, si chiama questa situazione archiviazione multivariante (“persistenza poliglotta”).
Fowler fornisce anche il seguente esempio di organizzazione dell'archiviazione dei dati in un'applicazione completa e ad alto carico nel campo dell'e-commerce.
Questo esempio, ovviamente, è un po' esagerato, ma si possono trovare alcune considerazioni a favore della scelta dell'uno o dell'altro DBMS per lo scopo corrispondente, ad esempio: .
È chiaro che essere servitore in uno zoo del genere non è facile.
- La quantità di codice che esegue l'archiviazione dei dati cresce in proporzione al numero di DBMS utilizzati; la quantità di dati di sincronizzazione del codice è buona se non proporzionale al quadrato di questo numero.
- Come multiplo del numero di DBMS utilizzati, aumentano i costi per fornire caratteristiche aziendali (scalabilità, tolleranza agli errori, elevata disponibilità) di ciascuno dei DBMS utilizzati.
- È impossibile garantire le caratteristiche aziendali del sottosistema di storage nel suo complesso, in particolare la transazionalità.
Dal punto di vista del direttore dello zoo, tutto assomiglia a questo:
- Un aumento multiplo del costo delle licenze e del supporto tecnico da parte del produttore del DBMS.
- Personale in eccesso e scadenze più lunghe.
- Perdite finanziarie dirette o sanzioni dovute all'incoerenza dei dati.
Si verifica un aumento significativo del costo totale di proprietà (TCO) del sistema. Esiste una via d'uscita dalla situazione di "opzioni di archiviazione multiple"?
Multimodello
Il termine “archiviazione multivariata” è entrato in uso nel 2011. La consapevolezza dei problemi dell'approccio e la ricerca di una soluzione hanno richiesto diversi anni e nel 2015, per bocca degli analisti di Gartner, è stata formulata la risposta:
- A partire dal ""
Il futuro dei DBMS, delle loro architetture e delle modalità di utilizzo è multimodello.
- A partire dal ""
I principali DBMS operativi offriranno più modelli, relazionali e non relazionali, come parte di un'unica piattaforma.
Sembra che questa volta gli analisti di Gartner avessero ragione con le loro previsioni. Se vai alla pagina con DBMS su DB-Engines, puoi vederloоLa maggior parte dei suoi leader si posiziona specificamente come DBMS multi-modello. Lo stesso può essere visto sulla pagina con qualsiasi valutazione privata.
La tabella seguente mostra i DBMS, i leader in ciascuno dei rating privati, che affermano di essere multi-modello. Per ogni DBMS viene indicato il modello originariamente supportato (che un tempo era l'unico) e insieme ad esso i modelli attualmente supportati. Sono elencati anche i DBMS che si posizionano come “originariamente multi-modello” e, secondo i creatori, non hanno alcun modello iniziale ereditato.
| DBMS | Modello iniziale | Modelli aggiuntivi |
|---|---|---|
| Oracle | Relazionale | Grafico, documento |
| MS SQL | Relazionale | Grafico, documento |
| PostgreSQL | Relazionale | Grafico*, documento |
| Mark Logic | Documentario | Grafico, relazionale |
| MongoDB | Documentario | Valore-chiave, grafico* |
| DataStax | Ampia colonna | Documentario, grafico |
| Redis | Valore-chiave | Documentario, grafico* |
| Arango DB | - | Grafico, documento |
| OrienteDB | - | Grafico, documento, relazionale |
| Azure CosmosDB | - | Grafico, documento, relazionale |
Note al tavolo
Gli asterischi nella tabella contrassegnano le affermazioni che richiedono riserve:
- Il DBMS PostgreSQL non supporta il modello dati grafico, ma questo prodotto lo supporta , come AgensGraph.
- In relazione a MongoDB è più corretto parlare della presenza di operatori grafici nel linguaggio di query (, ) che sul supporto del modello grafico, anche se, ovviamente, la loro introduzione ha richiesto alcune ottimizzazioni a livello di archiviazione fisica nella direzione del supporto del modello grafico.
- In relazione a Redis, intendiamo l'estensione .
Successivamente, per ciascuna classe, mostreremo come viene implementato il supporto per diversi modelli nel DBMS di questa classe. Considereremo i modelli relazionali, documentali e grafici come i più importanti e utilizzeremo esempi di DBMS specifici per mostrare come vengono implementati quelli “mancanti”.
DBMS multimodello basato sul modello relazionale
I principali DBMS attualmente sono relazionali; la previsione di Gartner non potrebbe essere considerata vera se gli RDBMS non mostrassero un movimento nella direzione del multi-modeling. E lo dimostrano. Ora l'idea che un DBMS multi-modello sia come un coltellino svizzero, che non può fare nulla di buono, può essere indirizzata direttamente a Larry Ellison.
L'autore, tuttavia, preferisce l'implementazione del multi-modeling in Microsoft SQL Server, sull'esempio del quale verrà descritto il supporto RDBMS per modelli di documenti e grafici.
Modello di documento in MS SQL Server
Sono già stati pubblicati due ottimi articoli su Habré su come MS SQL Server implementa il supporto per il modello di documento; mi limiterò a una breve rivisitazione e commento:
Il modo di supportare il modello di documento in MS SQL Server è abbastanza tipico per i DBMS relazionali: si propone che i documenti JSON siano archiviati in normali campi di testo. Il supporto per il modello di documento consiste nel fornire operatori speciali per analizzare questo JSON:
- per estrarre valori di attributi scalari,
- per estrarre i sotto-documenti.
Il secondo argomento di entrambi gli operatori è un'espressione con sintassi simile a JSONPath.
In astratto, possiamo dire che i documenti archiviati in questo modo non sono “entità di prima classe” in un DBMS relazionale, a differenza delle tuple. Nello specifico, in MS SQL Server non sono attualmente presenti indici sui campi dei documenti JSON, il che rende difficile unire le tabelle utilizzando i valori di questi campi e persino selezionare i documenti utilizzando questi valori. Tuttavia, è possibile creare una colonna calcolata per tale campo e un indice su di essa.
Inoltre, MS SQL Server offre la possibilità di costruire comodamente un documento JSON dal contenuto delle tabelle utilizzando l'operatore - una possibilità, in un certo senso, opposta alla precedente, di stoccaggio convenzionale. È chiaro che non importa quanto sia veloce un RDBMS, questo approccio contraddice l'ideologia dei DBMS documentali, che essenzialmente memorizzano risposte già pronte a domande popolari e possono risolvere solo problemi di facilità di sviluppo, ma non di velocità.
Infine, MS SQL Server ti consente di risolvere il problema opposto della costruzione del documento: puoi scomporre JSON in tabelle utilizzando . Se il documento non è completamente piatto, sarà necessario utilizzarlo CROSS APPLY.
Modello grafico in MS SQL Server
Il supporto per il modello grafico (LPG) è completamente implementato anche in Microsoft SQL Server : Si propone di utilizzare tabelle speciali per memorizzare i nodi e per memorizzare gli spigoli del grafico. Tali tabelle vengono create utilizzando le espressioni CREATE TABLE AS NODE и CREATE TABLE AS EDGE rispettivamente.
Le tabelle del primo tipo sono simili alle normali tabelle per l'archiviazione dei record, con l'unica differenza esterna che la tabella contiene un campo di sistema $node_id — identificatore univoco di un nodo grafico all'interno del database.
Allo stesso modo, le tabelle del secondo tipo hanno campi di sistema $from_id и $to_id, le voci in tali tabelle definiscono chiaramente le connessioni tra i nodi. Viene utilizzata una tabella separata per archiviare le relazioni di ciascun tipo.
Illustriamolo con un esempio. Lascia che i dati del grafico abbiano un layout come quello mostrato in figura. Quindi per creare la struttura corrispondente nel database è necessario eseguire le seguenti query 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);La principale specificità di tali tabelle è che nelle query su di esse è possibile utilizzare modelli grafici con sintassi simile a Cypher (tuttavia, "*"ecc. non sono ancora supportati). Sulla base delle misurazioni delle prestazioni, si può anche presumere che il modo in cui i dati vengono archiviati in queste tabelle è diverso dal modo in cui i dati vengono archiviati nelle tabelle normali e è ottimizzato per l'esecuzione di tali query sui grafici.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Inoltre, è abbastanza difficile non utilizzare questi modelli grafici quando si lavora con tali tabelle, poiché nelle normali query SQL per risolvere problemi simili sarà necessario compiere ulteriori sforzi per ottenere identificatori dei nodi “grafici” del sistema ($node_id, $from_id, $to_id; Per lo stesso motivo le interrogazioni per l'inserimento dei dati non vengono qui riportate in quanto inutilmente macchinose).
Per riassumere la descrizione delle implementazioni dei modelli di documento e grafico in MS SQL Server, vorrei notare che tali implementazioni di un modello sopra un altro non sembrano avere successo, principalmente dal punto di vista della progettazione del linguaggio. È necessario estendere una lingua con un’altra, le lingue non sono del tutto “ortogonali”, le regole di compatibilità possono essere piuttosto bizzarre.
DBMS multimodello basato sul modello documentale
In questa sezione, vorrei illustrare l'implementazione di DBMS multimodello in documenti utilizzando l'esempio del non più popolare di essi, MongoDB (come è stato detto, ha solo operatori grafici condizionali $lookup и $graphLookup, non lavorando su raccolte frammentate), ma utilizzando l'esempio di un DBMS più maturo ed “enterprise”. .
Quindi, lascia che la raccolta contenga una serie di documenti XML del seguente tipo (MarkLogic ti consente anche di archiviare documenti JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Modello relazionale in MarkLogic
È possibile creare una vista relazionale di una raccolta di documenti utilizzando (contenuto degli elementi value nell'esempio seguente può esserci un XPath arbitrario):
<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>È possibile indirizzare la vista creata con una query SQL (ad esempio tramite ODBC):
SELECT name, surname FROM Person WHERE name="John"Sfortunatamente, la vista relazionale creata dal modello di visualizzazione è di sola lettura. Durante l'elaborazione di una richiesta, MarkLogic tenterà di utilizzare . In precedenza, MarkLogic aveva visioni relazionali del tutto limitate e scrivibili, ma ora sono considerati deprecati.
Modello grafico in MarkLogic
Con il supporto per il modello grafico (RDF), tutto è più o meno lo stesso. Ancora una volta con l'aiuto puoi creare una rappresentazione RDF di una raccolta di documenti dall'esempio 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>Puoi indirizzare il grafico RDF risultante con una query SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}A differenza di quello relazionale, MarkLogic supporta il modello a grafico in altri due modi:
- Un DBMS può essere un archivio separato a tutti gli effetti di dati RDF (le triplette in esso contenute verranno chiamate a differenza di quelli sopra descritti ).
- RDF con serializzazione speciale può essere semplicemente inserito in documenti XML o JSON (e le triplette verranno quindi chiamate ). Questa è probabilmente un'alternativa ai meccanismi
idrefeccetera
Una buona idea di come funzionano “realmente” le cose in MarkLogic è data da , in questo senso, è di basso livello, sebbene il suo scopo sia piuttosto l'opposto: cercare di astrarre dal modello di dati utilizzato, per garantire un lavoro coerente con i dati in diversi modelli, transazionalità, ecc.
DBMS multimodello “senza modello principale”
Sul mercato esistono anche DBMS che si posizionano inizialmente come multi-modello, senza alcun modello principale ereditato. Questi includono , (dal 2018 la società di sviluppo appartiene a SAP) e (servizio nell'ambito della piattaforma cloud Microsoft Azure).
In effetti, ci sono modelli “core” in ArangoDB e OrientDB. In entrambi i casi, si tratta di modelli di dati propri, che sono generalizzazioni di quello del documento. Le generalizzazioni servono principalmente a facilitare la capacità di eseguire query di natura grafica e relazionale.
Questi modelli sono gli unici disponibili per l'uso nel DBMS specificato; i loro linguaggi di query sono progettati per funzionare con essi. Naturalmente, tali modelli e DBMS sono promettenti, ma la mancanza di compatibilità con modelli e linguaggi standard rende impossibile l’utilizzo di questi DBMS nei sistemi legacy, per sostituire i DBMS già utilizzati lì.
C'era già un bellissimo articolo su ArangoDB e OrientDB su Habré: .
Arango DB
ArangoDB rivendica il supporto per un modello di dati grafici.
I nodi di un grafico in ArangoDB sono documenti ordinari e gli spigoli sono documenti di tipo speciale che, insieme ai normali campi di sistema, hanno (_key, _id, _rev) campi del sistema _from и _to. I documenti nei DBMS documentali sono tradizionalmente combinati in raccolte. Le raccolte di documenti che rappresentano i bordi sono chiamate raccolte di bordi in ArangoDB. A proposito, anche i documenti della raccolta edge sono documenti, quindi gli edge in ArangoDB possono anche fungere da nodi.
Dati iniziali
Facciamo una raccolta persons, i cui documenti si presentano così:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Facciamo anche una colletta cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Poi la raccolta likes potrebbe assomigliare a questo:
[
{
"_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
}
]Domande e risultati
Una query in stile grafico nel linguaggio AQL utilizzato in ArangoDB, che restituisce in forma leggibile informazioni su chi preferisce quale bar, assomiglia a questa:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }In uno stile relazionale, dove stiamo “calcolando” le relazioni invece di memorizzarle, questa query può essere riscritta in questo modo (a proposito, senza la raccolta likes potrebbe farne a meno):
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 }Il risultato in entrambi i casi sarà lo stesso:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Altre query e risultati
Se il formato dei risultati sopra sembra essere più tipico per un DBMS relazionale che per un DBMS di documenti, puoi provare questa query (oppure puoi usare ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Il risultato sarà simile a questo:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrienteDB
La base per implementare un modello grafico sopra un modello di documento in OrientDB è i campi del documento, oltre a valori scalari più o meno standard, hanno anche valori di tipo come LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. I valori di questi tipi sono collegamenti o raccolte di collegamenti a documenti.
L'identificativo del documento assegnato dal sistema ha un “significato fisico”, che indica la posizione del record nel database, ed è simile a questo: @rid : #3:16. Pertanto, i valori delle proprietà di riferimento sono in realtà puntatori (come nel modello grafico) piuttosto che condizioni di selezione (come nel modello relazionale).
Come ArangoDB, i bordi in OrientDB sono rappresentati come documenti separati (sebbene se un bordo non ha proprietà proprie, può essere reso , e non corrisponderà ad un documento separato).
Dati iniziali
In un formato vicino a OrientDB, i dati dell'esempio precedente per ArangoDB sarebbero simili a questi:
[
{
"@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"
}
]Come possiamo vedere, i vertici memorizzano anche informazioni sui bordi entranti e uscenti. A L'API Document deve monitorare l'integrità referenziale stessa e l'API Graph si assume questo lavoro. Ma vediamo come si presenta l’accesso a OrientDB nei linguaggi di query “puri” non integrati nei linguaggi di programmazione.
Domande e risultati
Una query simile nello scopo alla query dell'esempio per ArangoDB in OrientDB si presenta così:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameIl risultato sarà ottenuto nella seguente forma:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Se il formato del risultato sembra ancora una volta troppo “relazionale”, è necessario rimuovere la riga con :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Il linguaggio di query di OrientDB può essere descritto come SQL con inserti simili a Gremlin. Nella versione 2.2 appariva un modulo di richiesta simile a Cypher, :
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_nameIl formato del risultato sarà lo stesso della richiesta precedente. Pensa a cosa deve essere rimosso per renderlo più “relazionale”, come nella primissima query.
Azure CosmosDB
In misura minore, quanto detto sopra per ArangoDB e OrientDB vale per Azure CosmosDB. CosmosDB fornisce le seguenti API di accesso ai dati: SQL, MongoDB, Gremlin e Cassandra.
L'API SQL e l'API MongoDB vengono utilizzate per accedere ai dati nel modello di documento. API Gremlin e API Cassandra: per accedere rispettivamente ai dati nei formati grafico e colonna. I dati in tutti i modelli vengono salvati nel formato del modello interno CosmosDB: (“sequenza-record-atomo”), che è anch'essa vicina a quella del documento.
Ma il modello dati scelto dall'utente e l'API utilizzata vengono fissati al momento della creazione di un account nel servizio. Non è possibile accedere ai dati caricati in un modello nel formato di un altro modello, come illustrato da qualcosa di simile:
Pertanto, il multimodello in Azure CosmosDB oggi significa solo la possibilità di utilizzare diversi database che supportano modelli diversi di un produttore, il che non risolve tutti i problemi dell'archiviazione multivariante.
DBMS multimodello basato su un modello grafico?
Degno di nota è il fatto che non esistono ancora DBMS multi-modello sul mercato basati su un modello grafico (ad eccezione del supporto multi-modello per due modelli grafici contemporaneamente: RDF e LPG; vedere questo in ). Le maggiori difficoltà sono causate dall'implementazione di un modello documentale sopra un modello grafico, piuttosto che relazionale.
La questione di come implementare un modello relazionale sopra il modello grafico è stata considerata anche durante la formazione di quest'ultimo. Come Ad esempio, :
Non c'è nulla di inerente all'approccio grafico che impedisca la creazione di uno strato (ad esempio, mediante un'adeguata indicizzazione) su un database a grafo che consenta una vista relazionale con (1) recupero di tuple dalle solite coppie chiave-valore e (2) raggruppamento di tuple per tipo di relazione.
Quando si implementa un modello di documento sopra un modello grafico, è necessario tenere presente, ad esempio, quanto segue:
- Gli elementi di un array JSON sono considerati ordinati, ma quelli provenienti dal vertice di un bordo del grafico non lo sono;
- I dati nel modello di documento sono solitamente denormalizzati; non si desidera comunque archiviare più copie dello stesso documento incorporato e i documenti secondari di solito non hanno identificatori;
- D'altra parte, l'ideologia dei DBMS documentali è che i documenti sono "aggregati" già pronti che non necessitano di essere ricostruiti ogni volta. È necessario fornire al modello grafico la possibilità di ottenere rapidamente un sottografo corrispondente al documento finito.
Qualche pubblicità
L'autore dell'articolo è legato allo sviluppo del DBMS NitrosBase, il cui modello interno è grafico, e i modelli esterni - relazionali e documentali - sono le sue rappresentazioni. Tutti i modelli sono uguali: quasi tutti i dati sono disponibili in ognuno di essi utilizzando un linguaggio di query che gli è naturale. Inoltre, in qualsiasi vista, i dati possono essere modificati. Le modifiche si rifletteranno nel modello interno e, di conseguenza, in altre visualizzazioni.
Spero di descrivere come appare la corrispondenza dei modelli in NitrosBase in uno dei seguenti articoli.
conclusione
Spero che le linee generali di ciò che viene chiamato multi-modeling siano diventate più o meno chiare al lettore. I DBMS multimodello sono piuttosto diversi e il "supporto multimodello" può apparire diverso. Per comprendere cosa viene chiamato “multi-modello” in ogni caso specifico, è utile rispondere alle seguenti domande:
- Stiamo parlando di sostenere modelli tradizionali o una sorta di modello “ibrido”?
- I modelli sono “uguali” oppure uno di essi è soggetto degli altri?
- I modelli sono “indifferenti” tra loro? I dati scritti in un modello possono essere letti in un altro o addirittura sovrascritti?
Penso che alla domanda sulla rilevanza dei DBMS multi-modello si possa già rispondere positivamente, ma la domanda interessante è quali tipi di essi saranno più richiesti nel prossimo futuro. Sembra che i DBMS multimodello che supportano i modelli tradizionali, principalmente relazionali, saranno maggiormente richiesti; La popolarità dei DBMS multi-modello, che offrono nuovi modelli che combinano i vantaggi di vari modelli tradizionali, è una questione di un futuro più lontano.
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Utilizzi DBMS multimodello?
Non lo usiamo, memorizziamo tutto in un DBMS e in un modello
Utilizziamo le funzionalità multi-modello dei DBMS tradizionali
Pratichiamo la persistenza poliglotta
Utilizziamo nuovi DBMS multi-modello (Arango, Orient, CosmosDB)
19 utenti hanno votato. 4 utenti si sono astenuti.
Fonte: habr.com
