Los sistemas de información modernos son bastante complejos. Su complejidad se debe no menos importante a la complejidad de los datos que en ellos se procesan. La complejidad de los datos a menudo reside en la variedad de modelos de datos utilizados. Así, por ejemplo, cuando los datos se vuelven “grandes”, una de las características problemáticas no es sólo su volumen (“volumen”), sino también su variedad (“variedad”).
Si aún no encuentra ningún defecto en el razonamiento, siga leyendo.
contenido
persistencia políglota
Lo anterior lleva al hecho de que a veces, incluso dentro del marco de un sistema, es necesario utilizar varios DBMS diferentes para almacenar datos y resolver diversos problemas de procesamiento, cada uno de los cuales admite su propio modelo de datos. Con la mano ligera del señor Fowler, varios libros famosos y uno de Manifiesto Ágil, esta situación se llama almacenamiento multivariante (“persistencia políglota”).
Fowler también tiene el siguiente ejemplo de organización del almacenamiento de datos en una aplicación con todas las funciones y de alta carga en el campo del comercio electrónico.
Este ejemplo, por supuesto, es algo exagerado, pero se pueden encontrar algunas consideraciones a favor de elegir uno u otro DBMS para el propósito correspondiente, por ejemplo, .
Está claro que ser sirviente en un zoológico así no es fácil.
- La cantidad de código que realiza el almacenamiento de datos crece en proporción a la cantidad de DBMS utilizados; la cantidad de código que sincroniza datos es buena si no es proporcional al cuadrado de este número.
- Como múltiplo de la cantidad de DBMS utilizados, aumentan los costos de proporcionar características empresariales (escalabilidad, tolerancia a fallas, alta disponibilidad) de cada uno de los DBMS utilizados.
- Es imposible garantizar las características empresariales del subsistema de almacenamiento en su conjunto, especialmente la transaccionalidad.
Desde el punto de vista del director del zoológico, todo se ve así:
- Un aumento múltiple en el costo de las licencias y el soporte técnico del fabricante del DBMS.
- Exceso de personal y aumento de plazos.
- Pérdidas financieras directas o sanciones debido a la inconsistencia de los datos.
Hay un aumento significativo en el costo total de propiedad (TCO) del sistema. ¿Existe alguna salida a la situación de “múltiples opciones de almacenamiento”?
Multimodelo
El término "almacenamiento multivariado" se empezó a utilizar en 2011. La conciencia de los problemas del enfoque y la búsqueda de una solución tomó varios años, y en 2015, por boca de los analistas de Gartner, se formuló la respuesta:
- Desde "»:
El futuro de los DBMS, sus arquitecturas y formas de utilizarlos es multimodelo.
- Desde "»:
Los DBMS operativos líderes ofrecerán múltiples modelos (relacionales y no relacionales) como parte de una única plataforma.
Parece que esta vez los analistas de Gartner acertaron con su previsión. Si vas a la página con DBMS en DB-Engines, puedes ver esoоLa mayoría de sus líderes se posicionan específicamente como DBMS multimodelo. Lo mismo se puede ver en la página con cualquier calificación privada.
La siguiente tabla muestra los DBMS, los líderes en cada una de las calificaciones privadas, que afirman ser multimodelo. Para cada DBMS, se indica el modelo soportado original (que alguna vez fue el único) y junto con él los modelos actualmente soportados. También se enumeran los DBMS que se posicionan como “originalmente multimodelo” y, según sus creadores, no tienen ningún modelo heredado inicial.
| DBMS | Modelo inicial | Modelos adicionales |
|---|---|---|
| Oracle | relacional | gráfico, documento |
| MS SQL | relacional | gráfico, documento |
| PostgreSQL | relacional | Gráfico*, documento |
| MarkLogic | Documental | Grafico, relacional |
| MongoDB | Documental | Valor-clave, gráfico* |
| DataStax | columna ancha | Documental, gráfico |
| Redis | Valor clave | Documental, gráfico* |
| ArangoDB | - | gráfico, documento |
| OrientDB | - | Gráfico, documento, relacional. |
| Azure Cosmos DB | - | Gráfico, documento, relacional. |
Notas a la mesa.
Los asteriscos en la tabla marcan declaraciones que requieren reservas:
- El DBMS PostgreSQL no es compatible con el modelo de datos de gráficos, pero este producto sí lo admite. , como AgensGraph.
- En relación con MongoDB, es más correcto hablar de la presencia de operadores gráficos en el lenguaje de consulta (, ) que sobre soportar el modelo gráfico, aunque, por supuesto, su introducción requirió algunas optimizaciones en el nivel de almacenamiento físico en la dirección de soportar el modelo gráfico.
- En relación con Redis, nos referimos a la extensión. .
A continuación, para cada una de las clases, mostraremos cómo se implementa el soporte para varios modelos en el DBMS de esta clase. Consideraremos los modelos relacionales, de documentos y de gráficos como los más importantes y usaremos ejemplos de DBMS específicos para mostrar cómo se implementan los “faltantes”.
DBMS multimodelo basado en el modelo relacional
Los DBMS líderes en la actualidad son los relacionales; el pronóstico de Gartner no podría considerarse cierto si los RDBMS no mostraran un movimiento en la dirección del multimodelado. Y lo demuestran. Ahora bien, la idea de que un DBMS multimodelo es como una navaja suiza, que no puede hacer nada bien, puede dirigirse directamente a Larry Ellison.
El autor, sin embargo, prefiere la implementación del modelado múltiple en Microsoft SQL Server, en cuyo ejemplo se describirá el soporte RDBMS para modelos de documentos y gráficos.
Modelo de documento en MS SQL Server
Habré ya ha publicado dos excelentes artículos sobre cómo MS SQL Server implementa el soporte para el modelo de documento, me limitaré a un breve recuento y comentario:
La forma de admitir el modelo de documento en MS SQL Server es bastante típica de los DBMS relacionales: se propone almacenar documentos JSON en campos de texto normales. La compatibilidad con el modelo de documento consiste en proporcionar operadores especiales para analizar este JSON:
- para extraer valores de atributos escalares,
- para extraer subdocumentos.
El segundo argumento de ambos operadores es una expresión en sintaxis similar a JSONPath.
De manera abstracta, podemos decir que los documentos almacenados de esta manera no son "entidades de primera clase" en un DBMS relacional, a diferencia de las tuplas. En concreto, en MS SQL Server actualmente no existen índices sobre los campos de los documentos JSON, lo que dificulta unir tablas usando los valores de estos campos e incluso seleccionar documentos usando estos valores. Sin embargo, es posible crear una columna calculada para dicho campo y un índice en él.
Además, MS SQL Server ofrece la posibilidad de construir cómodamente un documento JSON a partir del contenido de las tablas utilizando el operador - una posibilidad, en cierto sentido, opuesta a la anterior, el almacenamiento convencional. Está claro que no importa qué tan rápido sea un RDBMS, este enfoque contradice la ideología de los DBMS de documentos, que esencialmente almacenan respuestas listas para usar a consultas populares y solo pueden resolver problemas de facilidad de desarrollo, pero no de velocidad.
Finalmente, MS SQL Server le permite resolver el problema opuesto de la construcción de documentos: puede descomponer JSON en tablas usando . Si el documento no es completamente plano, necesitarás usar CROSS APPLY.
Modelo gráfico en MS SQL Server
El soporte para el modelo gráfico (LPG) también está completamente implementado en Microsoft SQL Server. : Se propone utilizar tablas especiales para almacenar nodos y almacenar bordes de gráficos. Estas tablas se crean utilizando expresiones. CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectivamente.
Las tablas del primer tipo son similares a las tablas ordinarias para almacenar registros, con la única diferencia externa que la tabla contiene un campo del sistema. $node_id — identificador único de un nodo gráfico dentro de la base de datos.
De manera similar, las tablas del segundo tipo tienen campos del sistema. $from_id и $to_id, las entradas en dichas tablas definen claramente las conexiones entre nodos. Se utiliza una tabla separada para almacenar relaciones de cada tipo.
Ilustremos esto con un ejemplo. Deje que los datos del gráfico tengan un diseño como el que se muestra en la figura. Luego, para crear la estructura correspondiente en la base de datos, debe ejecutar las siguientes 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);La principal especificidad de este tipo de tablas es que en las consultas sobre ellas es posible utilizar patrones de gráficos con sintaxis similar a Cypher (sin embargo, "*"etc. aún no son compatibles). Según las mediciones de rendimiento, también se puede suponer que la forma en que se almacenan los datos en estas tablas es diferente de la forma en que se almacenan los datos en tablas normales y está optimizada para ejecutar dichas consultas de gráficos.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Además, es bastante difícil no utilizar estos patrones de gráficos cuando se trabaja con este tipo de tablas, ya que en consultas SQL ordinarias para resolver problemas similares será necesario hacer esfuerzos adicionales para obtener los identificadores de nodos del "gráfico" del sistema ($node_id, $from_id, $to_id; Por la misma razón, las consultas para insertar datos no se muestran aquí porque son innecesariamente engorrosas).
Para resumir la descripción de las implementaciones de los modelos de documentos y gráficos en MS SQL Server, señalaría que tales implementaciones de un modelo sobre otro no parecen exitosas, principalmente desde el punto de vista del diseño del lenguaje. Es necesario ampliar un idioma con otro, los idiomas no son completamente “ortogonales”, las reglas de compatibilidad pueden ser bastante extrañas.
DBMS multimodelo basado en el modelo de documento.
En esta sección, me gustaría ilustrar la implementación de múltiples modelos en DBMS de documentos usando el ejemplo del no más popular de ellos, MongoDB (como se dijo, solo tiene operadores de gráficos condicionales $lookup и $graphLookup, no trabajando en colecciones fragmentadas), pero usando el ejemplo de un DBMS más maduro y "empresarial" .
Entonces, deje que la colección contenga un conjunto de documentos XML del siguiente tipo (MarkLogic también le permite almacenar documentos JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Modelo relacional en MarkLogic
Se puede crear una vista relacional de una colección de documentos usando (contenido de elementos value en el siguiente ejemplo puede 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>Puede abordar la vista creada con una consulta SQL (por ejemplo, a través de ODBC):
SELECT name, surname FROM Person WHERE name="John"Desafortunadamente, la vista relacional creada por la plantilla para mostrar es de solo lectura. Al procesar una solicitud, MarkLogic intentará utilizar . Anteriormente, MarkLogic tenía vistas relacionales limitadas, completamente y se pueden escribir, pero ahora se consideran obsoletos.
Modelo gráfico en MarkLogic
Con soporte para el modelo gráfico (RDF), todo es más o menos igual. De nuevo con la ayuda puede crear una representación RDF de una colección de documentos a partir del ejemplo 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>Puede abordar el gráfico RDF resultante con una consulta SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}A diferencia del relacional, MarkLogic admite el modelo gráfico de otras dos formas:
- Un DBMS puede ser un almacenamiento separado completo de datos RDF (los tripletes que contiene se llamarán a diferencia de los descritos anteriormente ).
- RDF en serialización especial se puede insertar simplemente en documentos XML o JSON (y luego se llamarán tripletes ). Esta es probablemente una alternativa a los mecanismos.
idrefetcétera
Una buena idea de cómo funcionan “realmente” las cosas en MarkLogic la da , en este sentido, es de bajo nivel, aunque su propósito es más bien el contrario: intentar abstraerse del modelo de datos utilizado, asegurar un trabajo coherente con datos en diferentes modelos, transaccionalidad, etc.
DBMS multimodelo “sin modelo principal”
También existen en el mercado DBMS que se posicionan inicialmente como multimodelo, sin ningún modelo principal heredado. Éstas incluyen , (desde 2018 la empresa desarrolladora pertenece a SAP) y (servicio como parte de la plataforma en la nube de Microsoft Azure).
De hecho, existen modelos "centrales" en ArangoDB y OrientDB. En ambos casos se trata de modelos de datos propios, que son generalizaciones del modelo documental. Las generalizaciones son principalmente para facilitar la capacidad de realizar consultas de naturaleza gráfica y relacional.
Estos modelos son los únicos disponibles para su uso en el DBMS especificado; sus propios lenguajes de consulta están diseñados para funcionar con ellos. Por supuesto, estos modelos y DBMS son prometedores, pero la falta de compatibilidad con modelos y lenguajes estándar hace imposible utilizar estos DBMS en sistemas heredados para reemplazar los DBMS que ya se utilizan allí.
Ya había un artículo maravilloso sobre ArangoDB y OrientDB en Habré: .
ArangoDB
ArangoDB afirma ser compatible con un modelo de datos gráficos.
Los nodos de un gráfico en ArangoDB son documentos ordinarios y los bordes son documentos de un tipo especial que, junto con los campos habituales del sistema, tienen (_key, _id, _rev) campos del sistema _from и _to. Los documentos de los DBMS de documentos se combinan tradicionalmente en colecciones. Las colecciones de documentos que representan bordes se denominan colecciones de bordes en ArangoDB. Por cierto, los documentos de la colección de bordes también son documentos, por lo que los bordes en ArangoDB también pueden actuar como nodos.
Datos iniciales
Tengamos una colección persons, cuyos documentos se ven así:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Que también haya una colección. cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Entonces la colección likes podría verse así:
[
{
"_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 y resultados
Una consulta de estilo gráfico en el lenguaje AQL utilizado en ArangoDB, que devuelve en formato legible por humanos información sobre a quién le gusta qué café, se ve así:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }En un estilo relacional, donde estamos "calculando" relaciones en lugar de almacenarlas, esta consulta se puede reescribir así (por cierto, sin la colección likes podrí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 }El resultado en ambos casos será el mismo:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Más consultas y resultados
Si el formato de resultado anterior parece ser más típico de un DBMS relacional que de un DBMS de documento, puede probar esta consulta (o puede usar ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}El resultado se verá así:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
La base para implementar un modelo gráfico sobre un modelo de documento en OrientDB es Los campos del documento, además de valores escalares más o menos estándar, también tienen valores de tipos como LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Los valores de estos tipos son enlaces o colecciones de enlaces a documentos.
El identificador del documento asignado por el sistema tiene un “significado físico”, que indica la posición del registro en la base de datos, y se parece a esto: @rid : #3:16. Por tanto, los valores de las propiedades de referencia son en realidad punteros (como en el modelo gráfico) en lugar de condiciones de selección (como en el modelo relacional).
Al igual que ArangoDB, los bordes en OrientDB se representan como documentos separados (aunque si un borde no tiene sus propias propiedades, se puede hacer , y no corresponderá a un documento aparte).
Datos iniciales
En un formato cercano a Base de datos OrientDB, los datos del ejemplo anterior para ArangoDB se verían 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, los vértices también almacenan información sobre las aristas entrantes y salientes. En La API de documentos tiene que monitorear la integridad referencial en sí misma, y la API de gráficos se encarga de este trabajo. Pero veamos cómo se ve el acceso a OrientDB en lenguajes de consulta "puros" que no están integrados en los lenguajes de programación.
Consultas y resultados
Una consulta similar en propósito a la consulta del ejemplo para ArangoDB en OrientDB se ve así:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameEl resultado se obtendrá de la siguiente forma:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Si el formato del resultado nuevamente parece demasiado "relacional", debe eliminar la línea con :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]El lenguaje de consulta de OrientDB se puede describir como SQL con inserciones similares a Gremlin. En la versión 2.2, apareció un formulario de solicitud 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 formato del resultado será el mismo que en la solicitud anterior. Piense en lo que debe eliminarse para hacerlo más "relacional", como en la primera consulta.
Azure Cosmos DB
En menor medida, lo dicho anteriormente sobre ArangoDB y OrientDB se aplica a Azure CosmosDB. CosmosDB proporciona las siguientes API de acceso a datos: SQL, MongoDB, Gremlin y Cassandra.
La API de SQL y la API de MongoDB se utilizan para acceder a los datos en el modelo de documento. Gremlin API y Cassandra API: para acceder a datos en formatos de gráfico y columna, respectivamente. Los datos de todos los modelos se guardan en el formato del modelo interno de CosmosDB: (“atom-record-sequence”), que también está cerca del documento.
Pero el modelo de datos elegido por el usuario y la API utilizada se fijan en el momento de crear una cuenta en el servicio. No es posible acceder a los datos cargados en un modelo en el formato de otro modelo, como se ilustra con algo como esto:
Por lo tanto, hoy en día, el multimodelo en Azure CosmosDB es solo la capacidad de utilizar varias bases de datos que admitan diferentes modelos de un fabricante, lo que no resuelve todos los problemas del almacenamiento multivariante.
¿DBMS multimodelo basado en un modelo gráfico?
Cabe destacar el hecho de que todavía no existen en el mercado DBMS multimodelo que se basen en un modelo gráfico (a excepción del soporte multimodelo para dos modelos gráficos simultáneamente: RDF y LPG; consulte esto en ). Las mayores dificultades surgen de la implementación de un modelo de documento sobre un modelo de gráfico, en lugar de uno relacional.
La cuestión de cómo implementar un modelo relacional sobre el modelo gráfico se consideró incluso durante la formación de este último. Cómo Por ejemplo, :
No hay nada inherente en el enfoque gráfico que impida crear una capa (por ejemplo, mediante una indexación adecuada) en una base de datos gráfica que permita una vista relacional con (1) recuperación de tuplas de los pares clave-valor habituales y (2) agrupación de tuplas por tipo de relación.
Al implementar un modelo de documento sobre un modelo de gráfico, es necesario tener en cuenta, por ejemplo, lo siguiente:
- Los elementos de una matriz JSON se consideran ordenados, pero los que emanan del vértice de un borde del gráfico no;
- Los datos en el modelo de documento generalmente no están normalizados; aún así, no desea almacenar varias copias del mismo documento incrustado y los subdocumentos generalmente no tienen identificadores;
- Por otro lado, la ideología de los DBMS de documentos es que los documentos son “agregados” ya preparados que no necesitan construirse de nuevo cada vez. Se requiere dotar al modelo gráfico de la capacidad de obtener rápidamente un subgrafo correspondiente al documento terminado.
Algo de publicidad
El autor del artículo está relacionado con el desarrollo del DBMS NitrosBase, cuyo modelo interno es gráfico, y los modelos externos (relacional y documental) son sus representaciones. Todos los modelos son iguales: casi todos los datos están disponibles en cualquiera de ellos mediante un lenguaje de consulta que le resulta natural. Además, en cualquier vista, los datos se pueden cambiar. Los cambios se reflejarán en el modelo interno y, en consecuencia, en otras vistas.
Con suerte describiré cómo se ve la coincidencia de modelos en NitrosBase en uno de los siguientes artículos.
Conclusión
Espero que las líneas generales de lo que se llama multimodelado hayan quedado más o menos claras para el lector. Los DBMS multimodelo son bastante diferentes y el “soporte multimodelo” puede verse diferente. Para entender lo que se denomina “multimodelo” en cada caso concreto, conviene responder a las siguientes preguntas:
- ¿Estamos hablando de apoyar modelos tradicionales o algún tipo de modelo “híbrido”?
- ¿Son los modelos “iguales” o uno de ellos es sujeto de los demás?
- ¿Son los modelos “indiferentes” entre sí? ¿Se pueden leer los datos escritos en un modelo en otro o incluso sobrescribirlos?
Creo que la pregunta sobre la relevancia de los DBMS multimodelo ya se puede responder positivamente, pero lo interesante es qué tipos de ellos tendrán más demanda en el futuro próximo. Parece que los DBMS multimodelo que soportan modelos tradicionales, principalmente relacionales, tendrán una mayor demanda; La popularidad de los DBMS multimodelo, que ofrecen nuevos modelos que combinan las ventajas de varios modelos tradicionales, es una cuestión de un futuro más lejano.
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Utiliza DBMS multimodelo?
-
No lo usamos, almacenamos todo en un DBMS y en un modelo.
-
Utilizamos capacidades multimodelo de los DBMS tradicionales.
-
Practicamos la persistencia políglota
-
Utilizamos nuevos DBMS multimodelo (Arango, Orient, CosmosDB)
19 usuarios votaron. 4 usuarios se abstuvieron.
Fuente: habr.com