I moderni sistemi informativi sono abbastanza complessi. Non ultima, la loro complessità è determinata dalla complessità dei dati elaborati. La complessità di questi dati spesso risiede nella varietà dei modelli di dati utilizzati. Ad esempio, quando i dati diventano "grandi", una delle caratteristiche che creano disagio è non solo il loro volume, ma anche la loro diversità.
Se non trovi ancora difetti nelle argomentazioni, continua a leggere.
Contenuto
Persistenza poliglotta
Quanto detto sopra porta al fatto che talvolta, all'interno anche di un solo sistema, è necessario utilizzare diverse DBMS per la memorizzazione dei dati e per risolvere vari compiti di elaborazione dei dati, ognuno dei quali supporta il proprio modello di dati. Per impulso di M. Fowler, di alcuni libri noti e uno dei dell'Agile Manifesto, questa situazione è stata definita memorizzazione polimodale ("polyglot persistence").
A Fowler appartiene anche il seguente esempio di organizzazione della memorizzazione dei dati in un'applicazione ad alte prestazioni e pienamente funzionale nel campo dell'e-commerce.
Questo esempio è ovviamente un po' esagerato, ma alcune considerazioni a favore della scelta di un determinato DBMS per uno scopo specifico si possono trovare, ad esempio, .
È chiaro che essere un custode in uno zoo del genere non è facile.
- Il volume del codice che esegue la memorizzazione dei dati cresce proporzionalmente al numero di DBMS utilizzati; il volume del codice che sincronizza i dati — sarebbe già un bene se non crescera proporzionalmente al quadrato di quel numero.
- La spesa per garantire le caratteristiche enterprise (scalabilità, resilienza, alta disponibilità) di ciascun DBMS utilizzato cresce in modo esponenziale rispetto al numero di DBMS utilizzati.
- Non è possibile garantire le caratteristiche enterprise di un sottosistema di memorizzazione in generale — soprattutto la transazionalità.
Dal punto di vista del direttore dello zoo, tutto appare così:
- L'aumento esponenziale del costo delle licenze e del supporto tecnico da parte del produttore del DBMS.
- Espansione del personale e prolungamento dei tempi.
- Perdite finanziarie dirette o sanzioni a causa della disallineamento dei dati.
C'è un significativo aumento del costo totale di possesso del sistema (TCO). Esiste una soluzione alla situazione del "multi-storage"?
Multimodalità
Il termine "multi-storage" è entrato in uso nel 2011. La consapevolezza dei problemi dell'approccio e la ricerca di una soluzione hanno richiesto diversi anni, e nel 2015 gli analisti di Gartner hanno formulato una risposta:
- Da "»:
Il futuro dei DBMS, delle loro architetture e dei metodi di utilizzo è la multiodo.
- Da "»:
Le principali DBMS operative offriranno diversi modelli — relazionale e non relazionali — all'interno di una piattaforma unificata.
Sembra che questa volta gli analisti di Gartner non si siano sbagliati nel loro pronostico. Se si visita la pagina con dei DBMS su DB-Engines, si può notare che launmaggior parte dei leader si posiziona esattamente come DBMS multiodo. Lo stesso può essere visto anche nella pagina con qualsiasi classifica specifica.
Nella tabella qui sotto sono elencati i DBMS leader in ciascuna delle classifiche specifiche, che dichiarano la loro multiodo. Per ogni DBMS viene indicato il modello inizialmente supportato (un tempo l'unico) e insieme ad esso i modelli attualmente supportati. Sono inclusi anche i DBMS che si posizionano come "inizialmente multiodo", che non hanno dichiarato alcun modello ereditato inizialmente.
| DBMS | Modello iniziale | Modelli aggiuntivi |
|---|---|---|
| Oracle | Relazionale | Grafico, documentale |
| MS SQL | Relazionale | Grafico, documentale |
| PostgreSQL | Relazionale | Grafico*, documentale |
| MarkLogic | Documentale | Grafico, relazionale |
| MongoDB | Documentale | Chiave-valore, grafico* |
| DataStax | Wide-column | Documentale, grafico |
| Redis | Chiave-valore | Documentale, grafico* |
| ArangoDB | — | Grafico, documentale |
| OrientDB | — | Grafico, documentale, relazionale |
| Azure CosmosDB | — | Grafico, documentale, relazionale |
Note alla tabella
Le affermazioni contrassegnate con asterischi nella tabella richiedono precisazioni:
- Il DBMS PostgreSQL non supporta il modello dati grafico, ma un prodotto , come AgensGraph, lo supporta.
- Riguardo a MongoDB, è più corretto parlare della presenza di operatori grafici nel linguaggio di query (, ), riguardo al supporto del modello a grafo, sebbene, naturalmente, la loro introduzione abbia richiesto alcune ottimizzazioni a livello di memorizzazione fisica in direzione del supporto del modello a grafo.
- In riferimento a Redis si intende un'estensione .
Successivamente, per ciascuna delle classi mostreremo come viene implementato il supporto per diversi modelli nei DBMS di questa classe. Considereremo i modelli relazionale, documentale e a grafo come i più importanti e mostreremo con esempi di specifici DBMS come vengono implementate le 'carenze'.
Database multimodali basati sul modello relazionale
I DBMS principali al momento sono relazionali; la previsione di Gartner non sarebbe stata realizzata se i RDBMS non mostrassero progressi verso la multimodalità. E la mostrano. Ora le considerazioni sul fatto che un DBMS multimodale sia simile a un coltellino svizzero, che non può fare nulla bene, possono essere immediatamente dirette a Larry Ellison.
Tuttavia, all'autore piace di più l'implementazione della multimaloralità in Microsoft SQL Server, sul quale sarà descritta la supporto per i RDBMS dei modelli documentale e a grafo.
Modello documentale in MS SQL Server
Su come sia implementato il supporto per il modello documentale in MS SQL Server, su Habr ci sono già stati due ottimi articoli, mi limiterò a una breve sintesi e a un commento:
Il modo in cui MS SQL Server supporta il modello documentale è abbastanza tipico per i DBMS relazionali: i documenti JSON vengono proposti per essere memorizzati in normali campi di testo. Il supporto per il modello documentale consiste nella fornitura di operatori speciali per l'analisi di questo JSON:
- per estrarre valori scalari degli attributi,
- per estrarre sottodocumenti.
Il secondo argomento di entrambi gli operatori è un'espressione in una sintassi simile a JSONPath.
In astratto, si può dire che i documenti memorizzati in questo modo non sono 'entità di primo livello' in un DBMS relazionale, a differenza delle tuple. In particolare, in MS SQL Server attualmente non ci sono indici sui campi dei documenti JSON, il che rende difficoltose le operazioni di join tra tabelle in base ai valori di questi campi e persino il recupero di documenti in base a questi valori. Tuttavia, è possibile creare una colonna calcolata su un campo del genere e un indice su di essa.
In aggiunta, MS SQL Server offre la possibilità di costruire comodamente un documento JSON dal contenuto delle tabelle con l'operatore — una possibilità, in un certo senso opposta a quella precedente, della memorizzazione tradizionale. È chiaro che, per quanto possa essere veloce un RDBMS, questo approccio contraddice l'ideologia dei document database, che in sostanza memorizzano risposte pronte a query popolari, e può risolvere solo problemi di praticità nello sviluppo, ma non di efficienza.
Infine, MS SQL Server consente di affrontare il compito opposto alla costruzione di un documento: è possibile decomporre JSON in tabelle tramite . Se il documento non è completamente piatto, sarà necessario utilizzare CROSS APPLY.
Modello grafico in MS SQL Server
Il supporto per il modello grafico (LPG) è implementato in Microsoft SQL Server in modo altrettanto : si consiglia di utilizzare tabelle speciali per memorizzare i nodi e per memorizzare gli archi del grafo. Tali tabelle vengono create utilizzando le espressioni CREATE TABLE AS NODE e CREATE TABLE AS EDGE rispettivamente.
Le tabelle del primo tipo sono simili a tabelle ordinarie per la memorizzazione di record, con l'unica differenza esterna che nella tabella è presente un campo di sistema $node_id — identificatore unico all'interno del database del nodo del grafo.
Analogamente, le tabelle del secondo tipo hanno campi di sistema $from_id e $to_id, le registrazioni in tali tabelle definiscono in modo chiaro le relazioni tra i nodi. Per memorizzare relazioni di ciascun tipo si utilizza una tabella separata.
Illustriamo quanto detto con un esempio. Supponiamo che i dati grafici abbiano uno schema come quello mostrato nell'immagine fornita. 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 specificità principale di tali tabelle è che nelle query è possibile utilizzare schemi grafici con sintassi simile a Cypher (peraltro, «*» e simili non sono ancora supportati). Sulla base delle misurazioni delle prestazioni, si può anche supporre che il modo in cui i dati sono memorizzati in queste tabelle sia diverso dal meccanismo di memorizzazione in tabelle ordinarie e ottimizzato per l'esecuzione di tali query grafiche.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Inoltre, è piuttosto difficile non utilizzare questi schemi grafici lavorando con tali tabelle, poiché nelle normali query SQL per risolvere compiti analoghi saranno necessari sforzi aggiuntivi per ottenere identificatori di nodo "grafici" di sistema ($node_id, $from_id, $to_id; per lo stesso motivo, le query di inserimento dati non sono state incluse qui poiché eccessivamente ingombranti).
Riassumendo la descrizione delle implementazioni dei modelli documentale e grafico in MS SQL Server, vorrei sottolineare che tali implementazioni di un modello sopra un altro non sembrano riuscite principalmente dal punto di vista del design linguistico. È necessario estendere un linguaggio con un altro, i linguaggi non sono completamente "ortogonali", le regole di combinazione possono essere piuttosto bizzarre.
Database multimodali basati sul modello documentale
In questa sezione desidero illustrare l'implementazione della multimodalità nei database documentali prendendo come esempio uno dei meno popolari, MongoDB (come già detto, contiene solo operatori grafici condizionali $lookup e $graphLookup, non funzionanti su raccolte shardate), ma piuttosto un database più maturo e "enterprise". .
Pertanto, supponiamo che la collezione contenga un insieme di documenti XML del seguente tipo (MarkLogic consente anche di memorizzare documenti JSON):
John
SmithModello relazionale in MarkLogic
La rappresentazione relazionale della collezione di documenti può essere creata usando (il contenuto degli elementi value nell'esempio seguente può essere qualsiasi XPath):
/Person
Person
SSN
@SSN
string
name
name
surname
surnameÈ possibile indirizzare una query SQL alla vista creata (ad esempio, tramite ODBC):
SELECT name, surname FROM Person WHERE name="John"Sfortunatamente, la rappresentazione relazionale creata tramite il modello di visualizzazione è disponibile solo in modalità di sola lettura. Quando viene elaborata una query su di essa, MarkLogic cercherà di utilizzare . In passato, MarkLogic aveva rappresentazioni relazionali limitate, totalmente ed erano modificabili, ma ora sono considerate deprecate.
Modello grafico in MarkLogic
Con il supporto del modello grafico (RDF), la situazione è più o meno la stessa. Anche qui, mediante è possibile creare una rappresentazione RDF della collezione di documenti dell'esempio sopra:
/Person
PREFIX
"http://example.org/example#"
sem:iri( $PREFIX || @SSN )
sem:iri( $PREFIX || surname )
sem:iri( $PREFIX || @SSN )
sem:iri( $PREFIX || name )
Al grafo RDF ottenuto è possibile indirizzare una query SPARQL:
PREFIX :
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}A differenza del modello relazionale, il modello grafico di MarkLogic è supportato anche in altri due modi:
- Il DBMS può fungere da archivio RDF autonomo (i tripleti in esso saranno chiamati in contrasto con quelli precedentemente descritti, che sono chiamati ).
- RDF in una serializzazione speciale può essere semplicemente inserito nei documenti XML o JSON (e i tripleti in tal caso saranno chiamati ). Probabilmente, questa è un'alternativa ai meccanismi di
idrefe simili.
Una buona comprensione di come sia "realmente" strutturato MarkLogic è offerta da , in questo senso è a basso livello, anche se il suo scopo è piuttosto opposto — cercare di astrarsi dal modello dati utilizzato, garantire un funzionamento coerente con i dati in diversi modelli, transazionalità e così via.
Database multimodali "senza modello principale"
Sul mercato ci sono anche DBMS che si posizionano come inizialmente multimodali, senza alcun modello di base ereditato. Tra questi ci sono , (dal 2018, la società sviluppatrice appartiene a SAP) e (servizio all'interno della piattaforma cloud Microsoft Azure).
In realtà, i modelli "principali" in ArangoDB e OrientDB esistono. In entrambi i casi, si tratta di modelli dati proprietari, che sono generalizzazioni del modello documentale. Le generalizzazioni riguardano principalmente la semplificazione della possibilità di effettuare query di natura grafica e relazionale.
Questi modelli sono gli unici disponibili per l'uso nei database specificati, progettati per l'elaborazione con propri linguaggi di query. Sicuramente, tali modelli e database sono promettenti, tuttavia la mancanza di compatibilità con modelli e linguaggi standard rende impossibile l'uso di questi database nei sistemi ereditati, sostituendo quelli già utilizzati.
Su ArangoDB e OrientDB su Habr è già stata pubblicata un'ottima articolo: .
ArangoDB
ArangoDB dichiara di supportare il modello di dati grafico.
I nodi del grafo in ArangoDB sono documenti normali, mentre i bordi sono documenti di tipo speciale, che hanno, insieme a campi di sistema normali (_key, _id, _rev) campi di sistema _from e _to. I documenti nei database documentali sono tradizionalmente raggruppati in collezioni. Le collezioni di documenti che rappresentano bordi in ArangoDB sono chiamate collezioni edge. A proposito, i documenti delle collezioni edge sono anch'essi documenti, quindi i bordi in ArangoDB possono anche fungere da nodi.
Dati di origine
Supponiamo di avere una collezione persons, i cui documenti appaiono così:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Alice"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Bob"
}
]Supponiamo anche di avere una collezione cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "John Donne"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Jean-Jacques"
}
]Allora la collezione likes può apparire nel seguente modo:
[
{
"_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
}
]Query e risultati
Una query in stile grafico nel linguaggio AQL utilizzato in ArangoDB, che restituisce in formato leggibile dall'uomo informazioni su quale caffè piace a chi, appare così:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }In stile relazionale, quando piuttosto "calcoliamo" le relazioni piuttosto che memorizzarle, questa query può essere riscritta così (a proposito, senza la collezione likes si sarebbe potuto fare 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" : "Alice" , likes : "Jean-Jacques" } ,
{ "person" : "Alice" , likes : "John Donne" } ,
{ "person" : "Bob" , likes : "John Donne" }
]Ulteriori query e risultati
Se sembra che il formato del risultato sopra sia più caratteristico per un DBMS relazionale che per uno documentale, si può provare una query di questo tipo (oppure si può utilizzare ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Il risultato avrà il seguente aspetto:
[
{ "person" : "Alice" , likes : ["Jean-Jacques" , "John Donne"] } ,
{ "person" : "Bob" , likes : ["John Donne"] }
]OrientDB
Alla base dell'implementazione del modello grafico sopra quello documentale in OrientDB c'è i campi dei documenti devono avere, oltre a valori scalari più o meno standard, anche valori di tipi come LINK, LINKLIST, LINKSET, LINKMAP e LINKBAG. I valori di questi tipi sono riferimenti o collezioni di riferimenti a dei documenti.
L'identificatore del documento assegnato dal sistema ha un "senso fisico", indicando la posizione della registrazione nel database, e appare più o meno così: @rid : #3:16. Di conseguenza, i valori delle proprietà di riferimento sono realmente più indicazioni (come nel modello grafico), e non condizioni di selezione (come nel relazionale).
Come in ArangoDB, in OrientDB i bordi sono rappresentati come documenti separati (anche se, se un bordo non ha proprie proprietà, può essere reso , e non avrà un documento separato associato).
Dati di origine
In un formato simile a del database OrientDB, i dati del precedente esempio per ArangoDB apparirebbero più o meno così:
[
{
"@type": "document",
"@rid": "#11:0",
"@class": "Person",
"name": "Alice",
"out_likes": [
"#30:1",
"#30:2"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#12:0",
"@class": "Person",
"name": "Bob",
"out_likes": [
"#30:3"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#21:0",
"@class": "Cafe",
"name": "Jean-Jacques",
"in_likes": [
"#30:2",
"#30:3"
],
"@fieldTypes": "in_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#22:0",
"@class": "Cafe",
"name": "John Donne",
"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, anche i nodi memorizzano informazioni sui bordi in entrata e in uscita. Durante È necessario monitorare da soli l'integrità dei link dell'API Documento, mentre l'API Graph si occupa di questo lavoro. Ma vediamo come appare la query a OrientDB in linguaggi di query "puri", non integrati nei linguaggi di programmazione.
Query e risultati
Una query simile a quella presentata nell'esempio per ArangoDB in OrientDB appare così:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameIl risultato sarà ottenuto nel seguente formato:
[
{ "person_name": "Alice", "cafe_name": "John Donne" },
{ "person_name": "Alice", "cafe_name": "Jean-Jacques" },
{ "person_name": "Bob", "cafe_name": "Jean-Jacques" }
]Se il formato del risultato sembra di nuovo troppo "relazionale", è necessario rimuovere la riga con :
[
{ "person_name": "Alice", "cafe_name": [ "John Donne", "Jean-Jacques" ] },
{ "person_name": "Bob", "cafe_name": [ "Jean-Jacques" ] }
]Il linguaggio di query di OrientDB può essere caratterizzato come SQL con inserimenti simili a Gremlin. Nella versione 2.2 è stata introdotta una forma di query 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 query precedente. Pensate a cosa deve essere rimosso per renderlo più "relazionale", come nella primissima query.
Azure CosmosDB
Con minore rilevanza, quanto detto sopra su ArangoDB e OrientDB si applica ad Azure CosmosDB. CosmosDB fornisce le seguenti API per l'accesso ai dati: SQL, MongoDB, Gremlin e Cassandra.
Le API SQL e MongoDB sono utilizzate per l'accesso ai dati nel modello documentale. Le API Gremlin e Cassandra — rispettivamente per l'accesso ai dati nel modello a grafo e in quello colonnare. I dati in tutti i modelli sono memorizzati nel formato del modello interno di CosmosDB: ("atom-record-sequence"), che è anche vicino al modello documentale.
Tuttavia, il modello di dati scelto dall'utente e l'API utilizzata vengono fissati al momento della creazione dell'account nel servizio. Non è possibile accedere ai dati caricati in un modello nel formato di un altro modello, il che sarebbe illustrato in modo simile a questo disegno:
Così, la multimedialità in Azure CosmosDB oggi rappresenta solo la possibilità di utilizzare diverse basi di dati che supportano vari modelli, da un unico fornitore, il che non risolve tutti i problemi di stoccaggio variegato.
Database multimodali basati sul modello grafico?
È notevole che attualmente non ci siano database relazionali multimodali sul mercato che si basano su modelli di grafo (a meno che non si consideri la multimodalità come il supporto simultaneo di due modelli a grafo: RDF e LPG; vedere a riguardo in ). La realizzazione di un modello documentale sopra un modello grafico presenta le maggiori difficoltà, piuttosto che su uno relazionale.
La questione su come implementare un modello relazionale sopra un modello grafico è stata considerata già ai tempi della sua formazione. Come , ad esempio, :
Non c'è nulla di intrinseco nell'approccio grafico che impedisca di creare uno strato (ad esempio, tramite un indicizzazione adeguata) su un database grafico che consenta una vista relazionale con (1) recupero di tuple dai soliti coppie chiave-valore e (2) raggruppamento di tuple per tipo di relazione.
Nell'implementazione di un modello documentale sopra un grafico, bisogna tenere presente, ad esempio, quanto segue:
- Gli elementi di un array JSON sono considerati ordinati, mentre quelli che escono dal vertice di un arco grafico no;
- I dati in un modello documentale sono solitamente denormalizzati, non si desidera conservare più copie dello stesso documento incorporato, e gli identificatori dei sub-documenti solitamente non sono presenti;
- D'altra parte, l'ideologia dei DBMS documentali è che i documenti sono 'aggregati' pronti all'uso, che non è necessario ricostruire ogni volta. È necessario garantire nella modellazione grafica la possibilità di ottenere rapidamente un sotto-grafico corrispondente a un documento pronto.
Un po' di pubblicità
L'autore dell'articolo è coinvolto nello sviluppo del DBMS NitrosBase, il cui modello interno è grafico, mentre i modelli esterni — relazionale e documentale — sono le sue rappresentazioni. Tutti i modelli sono equivalenti: praticamente qualsiasi dato è accessibile in ognuno di essi utilizzando il linguaggio di query naturale per ciascuno. Inoltre, in qualsiasi rappresentazione i dati possono essere modificati. Le modifiche verranno riflesse nel modello interno e, di conseguenza, nelle altre rappresentazioni.
Come appare la corrispondenza tra i modelli in NitrosBase — spero di descriverlo in uno dei prossimi articoli.
Conclusione
Spero che le linee generali di ciò che viene definito multimodalità siano diventate, per il lettore, più o meno chiare. Le DBMS multimodali comprendono DBMS abbastanza diversi, e il 'supporto di più modelli' può apparire in modi diversi. Per comprendere cosa si intende per 'multimodalità' in ciascun caso specifico, è utile rispondere alle seguenti domande:
- Si sta parlando del supporto di modelli tradizionali o di un singolo 'modello ibrido'?
- I modelli sono 'equivalenti', o uno di essi è sottoposto agli altri?
- Le modelle sono "indifferenti" l'una all'altra? Possono i dati registrati in un modello essere letti in un altro o addirittura sovrascritti?
Credo che si possa già dare una risposta positiva alla domanda sull'attualità dei database multimodelli, ma è interessante capire quali delle loro varietà saranno più richieste nel prossimo futuro. Sembra che i database multimodelli che supportano modelli tradizionali, in particolare quello relazionale, saranno più richiesti; mentre la popolarità dei database multimodelli che offrono nuovi modelli, combinando i vantaggi di vari modelli tradizionali, è una questione di un futuro più lontano.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Utilizzate database multimodelli?
Non utilizziamo, conserviamo tutto in un unico DBMS e in un unico modello
Utilizziamo le possibilità multimodello dei database tradizionali
Pratichiamo la conservazione poliglotta (polyglot persistence)
Utilizziamo nuovi database multimodelli (Arango, Orient, CosmosDB)
Hanno votato 19 utenti. Si sono astenuti 4 utenti.
Fonte: habr.com
