Os sistemas de información modernos son bastante complexos. Non menos importante, a súa complexidade débese á complexidade dos datos que nelas se procesan. A complexidade dos datos a miúdo reside na variedade de modelos de datos utilizados. Así, por exemplo, cando os datos se fan "grandes", unha das características problemáticas non é só o seu volume ("volume"), senón tamén a súa variedade ("variedade").
Se aínda non atopas un fallo no razoamento, continúa lendo.
Contido
Persistencia políglota
O anterior leva ao feito de que ás veces mesmo no marco dun sistema é necesario utilizar varios DBMS diferentes para almacenar datos e resolver varios problemas de procesamento dos cales, cada un deles admite o seu propio modelo de datos. Coa man lixeira de M. Fowler, unha serie de libros famosos e un de Manifesto Áxil, esta situación chámase almacenamento multivariante (“persistencia políglota”).
Fowler tamén ten o seguinte exemplo de organización do almacenamento de datos nunha aplicación con todas as funcións e de alta carga no campo do comercio electrónico.
Este exemplo, por suposto, é algo esaxerado, pero pódense atopar algunhas consideracións a favor de escoller un ou outro DBMS para o propósito correspondente, por exemplo, .
Está claro que ser criado nun zoolóxico así non é doado.
- A cantidade de código que realiza o almacenamento de datos crece en proporción ao número de DBMS utilizados; a cantidade de datos de sincronización do código é boa se non é proporcional ao cadrado deste número.
- Como múltiplo do número de SGBD utilizados, aumentan os custos de proporcionar características empresariais (escalabilidade, tolerancia a fallos, alta dispoñibilidade) de cada un dos SGBD utilizados.
- É imposible garantir as características empresariais do subsistema de almacenamento no seu conxunto, especialmente a transaccionalidade.
Desde o punto de vista do director do zoolóxico, todo se ve así:
- Un aumento múltiple do custo das licenzas e do soporte técnico do fabricante de DBMS.
- Exceso de persoal e aumento dos prazos.
- Perdas económicas directas ou sancións por incoherencia de datos.
Hai un aumento significativo no custo total de propiedade (TCO) do sistema. Hai algunha saída á situación de "múltiples opcións de almacenamento"?
Multimodelo
O termo "almacenamento multivariante" entrou en uso en 2011. A toma de conciencia dos problemas do enfoque e a busca dunha solución levou varios anos, e en 2015, por boca dos analistas de Gartner, formulouse a resposta:
- Desde ""
O futuro dos DBMS, as súas arquitecturas e as formas de usalos é multimodelo.
- Desde ""
Os DBMS operativos líderes ofrecerán varios modelos -relacionais e non-relacionais- como parte dunha única plataforma.
Parece que esta vez os analistas de Gartner acertaron coa súa previsión. Se vas á páxina con DBMS en DB-Engines, podes ver isoоA maioría dos seus líderes sitúanse especificamente como DBMS multimodelo. O mesmo pódese ver na páxina con calquera valoración privada.
A seguinte táboa mostra o DBMS: os líderes en cada unha das clasificacións privadas, que afirman ser multimodelo. Para cada DBMS indícase o modelo orixinal soportado (que antes foi o único) e xunto con el os modelos soportados actualmente. Tamén se enumeran os DBMS que se posicionan como "orixinalmente multimodelo" e, segundo os creadores, non teñen ningún modelo herdado inicial.
| DBMS | Modelo inicial | Modelos adicionais |
|---|---|---|
| oráculo | Relacional | Gráfico, documento |
| MS SQL | Relacional | Gráfico, documento |
| PostgreSQL | Relacional | Gráfico*, documento |
| MarkLogic | Documental | Gráfica, relacional |
| MongoDB | Documental | Clave-valor, gráfico* |
| DataStax | Columna ampla | Documental, gráfico |
| Redis | Clave-valor | Documental, gráfico* |
| ArangoDB | - | Gráfico, documento |
| OrientDB | - | Gráfico, documento, relacional |
| Azure CosmosDB | - | Gráfico, documento, relacional |
Notas sobre a mesa
Os asteriscos na táboa marcan as afirmacións que requiren reservas:
- O DBMS PostgreSQL non admite o modelo de datos de gráficos, pero este produto si o admite , como AgensGraph.
- En relación a MongoDB, é máis correcto falar da presenza de operadores gráficos na linguaxe de consulta (, ) que sobre o soporte do modelo gráfico, aínda que, por suposto, a súa introdución requiriu algunhas optimizacións a nivel de almacenamento físico no sentido de apoiar o modelo gráfico.
- En relación a Redis, queremos dicir a extensión .
A continuación, para cada unha das clases, mostraremos como se implementa o soporte para varios modelos no DBMS desta clase. Consideraremos os modelos relacionais, de documentos e gráficos como os máis importantes e empregaremos exemplos de DBMS específicos para mostrar como se implementan os "faltados".
DBMS multimodelo baseado no modelo relacional
Os principais DBMS actualmente son relacionais; a previsión de Gartner non podería considerarse verdadeira se os RDBMS non mostrasen movemento na dirección do multimodelado. E demostran. Agora a idea de que un DBMS multimodelo é como un coitelo suízo, que non pode facer nada ben, pódese dirixir directamente a Larry Ellison.
O autor, con todo, prefire a implementación do multimodelado en Microsoft SQL Server, sobre o que se describirá o soporte RDBMS para modelos de documentos e gráficos.
Modelo de documento en MS SQL Server
Xa houbo dous excelentes artigos sobre Habré sobre como MS SQL Server implementa soporte para o modelo de documento; limitareime a un breve relato e comentario:
A forma de admitir o modelo de documento en MS SQL Server é bastante típica para os DBMS relacionais: proponse que os documentos JSON se almacenen en campos de texto comúns. O soporte para o modelo de documento é proporcionar operadores especiais para analizar este JSON:
- para extraer valores de atributos escalares,
- para extraer subdocumentos.
O segundo argumento de ambos os operadores é unha expresión en sintaxe tipo JSONPath.
De xeito abstracto, podemos dicir que os documentos almacenados deste xeito non son "entidades de primeira clase" nun DBMS relacional, a diferenza das tuplas. En concreto, en MS SQL Server actualmente non hai índices nos campos dos documentos JSON, o que dificulta a unión de táboas utilizando os valores destes campos e mesmo a selección de documentos mediante estes valores. Non obstante, é posible crear unha columna calculada para tal campo e un índice sobre ela.
Ademais, MS SQL Server ofrece a posibilidade de construír convenientemente un documento JSON a partir do contido das táboas usando o operador - unha posibilidade, en certo sentido, contraria á anterior, o almacenamento convencional. Está claro que non importa o rápido que sexa un RDBMS, este enfoque contradí a ideoloxía dos DBMS de documentos, que esencialmente almacenan respostas preparadas a consultas populares, e só poden resolver problemas de facilidade de desenvolvemento, pero non de velocidade.
Finalmente, MS SQL Server permítelle resolver o problema oposto da construción do documento: pode descompoñer JSON en táboas usando . Se o documento non é completamente plano, terás que utilizalo CROSS APPLY.
Modelo gráfico en MS SQL Server
O soporte para o modelo gráfico (LPG) tamén está totalmente implementado en Microsoft SQL Server : proponse o uso de táboas especiais para almacenar nós e para almacenar bordos de gráficos. Tales táboas créanse mediante expresións CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectivamente.
As táboas do primeiro tipo son similares ás táboas ordinarias para almacenar rexistros, coa única diferenza externa é que a táboa contén un campo do sistema $node_id — identificador único dun nodo gráfico dentro da base de datos.
Do mesmo xeito, as táboas do segundo tipo teñen campos do sistema $from_id и $to_id, as entradas destas táboas definen claramente as conexións entre nós. Utilízase unha táboa separada para almacenar relacións de cada tipo.
Ilustremos isto cun exemplo. Deixa que os datos do gráfico teñan un esquema como o que se mostra na figura. A continuación, para crear a estrutura correspondente na base de datos, cómpre executar as seguintes consultas DDL:
CREATE TABLE Person (
ID INTEGER NOT NULL,
name VARCHAR(100)
) AS NODE;
CREATE TABLE Cafe (
ID INTEGER NOT NULL,
name VARCHAR(100),
) AS NODE;
CREATE TABLE likes (
rating INTEGER
) AS EDGE;
CREATE TABLE friendOf
AS EDGE;
ALTER TABLE likes
ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);A principal especificidade destas táboas é que nas consultas contra elas é posible usar patróns gráficos con sintaxe tipo Cypher (non obstante, "*"etc. aínda non son compatibles). En función das medicións de rendemento, tamén se pode supoñer que a forma en que se almacenan os datos nestas táboas é diferente da forma en que se almacenan os datos nas táboas normais e está optimizada para executar tales consultas de gráficos.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Ademais, é bastante difícil non usar estes patróns de gráficos cando se traballa con tales táboas, xa que nas consultas SQL ordinarias para resolver problemas similares será necesario facer esforzos adicionais para obter identificadores de nodos "gráficos" do sistema ($node_id, $from_id, $to_id; Polo mesmo motivo, as consultas para inserir datos non se mostran aquí xa que son innecesariamente engorrosas).
Para resumir a descrición das implementacións dos modelos de documentos e gráficos en MS SQL Server, notaría que este tipo de implementacións dun modelo sobre outro non parecen exitosas, principalmente dende o punto de vista do deseño da linguaxe. É necesario estender unha lingua con outra, as linguas non son completamente "ortogonais", as regras de compatibilidade poden ser bastante estrañas.
DBMS multimodelo baseado no modelo de documento
Nesta sección, gustaríame ilustrar a implementación do multimodelo nos DBMS de documentos usando o exemplo do non máis popular deles, MongoDB (como se dixo, só ten operadores gráficos condicionais). $lookup и $graphLookup, non traballando en coleccións fragmentadas), pero usando o exemplo dun DBMS máis maduro e "empresarial" .
Entón, deixe que a colección conteña un conxunto de documentos XML do seguinte tipo (MarkLogic tamén che permite almacenar documentos JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Modelo relacional en MarkLogic
Pódese crear unha vista relacional dunha colección de documentos usando (contido dos elementos value no seguinte exemplo pode haber 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>Podes abordar a vista creada cunha consulta SQL (por exemplo, a través de ODBC):
SELECT name, surname FROM Person WHERE name="John"Desafortunadamente, a vista relacional creada polo modelo de visualización é de só lectura. Ao procesar unha solicitude para iso, MarkLogic tentará utilizalo . Anteriormente, MarkLogic tiña visións relacionais limitadas, totalmente e escribibles, pero agora considéranse obsoletos.
Modelo gráfico en MarkLogic
Co soporte para o modelo gráfico (RDF), todo é máis ou menos igual. De novo coa axuda pode crear unha representación RDF dunha colección de documentos a partir do exemplo 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>Podes abordar o gráfico RDF resultante cunha consulta SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}A diferenza do relacional, MarkLogic admite o modelo gráfico doutras dúas formas:
- Un DBMS pode ser un almacenamento separado completo de datos RDF (chamaranse trillizos nel en contraste cos descritos anteriormente ).
- RDF en serialización especial pódese simplemente inserir en documentos XML ou JSON (e entón chamaranse trillizos ). Esta é probablemente unha alternativa aos mecanismos
idrefetc
Unha boa idea de como funcionan "realmente" as cousas en MarkLogic vén dada por , neste sentido, é de baixo nivel, aínda que a súa finalidade é máis ben a contraria: tentar abstraer do modelo de datos empregado, garantir un traballo coherente cos datos en diferentes modelos, transaccionalidade, etc.
DBMS multimodelo "sen un modelo principal"
Tamén existen no mercado DBMS que se posicionan como inicialmente multimodelo, sen ningún modelo principal herdado. Estes inclúen , (desde 2018 a empresa de desenvolvemento pertence a SAP) e (servizo como parte da plataforma cloud Microsoft Azure).
De feito, hai modelos "núcleos" en ArangoDB e OrientDB. En ambos os casos, trátase de modelos de datos propios, que son xeneralizacións do documento. As xeralizacións son principalmente para facilitar a capacidade de realizar consultas de carácter gráfico e relacional.
Estes modelos son os únicos dispoñibles para o seu uso no DBMS especificado; as súas propias linguaxes de consulta están deseñadas para funcionar con eles. Por suposto, tales modelos e DBMS son prometedores, pero a falta de compatibilidade con modelos e linguaxes estándar fai imposible usar estes DBMS en sistemas legados, para substituír os DBMS que xa se usan alí.
Xa había un artigo marabilloso sobre ArangoDB e OrientDB en Habré: .
ArangoDB
ArangoDB reclama soporte para un modelo de datos gráficos.
Os nodos dun gráfico en ArangoDB son documentos ordinarios e os bordos son documentos de tipo especial que, xunto cos campos do sistema habituais, teñen (_key, _id, _rev) campos do sistema _from и _to. Os documentos dos DBMS de documentos combínanse tradicionalmente en coleccións. As coleccións de documentos que representan bordes chámanse coleccións de bordes en ArangoDB. Por certo, os documentos de recollida de bordes tamén son documentos, polo que os bordos en ArangoDB tamén poden actuar como nós.
Datos iniciais
Imos facer unha colección persons, cuxos documentos se ven así:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Que haxa tamén unha colección cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Despois a colección likes pode ter este aspecto:
[
{
"_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
}
]Consultas e resultados
Unha consulta de estilo gráfico na linguaxe AQL usada en ArangoDB, que devolve en forma lexible información sobre a quen lle gusta que cafetería, ten o seguinte aspecto:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Nun estilo relacional, no que estamos "calculando" relacións en lugar de almacenalas, esta consulta pódese reescribir así (por certo, sen a colección likes podería 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 }O resultado en ambos casos será o mesmo:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Máis consultas e resultados
Se o formato de resultado anterior parece ser máis típico para un SGBD relacional que para un SGBD de documentos, pode probar esta consulta (ou pode utilizar ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}O resultado será así:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
A base para implementar un modelo gráfico enriba dun modelo de documento en OrientDB é os campos do documento, ademais de valores escalares máis ou menos estándar, tamén teñen valores de tipos como LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Os valores destes tipos son ligazóns ou coleccións de ligazóns a documentos.
O identificador do documento asignado polo sistema ten un "significado físico", que indica a posición do rexistro na base de datos, e ten un aspecto así: @rid : #3:16. Así, os valores das propiedades de referencia son realmente punteiros (como no modelo gráfico) e non condicións de selección (como no modelo relacional).
Do mesmo xeito que ArangoDB, os bordos en OrientDB represéntanse como documentos separados (aínda que se un bordo non ten as súas propias propiedades, pódese facer , e non corresponderá a un documento separado).
Datos iniciais
Nun formato próximo a Base de datos OrientDB, os datos do exemplo anterior para ArangoDB serían algo así:
[
{
"@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"
}
]Como podemos ver, os vértices tamén almacenan información sobre os bordos entrantes e saíntes. Ás A API de documentos ten que supervisar a propia integridade referencial e a API de Graph asume este traballo. Pero vexamos como é o acceso a OrientDB en linguaxes de consulta "puras" que non están integradas nas linguaxes de programación.
Consultas e resultados
Unha consulta similar en propósito á consulta do exemplo para ArangoDB en OrientDB ten o seguinte aspecto:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameO resultado obterase da seguinte forma:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Se o formato do resultado volve parecer demasiado "relacional", debes eliminar a liña con :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]A linguaxe de consulta de OrientDB pódese describir como SQL con insercións tipo Gremlin. Na versión 2.2, apareceu un formulario de solicitude tipo 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_nameO formato do resultado será o mesmo que na solicitude anterior. Pensa no que hai que eliminar para facelo máis "relacional", como na primeira consulta.
Azure CosmosDB
En menor medida, o que se dixo anteriormente sobre ArangoDB e OrientDB aplícase a Azure CosmosDB. CosmosDB ofrece as seguintes API de acceso a datos: SQL, MongoDB, Gremlin e Cassandra.
SQL API e MongoDB API utilízanse para acceder aos datos no modelo de documento. Gremlin API e Cassandra API: para acceder a datos en formatos de gráfico e columna, respectivamente. Os datos de todos os modelos gárdanse no formato de modelo interno de CosmosDB: (“atom-record-sequence”), que tamén é próxima á do documento.
Pero o modelo de datos escollido polo usuario e a API utilizada están fixados no momento de crear unha conta no servizo. Non é posible acceder aos datos cargados nun modelo no formato doutro modelo, como se ilustra con algo así:
Así, o multimodelo en Azure CosmosDB é hoxe só a posibilidade de usar varias bases de datos que admiten diferentes modelos dun fabricante, o que non resolve todos os problemas de almacenamento multivariante.
DBMS multimodelo baseado nun modelo gráfico?
Cabe destacar o feito de que non existen no mercado DBMS multimodelo aínda que estean baseados nun modelo gráfico (excepto polo soporte multimodelo para dous modelos de gráficos simultáneamente: RDF e LPG; vexa isto en ). As maiores dificultades prodúcense a implementación dun modelo de documento encima dun modelo gráfico, en lugar dun relacional.
A cuestión de como implementar un modelo relacional enriba do modelo gráfico considerouse mesmo durante a formación deste último. Como por exemplo :
Non hai nada inherente ao enfoque gráfico que impida crear unha capa (por exemplo, mediante unha indexación adecuada) nunha base de datos de gráficos que permita unha vista relacional con (1) recuperación de tuplas dos pares de valores de clave habituais e (2) agrupación de tuplas por tipo de relación.
Ao implementar un modelo de documento encima dun modelo gráfico, debes ter en conta, por exemplo, o seguinte:
- Os elementos dunha matriz JSON considéranse ordenados, pero os que emanan do vértice dun bordo do gráfico non o son;
- Os datos do modelo de documento adoitan estar desnormalizados; aínda non queres almacenar varias copias do mesmo documento incrustado e os subdocumentos normalmente non teñen identificadores;
- Por outra banda, a ideoloxía dos DBMS de documentos é que os documentos son "agregados" preparados que non precisan ser construídos de novo cada vez. Requírese proporcionar ao modelo gráfico a capacidade de obter rapidamente un subgráfico correspondente ao documento rematado.
Un pouco de publicidade
O autor do artigo está relacionado co desenvolvemento do DBMS NitrosBase, cuxo modelo interno é gráfico, e os modelos externos -relacionais e de documentos- son as súas representacións. Todos os modelos son iguais: case todos os datos están dispoñibles en calquera deles utilizando unha linguaxe de consulta que lle é natural. Ademais, en calquera vista, os datos pódense cambiar. Os cambios reflectiranse no modelo interno e, en consecuencia, noutras vistas.
Espero que describirei como é a coincidencia de modelos en NitrosBase nun dos seguintes artigos.
Conclusión
Espero que os trazos xerais do que se chama multimodelado queden máis ou menos claros para o lector. Os DBMS multimodelo son bastante diferentes e o "soporte multimodelo" pode parecer diferente. Para comprender o que se chama "multimodelo" en cada caso concreto, é útil responder ás seguintes preguntas:
- Estamos a falar de apoiar modelos tradicionais ou algún tipo de modelo "híbrido"?
- Os modelos son “iguais”, ou un deles é o tema dos demais?
- Son os modelos "indiferentes" entre si? Os datos escritos nun modelo pódense ler noutro ou mesmo sobrescribirse?
Creo que a pregunta sobre a relevancia do DBMS multimodelo xa se pode responder positivamente, pero a pregunta interesante é que tipos deles serán máis demandados nun futuro próximo. Parece que os DBMS multimodelo que admiten modelos tradicionais, principalmente relacionais, terán unha maior demanda; a popularidade dos DBMS multimodelo, que ofrecen novos modelos que combinan as vantaxes de varios tradicionais, é unha cuestión de futuro máis afastado.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Usas DBMS multimodelo?
-
Non o usamos, almacenamos todo nun DBMS e nun modelo
-
Usamos capacidades multimodelo dos DBMS tradicionais
-
Practicamos a persistencia políglota
-
Usamos novos DBMS multimodelo (Arango, Orient, CosmosDB)
Votaron 19 usuarios. 4 usuarios abstivéronse.
Fonte: www.habr.com