Os sistemas de informação modernos são bastante complexos. Não menos importante, a sua complexidade deve-se à complexidade dos dados neles tratados. A complexidade dos dados geralmente reside na variedade de modelos de dados utilizados. Assim, por exemplo, quando os dados se tornam “grandes”, uma das características problemáticas não é apenas o seu volume (“volume”), mas também a sua variedade (“variedade”).
Se você ainda não encontrou uma falha no raciocínio, continue lendo.
Conteúdo
persistência poliglota
O que foi dito acima leva ao fato de que às vezes, mesmo dentro da estrutura de um sistema, é necessário usar vários SGBDs diferentes para armazenar dados e resolver vários problemas de processamento deles, cada um dos quais suporta seu próprio modelo de dados. Com a mão leve de M. Fowler, vários livros famosos e um dos Manifesto Ágil, esta situação é chamada armazenamento multivariante (“persistência poliglota”).
Fowler também tem o seguinte exemplo de organização do armazenamento de dados em um aplicativo completo e de alta carga na área de comércio eletrônico.
Este exemplo, é claro, é um tanto exagerado, mas algumas considerações a favor da escolha de um ou outro SGBD para a finalidade correspondente podem ser encontradas, por exemplo, .
É claro que não é fácil ser servo em um zoológico assim.
- A quantidade de código que realiza o armazenamento de dados cresce proporcionalmente ao número de SGBDs utilizados; a quantidade de dados de sincronização de código é boa, se não for proporcional ao quadrado desse número.
- Como um múltiplo do número de SGBDs utilizados, aumentam os custos para fornecer características empresariais (escalabilidade, tolerância a falhas, alta disponibilidade) de cada um dos SGBDs utilizados.
- É impossível garantir as características empresariais do subsistema de armazenamento como um todo – especialmente a transacionalidade.
Do ponto de vista do diretor do zoológico, tudo é assim:
- Um aumento múltiplo no custo de licenças e suporte técnico do fabricante do SGBD.
- Excesso de pessoal e aumento de prazos.
- Perdas financeiras diretas ou penalidades devido à inconsistência de dados.
Há um aumento significativo no custo total de propriedade (TCO) do sistema. Existe alguma saída para a situação de “múltiplas opções de armazenamento”?
Multimodelo
O termo “armazenamento multivariado” entrou em uso em 2011. A consciência dos problemas da abordagem e a busca por uma solução demoraram vários anos e, em 2015, pela boca dos analistas do Gartner, a resposta foi formulada:
- A partir de "»:
O futuro dos SGBDs, suas arquiteturas e formas de utilizá-los é multimodelo.
- A partir de "»:
Os principais SGBDs operacionais oferecerão vários modelos – relacionais e não relacionais – como parte de uma única plataforma.
Parece que desta vez os analistas do Gartner estavam certos em suas previsões. Se você for para a página com DBMS em DB-Engines, você pode ver queоA maioria de seus líderes se posiciona especificamente como SGBDs multimodelos. O mesmo pode ser visto na página com qualquer avaliação privada.
A tabela abaixo mostra os SGBDs - líderes em cada uma das classificações privadas, que afirmam ser multimodelos. Para cada SGBD é indicado o modelo original suportado (que já foi o único) e junto com ele os modelos atualmente suportados. Também estão listados SGBDs que se posicionam como “originalmente multimodelos” e, segundo os criadores, não possuem nenhum modelo inicial herdado.
| SGBD | Modelo inicial | Modelos adicionais |
|---|---|---|
| Oracle | Relacional | Gráfico, documento |
| MS SQL | Relacional | Gráfico, documento |
| PostgreSQL | Relacional | Gráfico*, documento |
| MarkLogic | Documentário | Gráfico, relacional |
| MongoDB | Documentário | Valor-chave, gráfico* |
| Data Stax | Coluna larga | Documentário, gráfico |
| Redis | Valor chave | Documentário, gráfico* |
| ArangoDBName | - | Gráfico, documento |
| OrientDB | - | Gráfico, documento, relacional |
| Azure CosmosDB | - | Gráfico, documento, relacional |
Notas para a mesa
Asteriscos na tabela marcam declarações que exigem reservas:
- O DBMS PostgreSQL não oferece suporte ao modelo de dados gráficos, mas este produto oferece suporte , como AgensGraph.
- Em relação ao MongoDB, é mais correto falar sobre a presença de operadores gráficos na linguagem de consulta (, ) do que apoiar o modelo gráfico, embora, é claro, sua introdução exigisse algumas otimizações no nível de armazenamento físico no sentido de apoiar o modelo gráfico.
- Em relação ao Redis, queremos dizer a extensão .
A seguir, para cada uma das classes, mostraremos como é implementado o suporte a diversos modelos no SGBD desta classe. Consideraremos os modelos relacionais, documentais e gráficos os mais importantes e usaremos exemplos de SGBDs específicos para mostrar como os “ausentes” são implementados.
SGBD multimodelo baseado no modelo relacional
Os principais SGBDs atualmente são relacionais; a previsão do Gartner não poderia ser considerada verdadeira se os RDBMSs não mostrassem movimento na direção da multimodelagem. E eles demonstram. Agora, a ideia de que um SGBD multimodelo é como um canivete suíço, que não pode fazer nada bem, pode ser direcionada diretamente a Larry Ellison.
O autor, entretanto, prefere a implementação de multimodelagem no Microsoft SQL Server, cujo exemplo será descrito o suporte RDBMS para modelos de documentos e gráficos.
Modelo de documento no MS SQL Server
Já houve dois excelentes artigos no Habré sobre como o MS SQL Server implementa suporte ao modelo de documento; vou me limitar a uma breve recontagem e comentários:
A forma de suportar o modelo de documento no MS SQL Server é bastante típica para SGBDs relacionais: propõe-se que os documentos JSON sejam armazenados em campos de texto comuns. O suporte para o modelo de documento consiste em fornecer operadores especiais para analisar este JSON:
- para extrair valores de atributos escalares,
- para extrair subdocumentos.
O segundo argumento de ambos os operadores é uma expressão na sintaxe semelhante a JSONPath.
Abstratamente, podemos dizer que os documentos armazenados desta forma não são “entidades de primeira classe” em um SGBD relacional, ao contrário das tuplas. Especificamente, no MS SQL Server atualmente não existem índices nos campos dos documentos JSON, o que dificulta a união de tabelas utilizando os valores desses campos e até mesmo a seleção de documentos utilizando esses valores. No entanto, é possível criar uma coluna calculada para tal campo e um índice sobre ela.
Além disso, o MS SQL Server oferece a capacidade de construir convenientemente um documento JSON a partir do conteúdo das tabelas usando o operador - uma possibilidade, em certo sentido, oposta à anterior, o armazenamento convencional. É claro que não importa quão rápido seja um RDBMS, esta abordagem contradiz a ideologia dos SGBDs de documentos, que armazenam essencialmente respostas prontas para consultas populares e só podem resolver problemas de facilidade de desenvolvimento, mas não de velocidade.
Finalmente, o MS SQL Server permite resolver o problema inverso da construção de documentos: você pode decompor JSON em tabelas usando . Se o documento não estiver totalmente plano, você precisará usar CROSS APPLY.
Modelo de gráfico no MS SQL Server
O suporte para o modelo gráfico (LPG) também está totalmente implementado no Microsoft SQL Server : Propõe-se o uso de tabelas especiais para armazenar nós e arestas de grafo. Essas tabelas são criadas usando expressões CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectivamente.
As tabelas do primeiro tipo são semelhantes às tabelas comuns para armazenamento de registros, com a única diferença externa sendo que a tabela contém um campo do sistema $node_id — identificador exclusivo de um nó gráfico no banco de dados.
Da mesma forma, as tabelas do segundo tipo possuem campos de sistema $from_id и $to_id, as entradas nessas tabelas definem claramente as conexões entre os nós. Uma tabela separada é usada para armazenar relacionamentos de cada tipo.
Vamos ilustrar isso com um exemplo. Deixe os dados do gráfico terem um layout como o mostrado na figura. Então, para criar a estrutura correspondente no banco de dados, você precisa 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 de tais tabelas é que em consultas contra elas é possível usar padrões de gráfico com sintaxe semelhante a Cypher (no entanto, “*"etc. ainda não são suportados). Com base nas medições de desempenho, também pode-se presumir que a forma como os dados são armazenados nessas tabelas é diferente da forma como os dados são armazenados em tabelas regulares e são otimizados para executar tais consultas gráficas.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';Além disso, é bastante difícil não usar esses padrões gráficos ao trabalhar com tais tabelas, uma vez que em consultas SQL comuns para resolver problemas semelhantes será necessário fazer esforços adicionais para obter identificadores de nós “gráficos” do sistema ($node_id, $from_id, $to_id; Pelo mesmo motivo, as consultas para inserção de dados não são mostradas aqui por serem desnecessariamente complicadas).
Para resumir a descrição das implementações dos modelos de documentos e gráficos no MS SQL Server, observo que tais implementações de um modelo sobre outro não parecem bem-sucedidas, principalmente do ponto de vista do design da linguagem. É necessário estender uma linguagem com outra, as linguagens não são completamente “ortogonais”, as regras de compatibilidade podem ser bastante bizarras.
SGBD multimodelo baseado no modelo de documento
Nesta seção eu gostaria de ilustrar a implementação de multimodelos em SGBDs de documentos usando o exemplo do não mais popular deles, o MongoDB (como foi dito, ele só possui operadores gráficos condicionais $lookup и $graphLookup, não trabalhando em coleções fragmentadas), mas usando o exemplo de um SGBD mais maduro e “empresarial” .
Portanto, deixe a coleção conter um conjunto de documentos XML do seguinte tipo (o MarkLogic também permite armazenar documentos JSON):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Modelo relacional em MarkLogic
Uma visão relacional de uma coleção de documentos pode ser criada usando (conteúdo dos elementos value no exemplo abaixo pode haver um XPath arbitrário):
<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>Você pode abordar a visualização criada com uma consulta SQL (por exemplo, via ODBC):
SELECT name, surname FROM Person WHERE name="John"Infelizmente, a visualização relacional criada pelo modelo de exibição é somente leitura. Ao processar uma solicitação, MarkLogic tentará usar . Anteriormente, a MarkLogic tinha visões relacionais limitadas, inteiramente e graváveis, mas agora são considerados obsoletos.
Modelo gráfico em MarkLogic
Com suporte para o modelo gráfico (RDF), tudo é praticamente igual. Novamente com a ajuda Você pode criar uma representação RDF de uma coleção de documentos a partir do exemplo acima:
<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>Você pode abordar o gráfico RDF resultante com uma consulta SPARQL:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Ao contrário do relacional, o MarkLogic suporta o modelo gráfico de duas outras maneiras:
- Um SGBD pode ser um armazenamento separado completo de dados RDF (os triplos nele serão chamados em contraste com aqueles descritos acima ).
- RDF em serialização especial pode simplesmente ser inserido em documentos XML ou JSON (e os trigêmeos serão então chamados ). Esta é provavelmente uma alternativa aos mecanismos
idrefetc
Uma boa ideia de como as coisas “realmente” funcionam no MarkLogic é dada por , neste sentido, é de baixo nível, embora o seu objetivo seja exatamente o oposto - tentar abstrair do modelo de dados utilizado, garantir um trabalho consistente com os dados em diferentes modelos, transacionalidade, etc.
SGBD multimodelo “sem modelo principal”
Existem também SGBDs no mercado que se posicionam inicialmente como multimodelos, sem nenhum modelo principal herdado. Esses incluem , (desde 2018 a empresa de desenvolvimento pertence à SAP) e (serviço como parte da plataforma de nuvem Microsoft Azure).
Na verdade, existem modelos “principais” no ArangoDB e no OrientDB. Em ambos os casos, estes são modelos de dados próprios, que são generalizações do documento. As generalizações visam principalmente facilitar a capacidade de realizar consultas de natureza gráfica e relacional.
Esses modelos são os únicos disponíveis para uso no SGBD especificado; suas próprias linguagens de consulta são projetadas para funcionar com eles. É claro que tais modelos e SGBDs são promissores, mas a falta de compatibilidade com modelos e linguagens padrão torna impossível o uso desses SGBDs em sistemas legados — para substituir os SGBDs já utilizados lá.
Já existia um artigo maravilhoso sobre ArangoDB e OrientDB no Habré: .
ArangoDBName
ArangoDB reivindica suporte para um modelo de dados gráficos.
Os nós de um gráfico no ArangoDB são documentos comuns, e as arestas são documentos de um tipo especial que, junto com os campos regulares do sistema, possuem (_key, _id, _rev) campos do sistema _from и _to. Documentos em SGBDs de documentos são tradicionalmente combinados em coleções. Coleções de documentos que representam arestas são chamadas de coleções de arestas no ArangoDB. A propósito, os documentos de coleta de arestas também são documentos, portanto, as arestas no ArangoDB também podem atuar como nós.
Dados iniciais
Vamos fazer uma coleção persons, cujos documentos são assim:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Que haja também uma coleção cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Então a coleção likes pode ser assim:
[
{
"_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
Uma consulta em estilo gráfico na linguagem AQL usada no ArangoDB, retornando em formato legível informações sobre quem gosta de qual café, tem a seguinte aparência:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Num estilo relacional, onde estamos “computando” relacionamentos em vez de armazená-los, esta consulta pode ser reescrita assim (a propósito, sem a coleção likes poderia passar sem):
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 em ambos os casos será o mesmo:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Mais consultas e resultados
Se o formato do resultado acima parecer mais típico para um SGBD relacional do que para um SGBD de documento, você pode tentar esta consulta (ou pode usar ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}O resultado ficará assim:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
A base para implementar um modelo gráfico sobre um modelo de documento no OrientDB é os campos do documento, além de valores escalares mais ou menos padrão, também possuem valores de tipos como LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Os valores desses tipos são links ou coleções de links para documentos.
O identificador do documento atribuído pelo sistema tem um “significado físico”, indicando a posição do registro no banco de dados, e se parece com isto: @rid : #3:16. Assim, os valores das propriedades de referência são na verdade ponteiros (como no modelo de grafos) e não condições de seleção (como no modelo relacional).
Assim como o ArangoDB, as arestas no OrientDB são representadas como documentos separados (embora se uma aresta não tiver propriedades próprias, ela pode ser criada , e não corresponderá a um documento separado).
Dados iniciais
Num formato próximo Banco de dados OrientDB, os dados do exemplo anterior para ArangoDB seriam mais ou menos assim:
[
{
"@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 também armazenam informações sobre as arestas de entrada e saída. No A API Document precisa monitorar a própria integridade referencial, e a API Graph assume esse trabalho. Mas vamos ver como é o acesso ao OrientDB em linguagens de consulta “puras” que não estão integradas em linguagens de programação.
Consultas e resultados
Uma consulta de propósito semelhante à consulta do exemplo para ArangoDB no OrientDB é semelhante a esta:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameO resultado será obtido da seguinte forma:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Se o formato do resultado novamente parecer muito “relacional”, você precisará remover a linha com :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]A linguagem de consulta do OrientDB pode ser descrita como SQL com inserções semelhantes às do Gremlin. Na versão 2.2, apareceu um formulário de solicitação semelhante ao 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 da solicitação anterior. Pense no que precisa ser removido para torná-lo mais “relacional”, como na primeira consulta.
Azure CosmosDB
Em menor grau, o que foi dito acima sobre ArangoDB e OrientDB aplica-se ao Azure CosmosDB. CosmosDB fornece as seguintes APIs de acesso a dados: SQL, MongoDB, Gremlin e Cassandra.
API SQL e API MongoDB são usadas para acessar dados no modelo de documento. API Gremlin e API Cassandra - para acessar dados em formatos de gráfico e coluna, respectivamente. Os dados em todos os modelos são salvos no formato de modelo interno do CosmosDB: (“atom-record-sequence”), que também é próximo ao do documento.
Mas o modelo de dados escolhido pelo usuário e a API utilizada são fixados no momento da criação de uma conta no serviço. Não é possível acessar dados carregados em um modelo no formato de outro modelo, conforme ilustrado por algo assim:
Assim, o multimodelo no Azure CosmosDB hoje é apenas a capacidade de usar vários bancos de dados que suportam diferentes modelos de um fabricante, o que não resolve todos os problemas de armazenamento multivariado.
SGBD multimodelo baseado em um modelo gráfico?
Digno de nota é o fato de que ainda não existem no mercado SGBDs multimodelos que sejam baseados em um modelo gráfico (exceto para suporte multimodelo para dois modelos gráficos simultâneos: RDF e LPG; veja isso em ). As maiores dificuldades são causadas pela implementação de um modelo de documento sobre um modelo de grafo, ao invés de um modelo relacional.
A questão de como implementar um modelo relacional em cima do modelo de grafos foi considerada ainda durante a formação deste último. Como Por exemplo, :
Não há nada inerente à abordagem gráfica que impeça a criação de uma camada (por exemplo, por indexação adequada) em um banco de dados gráfico que permita uma visão relacional com (1) recuperação de tuplas dos pares chave-valor usuais e (2) agrupamento de tuplas por tipo de relação.
Ao implementar um modelo de documento sobre um modelo gráfico, você precisa ter em mente, por exemplo, o seguinte:
- Os elementos de uma matriz JSON são considerados ordenados, mas aqueles que emanam do vértice de uma borda do gráfico não;
- Os dados no modelo de documento geralmente são desnormalizados; você ainda não deseja armazenar várias cópias do mesmo documento incorporado e os subdocumentos geralmente não possuem identificadores;
- Por outro lado, a ideologia dos SGBDs de documentos é que os documentos são “agregados” prontos que não precisam ser construídos novamente a cada vez. É necessário fornecer ao modelo gráfico a capacidade de obter rapidamente um subgráfico correspondente ao documento finalizado.
Um pouco de publicidade
O autor do artigo está relacionado ao desenvolvimento do SGBD NitrosBase, cujo modelo interno é o gráfico, e os modelos externos - relacional e documental - são suas representações. Todos os modelos são iguais: quase todos os dados estão disponíveis em qualquer um deles usando uma linguagem de consulta que lhe seja natural. Além disso, em qualquer visualização, os dados podem ser alterados. As alterações serão refletidas no modelo interno e, consequentemente, nas demais visões.
Espero descrever como é a correspondência de modelos no NitrosBase em um dos artigos a seguir.
Conclusão
Espero que as linhas gerais do que é chamado de multimodelagem tenham ficado mais ou menos claras para o leitor. SGBDs multimodelos são bastante diferentes e o “suporte multimodelo” pode parecer diferente. Para entender o que se chama de “multimodelo” em cada caso específico, é útil responder às seguintes questões:
- Estamos falando de apoiar modelos tradicionais ou de algum tipo de modelo “híbrido”?
- Os modelos são “iguais” ou um deles é sujeito dos outros?
- Os modelos são “indiferentes” entre si? Os dados escritos em um modelo podem ser lidos em outro ou até mesmo sobrescritos?
Acho que a questão sobre a relevância dos SGBD multimodelos já pode ser respondida positivamente, mas a questão interessante é quais tipos deles serão mais procurados no futuro próximo. Parece que os SGBDs multimodelos que suportam modelos tradicionais, principalmente relacionais, terão maior demanda; A popularidade dos SGBDs multimodelos, que oferecem novos modelos que combinam as vantagens de vários modelos tradicionais, é uma questão de futuro mais distante.
Apenas usuários registrados podem participar da pesquisa. por favor
Você usa DBMS multimodelo?
-
Não usamos, armazenamos tudo em um SGBD e em um modelo
-
Usamos recursos multimodelos de SGBDs tradicionais
-
Praticamos persistência poliglota
-
Usamos novo DBMS multimodelo (Arango, Orient, CosmosDB)
19 usuários votaram. 4 usuários se abstiveram.
Fonte: habr.com