Els sistemes d'informació moderns són força complexos. No menys important, la seva complexitat es deu a la complexitat de les dades que s'hi processen. La complexitat de les dades sovint rau en la varietat de models de dades utilitzats. Així, per exemple, quan les dades es fan "grans", una de les característiques problemàtiques no és només el seu volum ("volum"), sinó també la seva varietat ("varietat").
Si encara no trobeu cap defecte en el raonament, seguiu llegint.
Contingut
Persistència políglota
L'anterior porta al fet que de vegades, fins i tot en el marc d'un sistema, és necessari utilitzar diversos DBMS diferents per emmagatzemar dades i resoldre diversos problemes de processament, cadascun dels quals admet el seu propi model de dades. Amb la mà lleugera de M. Fowler, una sèrie de llibres famosos i un de Manifest àgil, aquesta situació es diu emmagatzematge multivariant (“persistència políglota”).
Fowler també té el següent exemple d'organització de l'emmagatzematge de dades en una aplicació amb totes les funcions i de gran càrrega en el camp del comerç electrònic.
Aquest exemple, per descomptat, és una mica exagerat, però es poden trobar algunes consideracions a favor d'escollir un o un altre SGBD per al propòsit corresponent, per exemple, .
Està clar que ser servent en un zoològic així no és fàcil.
- La quantitat de codi que realitza l'emmagatzematge de dades creix en proporció al nombre de SGBD utilitzats; la quantitat de dades de sincronització del codi és bona si no és proporcional al quadrat d'aquest nombre.
- Com a múltiple del nombre de SGBD utilitzats, augmenten els costos de proporcionar les característiques empresarials (escalabilitat, tolerància a errors, alta disponibilitat) de cadascun dels SGBD utilitzats.
- És impossible garantir les característiques empresarials del subsistema d'emmagatzematge en conjunt, especialment la transaccionalitat.
Des del punt de vista del director del zoo, tot es veu així:
- Un augment múltiple del cost de les llicències i del suport tècnic del fabricant de SGBD.
- Excés de personal i augment de terminis.
- Pèrdues econòmiques directes o sancions per incoherència de dades.
Hi ha un augment significatiu del cost total de propietat (TCO) del sistema. Hi ha alguna manera de sortir de la situació de les "opcions d'emmagatzematge múltiples"?
Multimodel
El terme "emmagatzematge multivariant" es va utilitzar l'any 2011. La presa de consciència dels problemes de l'enfocament i la recerca d'una solució va trigar diversos anys, i el 2015, per boca dels analistes de Gartner, es va formular la resposta:
- de "'
El futur dels SGBD, les seves arquitectures i les maneres d'utilitzar-los és multimodel.
- de "'
Els SGBD operatius líders oferiran diversos models (relacionals i no relacionals) com a part d'una plataforma única.
Sembla que aquesta vegada els analistes de Gartner van tenir raó amb la seva previsió. Si aneu a la pàgina amb DBMS a DB-Engines, ho podeu veureоLa majoria dels seus líders es posicionen específicament com a SGBD multimodel. El mateix es pot veure a la pàgina amb qualsevol valoració privada.
La taula següent mostra el SGBD: els líders de cadascuna de les qualificacions privades, que diuen ser multimodel. Per a cada SGBD, s'indica el model original suportat (que abans va ser l'únic) i juntament amb ell els models suportats actualment. També s'enumeren els SGBD que es posicionen com a "originalment multimodel" i, segons els creadors, no tenen cap model heretat inicial.
| SGBD | Model inicial | Models addicionals |
|---|---|---|
| Oracle | relacional | Gràfic, document |
| MS SQL | relacional | Gràfic, document |
| PostgreSQL | relacional | Gràfic*, document |
| MarkLogic | Documental | Gràfic, relacional |
| MongoDB | Documental | Valor-clau, gràfic* |
| DataStax | Columna ampla | Documental, gràfic |
| Redis | Clau-valor | Documental, gràfic* |
| ArangoDB | - | Gràfic, document |
| OrientDB | - | Gràfic, document, relacional |
| Azure CosmosDB | - | Gràfic, document, relacional |
Notes sobre la taula
Els asteriscs a la taula marquen les declaracions que requereixen reserves:
- El SGBD PostgreSQL no admet el model de dades de gràfics, però aquest producte sí , com ara AgensGraph.
- En relació a MongoDB, és més correcte parlar de la presència d'operadors gràfics en el llenguatge de consulta (, ) que sobre donar suport al model gràfic, encara que, per descomptat, la seva introducció va requerir algunes optimitzacions a nivell d'emmagatzematge físic en la direcció de donar suport al model gràfic.
- En relació a Redis, ens referim a l'extensió .
A continuació, per a cadascuna de les classes, mostrarem com s'implementa el suport per a diversos models al SGBD d'aquesta classe. Considerarem els models relacionals, de documents i de gràfics com els més importants i utilitzarem exemples de SGBD específics per mostrar com s'implementen els "que falten".
SGBD multimodel basat en el model relacional
Els principals DBMS actualment són relacionals; la previsió de Gartner no es podria considerar certa si els RDBMS no mostressin moviment en la direcció del modelatge múltiple. I ho demostren. Ara la idea que un DBMS multimodel és com un ganivet suís, que no pot fer res bé, es pot dirigir directament a Larry Ellison.
L'autor, però, prefereix la implementació del modelatge múltiple a Microsoft SQL Server, en l'exemple del qual es descriurà el suport RDBMS per a models de documents i gràfics.
Model de document en MS SQL Server
Ja hi ha hagut dos articles excel·lents sobre Habré sobre com implementa MS SQL Server el suport per al model de document, em limitaré a un breu relat i comentari:
La manera de donar suport al model de document a MS SQL Server és força típica per als SGBD relacionals: es proposa que els documents JSON s'emmagatzemen en camps de text normals. El suport per al model de document és proporcionar operadors especials per analitzar aquest JSON:
- per extreure valors d'atributs escalars,
- per extreure subdocuments.
El segon argument dels dos operadors és una expressió en la sintaxi semblant a JSONPath.
De manera abstracta, podem dir que els documents emmagatzemats d'aquesta manera no són "entitats de primera classe" en un SGBD relacional, a diferència de les tuples. Concretament, a MS SQL Server actualment no hi ha índexs sobre els camps dels documents JSON, la qual cosa dificulta unir taules utilitzant els valors d'aquests camps i fins i tot seleccionar documents amb aquests valors. Tanmateix, és possible crear una columna calculada per a aquest camp i un índex sobre ell.
A més, MS SQL Server ofereix la possibilitat de construir còmodament un document JSON a partir del contingut de les taules mitjançant l'operador - una possibilitat, en cert sentit, contrària a l'anterior, l'emmagatzematge convencional. És evident que, per molt ràpid que sigui un SGBD, aquest enfocament contradiu la ideologia dels SGBD de documents, que essencialment emmagatzemen respostes ja fetes a les consultes populars, i només poden resoldre problemes de facilitat de desenvolupament, però no de velocitat.
Finalment, MS SQL Server us permet resoldre el problema invers de la construcció de documents: podeu descompondre JSON en taules utilitzant . Si el document no és completament pla, caldrà utilitzar-lo CROSS APPLY.
Model gràfic en MS SQL Server
El suport per al model de gràfics (LPG) també està totalment implementat a Microsoft SQL Server : Es proposa utilitzar taules especials per emmagatzemar nodes i emmagatzemar arestes de gràfics. Aquestes taules es creen mitjançant expressions CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectivament.
Les taules del primer tipus són similars a les taules ordinàries per emmagatzemar registres, amb l'única diferència externa que la taula conté un camp del sistema. $node_id — identificador únic d'un node gràfic dins de la base de dades.
De la mateixa manera, les taules del segon tipus tenen camps de sistema $from_id и $to_id, les entrades d'aquestes taules defineixen clarament les connexions entre nodes. S'utilitza una taula separada per emmagatzemar les relacions de cada tipus.
Il·lustrem-ho amb un exemple. Deixeu que les dades del gràfic tinguin un disseny com el que es mostra a la figura. Aleshores, per crear l'estructura corresponent a la base de dades, heu d'executar les consultes DDL següents:
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 principal especificitat d'aquestes taules és que en les consultes contra elles és possible utilitzar patrons de gràfics amb sintaxi semblant a Cypher (no obstant això, "*"etc. encara no són compatibles). A partir de les mesures de rendiment, també es pot suposar que la forma en què s'emmagatzemen les dades en aquestes taules és diferent de la manera com s'emmagatzemen les dades a les taules normals i està optimitzada per executar aquestes consultes de gràfics.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';A més, és bastant difícil no utilitzar aquests patrons de gràfics quan es treballa amb aquestes taules, ja que en consultes SQL ordinàries per resoldre problemes similars caldrà fer esforços addicionals per obtenir els identificadors de nodes "gràfics" del sistema ($node_id, $from_id, $to_id; Per la mateixa raó, les consultes per inserir dades no es mostren aquí perquè són innecessàriament feixugues).
Per resumir la descripció de les implementacions dels models de documents i gràfics a MS SQL Server, destacaria que aquestes implementacions d'un model sobre un altre no semblen reeixides, principalment des del punt de vista del disseny del llenguatge. Cal estendre un idioma amb un altre, els idiomes no són completament "ortogonals", les regles de compatibilitat poden ser força estranyes.
SGBD multimodel basat en el model de document
En aquesta secció, m'agradaria il·lustrar la implementació del multimodel en els SGBD de documents utilitzant l'exemple del no més popular d'ells, MongoDB (com es va dir, només té operadors de gràfics condicionals). $lookup и $graphLookup, no treballant en col·leccions fragmentades), sinó utilitzant l'exemple d'un SGBD més madur i "empresarial" .
Per tant, deixeu que la col·lecció contingui un conjunt de documents XML del tipus següent (MarkLogic també us permet emmagatzemar documents JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Model relacional en MarkLogic
Es pot crear una vista relacional d'una col·lecció de documents utilitzant (contingut dels elements value a l'exemple següent pot haver-hi un XPath arbitrari):
<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>Podeu adreçar la vista creada amb una consulta SQL (per exemple, mitjançant ODBC):
SELECT name, surname FROM Person WHERE name="John"Malauradament, la vista relacional creada per la plantilla de visualització és només de lectura. Quan es processi una sol·licitud, MarkLogic intentarà utilitzar-lo . Anteriorment, MarkLogic tenia visions relacionals limitades, completament i es pot escriure, però ara es consideren obsolets.
Model gràfic a MarkLogic
Amb el suport per al model de gràfics (RDF), tot és gairebé igual. De nou amb l'ajuda podeu crear una representació RDF d'una col·lecció de documents a partir de l'exemple anterior:
<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>Podeu abordar el gràfic RDF resultant amb una consulta SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}A diferència del relacional, MarkLogic admet el model gràfic d'altres dues maneres:
- Un SGBD pot ser un emmagatzematge independent complet de dades RDF (s'anomenaran els triplets que hi ha en contrast amb les descrites anteriorment ).
- RDF en serialització especial es pot inserir simplement en documents XML o JSON (i llavors s'anomenaran triplets ). Aquesta és probablement una alternativa als mecanismes
idrefetcètera
Una bona idea de com funcionen les coses "realment" a MarkLogic ve donada per , en aquest sentit, és de baix nivell, encara que la seva finalitat és més aviat la contrària: intentar abstraure's del model de dades utilitzat, garantir un treball coherent amb dades en diferents models, transaccionalitat, etc.
SGBD multimodel "sense model principal"
També hi ha DBMS al mercat que es posicionen com inicialment multimodel, sense cap model principal heretat. Això inclou , (des del 2018 l'empresa de desenvolupament pertany a SAP) i (servei com a part de la plataforma al núvol de Microsoft Azure).
De fet, hi ha models "bàsic" a ArangoDB i OrientDB. En ambdós casos, es tracta de models de dades propis, que són generalitzacions del document. Les generalitzacions són principalment per facilitar la capacitat de realitzar consultes de caràcter gràfic i relacional.
Aquests models són els únics disponibles per utilitzar-los al SGBD especificat; els seus propis llenguatges de consulta estan dissenyats per funcionar amb ells. Per descomptat, aquests models i SGBD són prometedors, però la manca de compatibilitat amb models i idiomes estàndard fa que sigui impossible utilitzar aquests SGBD en sistemes heretats, per substituir els SGBD que ja s'hi fan servir.
Ja hi havia un article meravellós sobre ArangoDB i OrientDB a Habré: .
ArangoDB
ArangoDB reclama suport per a un model de dades de gràfics.
Els nodes d'un gràfic a ArangoDB són documents ordinaris, i les vores són documents d'un tipus especial que, juntament amb els camps del sistema habituals, tenen (_key, _id, _rev) camps del sistema _from и _to. Els documents dels SGBD de documents es combinen tradicionalment en col·leccions. Les col·leccions de documents que representen les vores s'anomenen col·leccions d'arres a ArangoDB. Per cert, els documents de col·lecció de vora també són documents, de manera que les vores a ArangoDB també poden actuar com a nodes.
Dades primeres
Fem una col·lecció persons, els documents de la qual tenen aquest aspecte:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Que hi hagi també una col·lecció cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Després la col·lecció likes podria tenir aquest aspecte:
[
{
"_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
}
]Consultes i resultats
Una consulta d'estil gràfic en el llenguatge AQL utilitzat a ArangoDB, que retorna informació en forma llegible pels humans sobre a qui li agrada quina cafeteria, té aquest aspecte:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }En un estil relacional, on estem "computant" relacions en lloc d'emmagatzemar-les, aquesta consulta es pot reescriure així (per cert, sense la col·lecció likes podria prescindir):
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 }El resultat en tots dos casos serà el mateix:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Més consultes i resultats
Si el format del resultat anterior sembla ser més típic per a un SGBD relacional que per a un SGBD de document, podeu provar aquesta consulta (o podeu utilitzar ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}El resultat serà així:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
La base per implementar un model de gràfic a la part superior d'un model de document a OrientDB és els camps del document, a més de valors escalars més o menys estàndard, també tenen valors de tipus com ara LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Els valors d'aquests tipus són enllaços o col·leccions d'enllaços a documents.
L'identificador del document assignat pel sistema té un "significat físic", que indica la posició del registre a la base de dades, i té un aspecte com aquest: @rid : #3:16. Així, els valors de les propietats de referència són realment punters (com en el model de gràfic) més que condicions de selecció (com en el model relacional).
Igual que ArangoDB, les arestes a OrientDB es representen com a documents separats (tot i que si una vora no té les seves pròpies propietats, es pot fer , i no correspondrà a un document separat).
Dades primeres
En un format proper a Base de dades OrientDB, les dades de l'exemple anterior per a ArangoDB tindrien un aspecte semblant a això:
[
{
"@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"
}
]Com podem veure, els vèrtexs també emmagatzemen informació sobre les vores entrants i sortints. A les L'API de document ha de supervisar la pròpia integritat referencial i l'API Graph s'encarrega d'aquest treball. Però vegem com és l'accés a OrientDB en llenguatges de consulta "purs" que no estan integrats en llenguatges de programació.
Consultes i resultats
Una consulta similar en propòsit a la consulta de l'exemple per a ArangoDB a OrientDB té aquest aspecte:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameEl resultat s'obtindrà de la forma següent:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Si el format del resultat torna a semblar massa "relacional", heu d'eliminar la línia amb :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]El llenguatge de consulta d'OrientDB es pot descriure com SQL amb insercions semblants a Gremlin. A la versió 2.2, va aparèixer un formulari de sol·licitud similar 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_nameEl format del resultat serà el mateix que en la sol·licitud anterior. Penseu en què cal eliminar per fer-lo més "relacional", com en la primera consulta.
Azure CosmosDB
En menor mesura, el que es va dir anteriorment sobre ArangoDB i OrientDB s'aplica a Azure CosmosDB. CosmosDB proporciona les següents API d'accés a dades: SQL, MongoDB, Gremlin i Cassandra.
L'API SQL i l'API MongoDB s'utilitzen per accedir a les dades del model de document. API Gremlin i API Cassandra: per accedir a les dades en formats de gràfic i columna, respectivament. Les dades de tots els models es guarden en el format de model intern de CosmosDB: (“àtom-record-sequence”), que també s'acosta al document.
Però el model de dades escollit per l'usuari i l'API utilitzada es fixen en el moment de crear un compte al servei. No és possible accedir a les dades carregades en un model en el format d'un altre model, com s'il·lustra amb alguna cosa com això:
Així, el multimodel d'Azure CosmosDB és avui només la possibilitat d'utilitzar diverses bases de dades que admeten diferents models d'un fabricant, cosa que no resol tots els problemes d'emmagatzematge multivariant.
SGBD multimodel basat en un model gràfic?
Cal destacar el fet que no hi ha SGBD multimodel al mercat encara que es basin en un model de gràfic (excepte per al suport multimodel per a dos models de gràfics simultàniament: RDF i LPG; vegeu això a ). Les dificultats més grans es produeixen per la implementació d'un model de document a sobre d'un model de gràfic, més que no pas d'un de relacional.
La qüestió de com implementar un model relacional a la part superior del model gràfic es va considerar fins i tot durant la formació d'aquest últim. Com Per exemple, :
No hi ha res inherent a l'enfocament del gràfic que impedeixi crear una capa (per exemple, mitjançant una indexació adequada) en una base de dades de gràfics que permeti una visió relacional amb (1) recuperació de tuples dels parells de valors clau habituals i (2) agrupació de tuples per tipus de relació.
Quan implementeu un model de document a sobre d'un model de gràfic, heu de tenir en compte, per exemple, el següent:
- Els elements d'una matriu JSON es consideren ordenats, però els que emanen del vèrtex d'una vora del gràfic no ho són;
- Les dades del model de document solen estar desnormalitzades; encara no voleu emmagatzemar diverses còpies del mateix document incrustat, i els subdocuments normalment no tenen identificadors;
- D'altra banda, la ideologia dels SGBD de documents és que els documents són "agregats" ja fets que no cal que es tornin a construir cada vegada. Cal proporcionar al model de gràfic la capacitat d'obtenir ràpidament un subgraf corresponent al document acabat.
Una mica de publicitat
L'autor de l'article està relacionat amb el desenvolupament del SGBD NitrosBase, el model intern del qual és gràfic, i els models externs -relacionals i de document- són les seves representacions. Tots els models són iguals: gairebé totes les dades estan disponibles en qualsevol d'ells utilitzant un llenguatge de consulta que li és natural. A més, en qualsevol vista, les dades es poden canviar. Els canvis es reflectiran en el model intern i, en conseqüència, en altres visions.
Espero descriure com és la concordança de models a NitrosBase en un dels articles següents.
Conclusió
Espero que els contorns generals del que s'anomena multimodelització hagin quedat més o menys clars per al lector. Els SGBD multimodel són força diferents i el "suport multimodel" pot semblar diferent. Per entendre el que s'anomena "multimodel" en cada cas concret, és útil respondre les preguntes següents:
- Estem parlant de donar suport a models tradicionals o algun tipus de model "híbrid"?
- Els models són “iguals”, o un d'ells és el tema dels altres?
- Els models són "indiferents" els uns als altres? Les dades escrites en un model es poden llegir en un altre o fins i tot sobreescriure?
Crec que la pregunta sobre la rellevància dels DBMS multimodel ja es pot respondre positivament, però la pregunta interessant és quins tipus d'ells tindran més demanda en un futur proper. Sembla que els SGBD multimodel que admeten models tradicionals, principalment relacionals, tindran una major demanda; La popularitat dels SGBD multimodel, que ofereixen nous models que combinen els avantatges dels diversos tradicionals, és una qüestió d'un futur més llunyà.
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Utilitzeu DBMS multimodel?
No el fem servir, ho emmagatzemem tot en un SGBD i en un model
Utilitzem capacitats multimodel dels SGBD tradicionals
Practiquem la persistència políglota
Utilitzem nous SGBD multimodel (Arango, Orient, CosmosDB)
Han votat 19 usuaris. 4 usuaris es van abstenir.
Font: www.habr.com
