I sistemi informatici moderni sono piuttosto complessi. Non è solo la loro complessità a derivare dai dati che elaborano. La complessità dei dati può spesso risiedere nella varietà dei modelli di dati utilizzati. Ad esempio, quando i dati diventano "grandi", una delle caratteristiche che possono risultare scomode è non solo il loro volume, ma anche la loro varietà.
Se non trovi ancora difetti nei ragionamenti, continua a leggere.
Contenuto
Persistenza poliglotta
Quanto detto sopra porta al fatto che, a volte, all'interno di un singolo sistema è necessario utilizzare più DBMS diversi per la memorizzazione dei dati e per affrontare diverse esigenze di elaborazione, ognuno dei quali supporta il proprio modello di dati. Su iniziativa di M. Fowler, una serie di libri noti e uno dei Manifesto Agile, tale situazione è stata chiamata archiviazione multivariata ('polyglot persistence').
A Fowler appartiene anche il seguente esempio di organizzazione dell'archiviazione dei dati in un'applicazione completamente funzionale e ad alta capacità nel settore dell'e-commerce.
Questo esempio, ovviamente, è un po' esagerato, ma si possono trovare alcune considerazioni a favore della scelta di un determinato DBMS per uno scopo specifico, ad esempio, .
È chiaro che essere il custode di uno zoo del genere non è facile.
- La quantità di codice che esegue la conservazione dei dati cresce proporzionalmente al numero di DBMS utilizzati; la quantità di codice che sincronizza i dati aumenta, bene che non sia proporzionale al quadrato di quel numero.
- I costi per garantire le caratteristiche enterprise (scalabilità, resilienza, alta disponibilità) di ciascun DBMS utilizzato aumentano in modo esponenziale.
- È impossibile garantire le caratteristiche enterprise della sottosistema di archiviazione nel suo complesso, specialmente la transazionalità.
Dal punto di vista del direttore dello zoo, tutto appare così:
- Aumento significativo dei costi delle licenze e del supporto tecnico da parte del produttore del DBMS.
- Espansione del personale e allungamento dei tempi.
- Perdite finanziarie dirette o sanzioni a causa di incoerenze nei dati.
C'è un notevole aumento del costo totale di possesso del sistema (TCO). C'è una via d'uscita dalla situazione del "storage multivariato"?
Multimodalità
Il termine "storage multivariato" è entrato in uso nel 2011. La consapevolezza dei problemi dell'approccio e la ricerca di soluzioni hanno richiesto diversi anni, e nel 2015 gli analisti di Gartner hanno formulato la risposta:
- Da "»:
Il futuro dei DBMS, delle loro architetture e dei metodi di utilizzo è la multimodalità.
- Da "»:
I principali DBMS operativi offriranno diversi modelli — relazionali e non relazionali — all'interno di un'unica piattaforma.
Sembra che per questa volta gli analisti di Gartner non si siano sbagliati. Se si visita la pagina con dei DBMS su DB-Engines, si può vedere che launmaggior parte dei leader si posiziona proprio come DBMS multimodale. Lo stesso si può osservare anche nella pagina di qualsiasi classifica specifica.
Nella tabella sottostante sono elencati i DBMS leader in ciascuna delle classifiche private, che dichiarano la loro multimodalità. Per ogni DBMS sono indicate la modellistica iniziale supportata (un tempo l'unica) e, accanto ad essa, i modelli attualmente supportati. Sono inclusi anche i DBMS che si posizionano come "originariamente multimodali", senza alcun modello ereditato iniziale secondo le dichiarazioni dei loro creatori.
| 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 asterisco richiedono delle precisazioni:
- Il DBMS PostgreSQL non supporta il modello di dati grafico, ma è supportato da un prodotto , come ad esempio AgensGraph.
- In relazione a MongoDB, è più corretto parlare di operatori grafici nel linguaggio di query (, ), e riguardo al supporto del modello grafico, sebbene, ovviamente, la loro introduzione abbia richiesto alcune ottimizzazioni a livello di memorizzazione fisica per supportare il modello grafico.
- In riferimento a Redis si intende l'estensione .
Successivamente, per ciascuna delle classi mostreremo come viene implementato il supporto per più modelli nei DBMS di questa classe. Considereremo i modelli relazionale, documentale e grafico come i più importanti e mostreremo, attraverso esempi di specifici DBMS, come vengano implementati quelli "mancanti".
DBMS multimodali basati su modello relazionale
I principali DBMS attualmente sono relazionali, non si potrebbe considerare la previsione di Gartner avverata se i DBMS relazionali non dimostrassero progressi verso la multimodalità. E lo stanno dimostrando. Ora le considerazioni secondo cui un DBMS multimodale è simile a un coltellino svizzero, con cui non si può fare nulla di buono, possono essere subito dirette a Larry Ellison.
Tuttavia, all'autore piace di più l'implementazione della multimodalità in Microsoft SQL Server, il cui esempio descriverà il supporto dei DBMS relazionali per i modelli documentale e grafico.
Modello documentale in MS SQL Server
Come viene implementato il supporto per il modello documentale in MS SQL Server, ci sono già due ottimi articoli su Habr, quindi mi limiterò a un breve riassunto e commento:
Il modo in cui MS SQL Server supporta il modello documentale è piuttosto tipico per i database 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 subdocumenti.
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 prima classe’ in un database 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 delle tabelle basate sui valori di questi campi e persino l'estrazione dei documenti in base a questi valori. Tuttavia, è possibile creare una colonna calcolata su tale campo e un indice su di essa.
In aggiunta, 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 allo stoccaggio tradizionale. È chiaro che, per quanto possa essere veloce un DBMS, questo approccio contraddice l'ideologia dei DBMS documentali, che in sostanza memorizzano risposte pronte per richieste comuni, e può affrontare solo problemi di comodità nello sviluppo, ma non di prestazioni.
Infine, MS SQL Server consente di affrontare il problema opposto alla costruzione del documento: è possibile suddividere il JSON in tabelle utilizzando . 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 del tutto : si propone 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 alle normali tabelle per la memorizzazione di record, con la sola differenza esterna che nella tabella è presente un campo di sistema $node_id — identificatore univoco all'interno del database per il nodo del grafo.
Analogamente, le tabelle di secondo tipo hanno campi di sistema $from_id e $to_id, le righe in tali tabelle definiscono chiaramente le relazioni tra i nodi. Per memorizzare le relazioni di ciascun tipo si utilizza una tabella separata.
Illustriamo quanto detto con un esempio. Supponiamo che i dati del grafo abbiano uno schema come quello mostrato nell'immagine. 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 ad esse è possibile utilizzare pattern grafici con una sintassi simile a Cypher (tuttavia, «*» e altre non sono ancora supportati). Sulla base delle misurazioni delle prestazioni, si può anche presumere che il modo in cui i dati sono memorizzati in queste tabelle sia diverso dal meccanismo di memorizzazione dei dati nelle tabelle normali e ottimizzato per l'esecuzione di tali query grafiche.
SELEZIONA Cafe.name
DA Person, likes, Cafe
DOVE MATCH (Person-(friendOf)-(likes)->Cafe)
E Person.name = 'John';Inoltre, è piuttosto difficile non utilizzare questi schemi grafici quando si lavora con tali tabelle, poiché nelle normali query SQL per risolvere compiti simili sarebbe necessario fare ulteriori sforzi per ottenere identificatori «grafici» sistemici dei nodi ($node_id, $from_id, $to_id; per lo stesso motivo le query per l'inserimento dei dati non sono incluse qui in quanto considerate superflue).
Riassumendo la descrizione delle realizzazioni dei modelli documentali e grafici in MS SQL Server, noterei che tali realizzazioni di un modello sopra l'altro non sembrano riuscite innanzitutto dal punto di vista del design linguistico. È necessario espandere un linguaggio con un altro, i linguaggi non sono del tutto «ortogonali», le regole di combinazione possono essere piuttosto bizzarre.
DBMS multimodali basati su modello documentale
In questa sezione desidero illustrare l'implementazione della multimodalità nei database documentali prendendo come esempio uno dei meno popolari, MongoDB (come detto, in essa ci sono solo operatori graficamente condizionati, $lookup e $graphLookupche non funzionano su collezioni sharded), ma su un sistema di database più maturo e «enterprise». .
Quindi, 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
È possibile creare una rappresentazione relazionale della collezione di documenti utilizzando (il contenuto degli elementi value nell'esempio seguente può contenere un XPath arbitrario):
/Person
Person
SSN
@SSN
string
name
name
surname
surnameÈ possibile indirizzare una query SQL alla rappresentazione creata (ad esempio, tramite ODBC):
SELECT name, surname FROM Person WHERE name="John"Sfortunatamente, la rappresentazione relazionale creata tramite il modello di visualizzazione è accessibile solo in modalità di sola lettura. Quando si elabora una richiesta a essa, MarkLogic cercherà di utilizzare . In precedenza, MarkLogic aveva anche rappresentazioni relazionali limitate, basate esclusivamente e disponibili per la registrazione, ma attualmente sono considerati obsoleti.
Modello grafico in MarkLogic
Per quanto riguarda il supporto per il modello grafico (RDF), la situazione è più o meno la stessa. Anche in questo caso, è possibile utilizzare per creare una rappresentazione RDF della collezione di documenti dell'esempio precedente:
/Person
PREFIX
"http://example.org/example#"
sem:iri( $PREFIX || @SSN )
sem:iri( $PREFIX || surname )
sem:iri( $PREFIX || @SSN )
sem:iri( $PREFIX || name )
Puoi inviare una query SPARQL al grafo RDF ottenuto:
PREFIX :
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Diversamente dal modello relazionale, il modello grafico di MarkLogic è supportato anche in due altri modi:
- Il DBMS può essere un archivio RDF completamente separato (i tripleti in esso saranno chiamati in contrapposizione a quanto descritto sopra ).
- L'RDF in una serializzazione speciale può essere semplicemente inserito in documenti XML o JSON (e le triplette verranno chiamate ). Probabilmente è un'alternativa a meccanismi
idrefe così via.
Una buona rappresentazione di come "in realtà" tutto funzioni in MarkLogic è fornita da , in questo senso è di basso livello, anche se la sua destinazione è piuttosto opposta: cercare di astrarsi dal modello di dati utilizzato, garantire coerenza nel lavoro con dati in diversi modelli, transazionalità e così via.
DBMS multimodali "senza modello principale"
Sono presenti sul mercato anche DBMS che si propongono come nativamente multimodali, senza alcun modello principale ereditato. Tra questi ci sono , (dal 2018, la società di sviluppo appartiene a SAP) e (un servizio all'interno della piattaforma cloud Microsoft Azure).
In effetti, ci sono "modelli principali" in ArangoDB e OrientDB. In entrambi i casi si tratta di modelli di dati proprietari che sono generalizzazioni di quello documentale. Le generalizzazioni si riferiscono principalmente alla semplificazione della possibilità di effettuare query di natura grafica e relazionale.
Questi modelli sono gli unici disponibili per l'uso nei sistemi di gestione dei database specificati, e sono destinati a lavorare con linguaggi di query proprietari. Senza dubbio, questi modelli e i rispettivi database sono promettenti, ma l'assenza di compatibilità con i modelli e i linguaggi standard rende impossibile utilizzare questi database nei sistemi ereditati — per sostituire i database già in uso.
Su ArangoDB e OrientDB c'è già stato un articolo interessante su Habr: .
ArangoDB
ArangoDB dichiara di supportare il modello di dati grafico.
I nodi del grafo in ArangoDB sono documenti ordinari, mentre i bordi sono documenti di tipo speciale, aventi insieme ai normali campi di sistema (_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 i bordi in ArangoDB sono chiamate collezioni edge. Vale la pena notare che 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 inoltre di avere una collezione caffè:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "John Donne"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Jean-Jacques"
}
]Quindi la collezione mi piace potrebbe apparire come segue:
[
{
"_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 usato in ArangoDB, che restituisce in modo leggibile per le persone le informazioni su chi piace quale caffè, 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 invece di memorizzarle, questa query può essere riscritta così (tra l'altro, senza la collezione mi piace si potrebbe 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" }
]Altre query e risultati
Se sembra che il formato del risultato sopra sia più caratteristico per un DBMS relazionale piuttosto che per uno documentale, è possibile provare questa query (o 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 il documento in OrientDB c'è campi dei documenti che hanno valori più o meno standard scalari, ma anche valori di tipi come LINK, LINKLIST, LINKSET, LINKMAP e LINKBAG. I valori di questi tipi sono riferimenti o collezioni di riferimenti a documenti.
L'identificatore del documento assegnato dal sistema ha un "senso fisico", indicando la posizione della registrazione nel database, e appare all'incirca così: @rid : #3:16. Pertanto, i valori delle proprietà di riferimento sono davvero piuttosto puntatori (come nel modello grafico), piuttosto che condizioni di selezione (come in quello relazionale).
Come in ArangoDB, in OrientDB gli archi sono rappresentati come documenti separati (anche se se un arco non ha le proprie proprietà, può essere reso , e non sarà necessario un documento separato).
Dati di origine
In un formato simile a di OrientDB, i dati del precedente esempio per ArangoDB apparirebbero 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, i vertici conservano anche informazioni sui bordi entranti e uscenti. Durante L'API Document per la coerenza dei riferimenti richiede di essere monitorata manualmente, mentre l'API Graph si occupa di tutto ciò. Vediamo come si presenta una chiamata a OrientDB in linguaggi di query "puramente" non integrati in linguaggi di programmazione.
Query e risultati
Una query equivalente a quella dell'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à restituito 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 nuovamente eccessivamente "relazionale", è necessario rimuovere la riga con :
[
{ "person_name": "Alice", "cafe_name": [ "John Donne", "Jean-Jacques" ] },
{ "person_name": "Bob", "cafe_name": [ "Jean-Jacques" ] }
]Il linguaggio delle 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 rimuovere per renderlo più "relazionale", proprio come nella prima query.
Azure CosmosDB
In misura minore, quanto detto sopra su ArangoDB e OrientDB si applica ad Azure CosmosDB. CosmosDB offre i seguenti API per l'accesso ai dati: SQL, MongoDB, Gremlin e Cassandra.
L'API SQL e l'API MongoDB vengono utilizzati per accedere ai dati nel modello documentale. L'API Gremlin e l'API Cassandra servono per accedere ai dati, rispettivamente, nel modello grafico e colonnare. I dati in tutti i modelli vengono mantenuti nel formato del modello interno di CosmosDB: («atom-record-sequence»), che è anche simile a un documento.
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 in un formato diverso, come sarebbe illustrato da un'immagine simile a questa:
Pertanto, la multimodalità in Azure CosmosDB attualmente rappresenta solo la possibilità di utilizzare più database che supportano diversi modelli, tutti dello stesso fornitore, il che non risolve tutte le problematiche dello storage multi-variante.
DBMS multimodali basati su modello grafico?
È interessante notare che attualmente non ci sono database multi-modello sul mercato che si basano su un modello grafico (salvo non considerare la multi-modellità come supporto simultaneo di due modelli grafici: RDF e LPG; vedere a riguardo in ). La maggiore difficoltà si presenta nell'implementazione di un modello documentale sopra a un modello grafico, piuttosto che relazionale.
La questione di come implementare un modello relazionale sopra un modello grafico è stata discussa già ai tempi della sua nascita. Come , ad esempio, :
Non c'è nulla di intrinseco nell'approccio grafico che impedisca di creare uno strato (ad esempio, tramite indicizzazione appropriata) 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.
Quando si implementa un modello documentale sopra a un modello grafico, bisogna tenere a mente, ad esempio, quanto segue:
- Gli elementi dell'array JSON sono considerati ordinati, quelli provenienti dalla cima dell'arco del grafico no;
- I dati nel modello documentale sono solitamente denormalizzati; non si desidera veramente memorizzare più copie dello stesso documento annidato e di solito non ci sono identificatori per i sotto-documenti.
- D'altra parte, l'ideologia dei DBMS documentali sta nel fatto che i documenti sono 'aggregati' pronti che non devono essere ricostruiti ogni volta. È necessario garantire nella modelizzazione grafica la possibilità di ottenere rapidamente un sotto-grafico corrispondente al 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 — ne sono le rappresentazioni. Tutti i modelli sono equivalenti: praticamente qualsiasi dato è accessibile in ciascuno di essi utilizzando il linguaggio di query naturale per ciascun modello. Inoltre, in qualsiasi rappresentazione, i dati possono essere modificati. Le modifiche si rifletteranno nel modello interno e, di conseguenza, nelle altre rappresentazioni.
Come appare la corrispondenza dei modelli in NitrosBase — spero di descriverlo in uno dei prossimi articoli.
Conclusione
Spero che le linee generali di ciò che si chiama multimodalità siano diventate più o meno chiare per il lettore. Si definiscono multimodali diversi sistemi di gestione dei database (SGBD), e il termine 'supporto di più modelli' può assumere forme diverse. Per comprendere cosa si intende per 'multimodalità' in ogni singolo caso, è utile rispondere alle seguenti domande:
- Si tratta di supportare modelli tradizionali o di una sorta di modello 'ibrido'?
- I modelli sono 'paritari' o uno di essi è subordinato agli altri?
- I modelli sono 'indifferenti' tra loro? I dati registrati in un modello possono essere letti in un altro o addirittura sovrascritti?
Credo che sulla rilevanza dei database multimodali si possa ormai dare una risposta positiva, ma resta da capire quali delle loro varianti saranno più richieste nel prossimo futuro. Sembra che i database multimodali che supportano modelli tradizionali, in particolare relazionali, saranno i più richiesti; la popolarità dei database multimodali che offrono nuovi modelli, combinando i vantaggi di vari tradizionali, è una questione di un futuro più lontano.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Utilizzate database multimodali?
Non li utilizziamo, conserviamo tutto in un unico database e in un unico modello.
Utilizziamo le funzionalità multimodali dei database tradizionali.
Pratichiamo la persistenza poliglota.
Utilizziamo nuovi database multimodali (Arango, Orient, CosmosDB).
Hanno votato 19 utenti. 4 utenti si sono astenuti.
Fonte: habr.com
