Les systèmes d'information modernes sont assez complexes. Leur complexité est notamment due à la complexité des données qui y sont traitées. La complexité des données réside souvent dans la variété des modèles de données utilisés. Ainsi, par exemple, lorsque les données deviennent « volumineuses », l’une des caractéristiques problématiques n’est pas seulement leur volume (« volume »), mais aussi leur variété (« variété »).
Si vous ne trouvez pas encore de faille dans le raisonnement, poursuivez votre lecture.
Teneur
Persistance polyglotte
Ce qui précède conduit au fait que parfois, même dans le cadre d'un même système, il est nécessaire d'utiliser plusieurs SGBD différents pour stocker les données et résoudre divers problèmes de traitement, chacun prenant en charge son propre modèle de données. Avec la main légère de M. Fowler, un certain nombre de livres célèbres et l'un des Manifeste Agile, cette situation s'appelle stockage multi-variantes (« persistance polyglotte »).
Fowler propose également l'exemple suivant d'organisation du stockage de données dans une application complète et à forte charge dans le domaine du commerce électronique.
Cet exemple, bien sûr, est quelque peu exagéré, mais certaines considérations en faveur du choix de l'un ou l'autre SGBD pour l'objectif correspondant peuvent être trouvées, par exemple : .
Force est de constater qu’être domestique dans un tel zoo n’est pas chose facile.
- La quantité de code qui effectue le stockage des données augmente proportionnellement au nombre de SGBD utilisés ; la quantité de données de synchronisation de code est bonne sinon proportionnelle au carré de ce nombre.
- En tant que multiple du nombre de SGBD utilisés, les coûts liés à la fourniture des caractéristiques d'entreprise (évolutivité, tolérance aux pannes, haute disponibilité) de chacun des SGBD utilisés augmentent.
- Il est impossible de garantir les caractéristiques d'entreprise du sous-système de stockage dans son ensemble, en particulier le caractère transactionnel.
Du point de vue du directeur du zoo, tout ressemble à ceci :
- Une augmentation multiple du coût des licences et du support technique du fabricant du SGBD.
- Sureffectif et délais accrus.
- Pertes financières directes ou pénalités dues à l’incohérence des données.
Il y a une augmentation significative du coût total de possession (TCO) du système. Existe-t-il un moyen de sortir de la situation des « options de stockage multiples » ?
Multi-modèle
Le terme « stockage multivarié » est apparu en 2011. La prise de conscience des problèmes de l'approche et la recherche d'une solution ont pris plusieurs années, et en 2015, par la bouche des analystes de Gartner, la réponse était formulée :
- De "»:
L’avenir des SGBD, de leurs architectures et de leurs modes d’utilisation est multimodèle.
- De "»:
Les principaux SGBD opérationnels offriront plusieurs modèles (relationnels et non relationnels) dans le cadre d'une plate-forme unique.
Il semble que cette fois-ci, les analystes de Gartner avaient raison dans leurs prévisions. Si vous allez à la page avec SGBD sur DB-Engines, vous pouvez voir queоLa plupart de ses dirigeants se positionnent spécifiquement comme des SGBD multimodèles. La même chose peut être vue sur la page avec n’importe quelle note privée.
Le tableau ci-dessous présente les SGBD - leaders dans chacune des notations privées, qui prétendent être multimodèles. Pour chaque SGBD, le modèle original pris en charge (qui était autrefois le seul) et avec lui les modèles actuellement pris en charge sont indiqués. Sont également répertoriés les SGBD qui se positionnent comme « à l'origine multi-modèles » et, selon les créateurs, ne possèdent pas de modèle initial hérité.
| SGBD | Modèle initial | Modèles supplémentaires |
|---|---|---|
| Oracle | Relationnel | Graphique, document |
| MS SQL | Relationnel | Graphique, document |
| PostgreSQL | Relationnel | Graphique*, document |
| MarkLogic | Documentaire | Graphique, relationnel |
| MongoDB | Documentaire | Valeur-clé, graphique* |
| DataStax | Colonne large | Documentaire, graphique |
| Redis | Valeur clé | Documentaire, graphique* |
| ArangoDB | - | Graphique, document |
| OrientDB | - | Graphique, document, relationnel |
| Azure CosmosDB | - | Graphique, document, relationnel |
Notes à la table
Les astérisques dans le tableau indiquent les déclarations qui nécessitent des réserves :
- Le SGBD PostgreSQL ne prend pas en charge le modèle de données graphique, mais ce produit le prend en charge , tel qu'AgensGraph.
- Par rapport à MongoDB, il est plus correct de parler de la présence d'opérateurs graphes dans le langage de requête (, ) que sur la prise en charge du modèle graphique, même si, bien sûr, leur introduction a nécessité certaines optimisations au niveau du stockage physique dans le sens de la prise en charge du modèle graphique.
- Par rapport à Redis, nous entendons l'extension .
Ensuite, pour chacune des classes, nous montrerons comment la prise en charge de plusieurs modèles est implémentée dans le SGBD de cette classe. Nous considérerons les modèles relationnels, documentaires et graphiques comme les plus importants et utiliserons des exemples de SGBD spécifiques pour montrer comment les « manquants » sont implémentés.
SGBD multimodèle basé sur le modèle relationnel
Les principaux SGBD actuels sont relationnels ; la prévision de Gartner ne pourrait pas être considérée comme vraie si les SGBDR ne montraient pas une évolution dans le sens de la multimodélisation. Et ils démontrent. Maintenant, l'idée selon laquelle un SGBD multimodèle est comme un couteau suisse, qui ne peut rien faire de bien, peut être adressée directement à Larry Ellison.
L'auteur préfère cependant la mise en œuvre de la multimodélisation dans Microsoft SQL Server, sur l'exemple de laquelle sera décrite la prise en charge des SGBDR pour les modèles de documents et de graphiques.
Modèle de document dans MS SQL Server
Il y a déjà eu deux excellents articles sur Habré sur la façon dont MS SQL Server implémente la prise en charge du modèle de document ; je me limiterai à un bref récit et commentaire :
La manière de prendre en charge le modèle de document dans MS SQL Server est assez typique des SGBD relationnels : il est proposé de stocker les documents JSON dans des champs de texte ordinaires. La prise en charge du modèle de document consiste à fournir des opérateurs spéciaux pour analyser ce JSON :
- pour extraire les valeurs d'attributs scalaires,
- pour extraire des sous-documents.
Le deuxième argument des deux opérateurs est une expression dans une syntaxe de type JSONPath.
De manière abstraite, on peut dire que les documents ainsi stockés ne sont pas des « entités de premier ordre » dans un SGBD relationnel, contrairement aux tuples. Plus précisément, dans MS SQL Server, il n'existe actuellement aucun index sur les champs des documents JSON, ce qui rend difficile la jointure de tables utilisant les valeurs de ces champs et même la sélection de documents utilisant ces valeurs. Cependant, il est possible de créer une colonne calculée pour un tel champ et un index sur celui-ci.
De plus, MS SQL Server offre la possibilité de créer facilement un document JSON à partir du contenu des tables à l'aide de l'opérateur - une possibilité, en un certain sens, opposée à la précédente, de stockage classique. Il est clair que quelle que soit la rapidité d'un SGBDR, cette approche contredit l'idéologie des SGBD documentaires, qui stockent essentiellement des réponses toutes faites aux requêtes populaires, et ne peuvent résoudre que des problèmes de facilité de développement, mais pas de vitesse.
Enfin, MS SQL Server permet de résoudre le problème inverse de la construction de documents : vous pouvez décomposer JSON en tables en utilisant . Si le document n'est pas complètement plat, vous devrez utiliser CROSS APPLY.
Modèle graphique dans MS SQL Server
La prise en charge du modèle graphique (LPG) est également entièrement implémentée dans Microsoft SQL Server : Il est proposé d'utiliser des tables spéciales pour stocker les nœuds et stocker les arêtes du graphe. Ces tableaux sont créés à l'aide d'expressions CREATE TABLE AS NODE и CREATE TABLE AS EDGE respectivement.
Les tables du premier type sont similaires aux tables ordinaires pour stocker des enregistrements, la seule différence externe étant que la table contient un champ système $node_id — identifiant unique d'un nœud de graphe dans la base de données.
De même, les tables du deuxième type ont des champs système $from_id и $to_id, les entrées dans ces tableaux définissent clairement les connexions entre les nœuds. Une table distincte est utilisée pour stocker les relations de chaque type.
Illustrons cela avec un exemple. Laissez les données du graphique avoir une disposition similaire à celle illustrée dans la figure. Ensuite, pour créer la structure correspondante dans la base de données, vous devez exécuter les requêtes DDL suivantes :
CREATE TABLE Person (
ID INTEGER NOT NULL,
name VARCHAR(100)
) AS NODE;
CREATE TABLE Cafe (
ID INTEGER NOT NULL,
name VARCHAR(100),
) AS NODE;
CREATE TABLE likes (
rating INTEGER
) AS EDGE;
CREATE TABLE friendOf
AS EDGE;
ALTER TABLE likes
ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);La principale spécificité de ces tables est que dans les requêtes sur celles-ci, il est possible d'utiliser des modèles de graphiques avec une syntaxe de type Cypher (cependant, "*"etc. ne sont pas encore pris en charge). Sur la base des mesures de performances, on peut également supposer que la manière dont les données sont stockées dans ces tables est différente de la manière dont les données sont stockées dans des tables normales et qu'elle est optimisée pour exécuter de telles requêtes graphiques.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';De plus, il est assez difficile de ne pas utiliser ces modèles de graphiques lorsque vous travaillez avec de telles tables, car dans les requêtes SQL ordinaires pour résoudre des problèmes similaires, il sera nécessaire de faire des efforts supplémentaires pour obtenir les identifiants de nœuds « graphiques » du système ($node_id, $from_id, $to_id; Pour la même raison, les requêtes d'insertion de données ne sont pas présentées ici car elles sont inutilement lourdes).
Pour résumer la description des implémentations des modèles de document et de graphique dans MS SQL Server, je voudrais noter que de telles implémentations d'un modèle par-dessus un autre ne semblent pas réussies, principalement du point de vue de la conception du langage. Il faut étendre une langue avec une autre, les langues ne sont pas complètement « orthogonales », les règles de compatibilité peuvent être assez bizarres.
SGBD multimodèle basé sur le modèle du document
Dans cette section, je voudrais illustrer l'implémentation du multimodèle dans les SGBD de documents en utilisant l'exemple du moins populaire d'entre eux, MongoDB (comme cela a été dit, il n'a que des opérateurs de graphes conditionnels $lookup и $graphLookup, ne travaillant pas sur des collections fragmentées), mais en utilisant l'exemple d'un SGBD plus mature et « entreprise » .
Alors, laissez la collection contenir un ensemble de documents XML du type suivant (MarkLogic vous permet également de stocker des documents JSON) :
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>Modèle relationnel dans MarkLogic
Une vue relationnelle d'une collection de documents peut être créée en utilisant (contenu des éléments value dans l'exemple ci-dessous, il peut y avoir un XPath arbitraire) :
<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>Vous pouvez adresser la vue créée avec une requête SQL (par exemple, via ODBC) :
SELECT name, surname FROM Person WHERE name="John"Malheureusement, la vue relationnelle créée par le modèle d'affichage est en lecture seule. Lors du traitement d'une demande, MarkLogic essaiera d'utiliser . Auparavant, MarkLogic avait des vues relationnelles limitées, entièrement et inscriptibles, mais ils sont désormais considérés comme obsolètes.
Modèle graphique dans MarkLogic
Avec la prise en charge du modèle graphique (RDF), tout est à peu près pareil. Encore une fois avec l'aide vous pouvez créer une représentation RDF d'une collection de documents à partir de l'exemple ci-dessus :
<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>Vous pouvez adresser le graphe RDF résultant avec une requête SPARQL :
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}Contrairement au modèle relationnel, MarkLogic prend en charge le modèle graphique de deux autres manières :
- Un SGBD peut être un stockage séparé à part entière de données RDF (les triplets qu'il contient seront appelés contrairement à ceux décrits ci-dessus ).
- RDF en sérialisation spéciale pourra simplement être inséré dans des documents XML ou JSON (et les triplets seront alors appelés ). C'est probablement une alternative aux mécanismes
idrefetc
Une bonne idée de la façon dont les choses fonctionnent « réellement » dans MarkLogic est donnée par , en ce sens, il est de bas niveau, même si son objectif est plutôt le contraire - essayer de faire abstraction du modèle de données utilisé, assurer un travail cohérent avec les données dans différents modèles, transactionnalité, etc.
SGBD multimodèle « sans modèle principal »
Il existe également sur le marché des SGBD qui se positionnent comme initialement multi-modèles, sans modèle principal hérité. Ceux-ci inclus , (depuis 2018, la société de développement appartient à SAP) et (service faisant partie de la plateforme cloud Microsoft Azure).
En fait, il existe des modèles « de base » dans ArangoDB et OrientDB. Dans les deux cas, il s’agit de leurs propres modèles de données, qui sont des généralisations de celui du document. Les généralisations visent principalement à faciliter la capacité à effectuer des requêtes de nature graphique et relationnelle.
Ces modèles sont les seuls disponibles pour une utilisation dans le SGBD spécifié ; leurs propres langages de requête sont conçus pour fonctionner avec eux. Bien sûr, ces modèles et SGBD sont prometteurs, mais le manque de compatibilité avec les modèles et langages standards rend impossible l'utilisation de ces SGBD dans des systèmes existants, pour remplacer les SGBD déjà utilisés.
Il y avait déjà un merveilleux article sur ArangoDB et OrientDB sur Habré : .
ArangoDB
ArangoDB revendique la prise en charge d'un modèle de données graphique.
Les nœuds d'un graphique dans ArangoDB sont des documents ordinaires et les bords sont des documents d'un type spécial qui, avec les champs système réguliers, ont (_key, _id, _rev) champs système _from и _to. Les documents des SGBD de documents sont traditionnellement regroupés en collections. Les collections de documents représentant les bords sont appelées collections de bords dans ArangoDB. À propos, les documents de collection Edge sont également des documents, donc les bords dans ArangoDB peuvent également agir comme des nœuds.
Données initiales
Ayons une collection persons, dont les documents ressemblent à ceci :
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]Qu'il y ait aussi une collection cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]Puis la collecte likes pourrait ressembler à ceci:
[
{
"_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
}
]Requêtes et résultats
Une requête de style graphique dans le langage AQL utilisé dans ArangoDB, renvoyant sous une forme lisible par l'homme des informations sur qui aime quel café, ressemble à ceci :
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }Dans un style relationnel, où nous « calculons » les relations plutôt que de les stocker, cette requête peut être réécrite ainsi (d'ailleurs, sans la collection likes on pourrait s'en passer) :
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 }Le résultat dans les deux cas sera le même :
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]Plus de requêtes et de résultats
Si le format de résultat ci-dessus semble être plus typique pour un SGBD relationnel que pour un SGBD de documents, vous pouvez essayer cette requête (ou vous pouvez utiliser ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}Le résultat ressemblera à ceci :
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
La base pour implémenter un modèle de graphique au-dessus d'un modèle de document dans OrientDB est les champs du document, en plus des valeurs scalaires plus ou moins standards, ont également des valeurs de types tels que LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. Les valeurs de ces types sont des liens ou des collections de liens vers documents.
L'identifiant du document attribué par le système a une « signification physique », indiquant la position de l'enregistrement dans la base de données, et ressemble à ceci : @rid : #3:16. Ainsi, les valeurs des propriétés de référence sont en réalité des pointeurs (comme dans le modèle graphique) plutôt que des conditions de sélection (comme dans le modèle relationnel).
Comme ArangoDB, les arêtes dans OrientDB sont représentées comme des documents séparés (bien que si une arête n'a pas ses propres propriétés, elle peut être créée). , et cela ne correspondra pas à un document séparé).
Données initiales
Dans un format proche de Base de données OrientDB, les données de l'exemple précédent pour ArangoDB ressembleraient à ceci :
[
{
"@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"
}
]Comme nous pouvons le voir, les sommets stockent également des informations sur les arêtes entrantes et sortantes. À L'API Document doit surveiller elle-même l'intégrité référentielle, et l'API Graph se charge de ce travail. Mais voyons à quoi ressemble l’accès à OrientDB dans les langages de requête « purs » qui ne sont pas intégrés aux langages de programmation.
Requêtes et résultats
Une requête similaire dans son objectif à la requête de l'exemple pour ArangoDB dans OrientDB ressemble à ceci :
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameLe résultat sera obtenu sous la forme suivante :
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]Si le format du résultat vous semble à nouveau trop « relationnel », vous devez supprimer la ligne avec :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]Le langage de requête d'OrientDB peut être décrit comme du SQL avec des insertions de type Gremlin. Dans la version 2.2, un formulaire de demande de type Cypher est apparu, :
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_nameLe format du résultat sera le même que dans la requête précédente. Pensez à ce qui doit être supprimé pour le rendre plus « relationnel », comme dans la toute première requête.
Azure CosmosDB
Dans une moindre mesure, ce qui a été dit ci-dessus à propos d'ArangoDB et d'OrientDB s'applique à Azure CosmosDB. CosmosDB fournit les API d'accès aux données suivantes : SQL, MongoDB, Gremlin et Cassandra.
L'API SQL et l'API MongoDB sont utilisées pour accéder aux données dans le modèle de document. API Gremlin et API Cassandra - pour accéder aux données sous forme de graphique et de colonne, respectivement. Les données de tous les modèles sont enregistrées au format de modèle interne CosmosDB : (« atom-record-sequence »), qui est également proche de celui du document.
Mais le modèle de données choisi par l'utilisateur et l'API utilisée sont fixés au moment de la création d'un compte dans le service. Il n'est pas possible d'accéder aux données chargées dans un modèle dans le format d'un autre modèle, comme illustré par quelque chose comme ceci :
Ainsi, le multimodèle dans Azure CosmosDB n'est aujourd'hui que la possibilité d'utiliser plusieurs bases de données prenant en charge différents modèles d'un seul fabricant, ce qui ne résout pas tous les problèmes du stockage multivariant.
Un SGBD multimodèle basé sur un modèle graphique ?
Il convient de noter qu'il n'existe pas encore sur le marché de SGBD multimodèles basés sur un modèle graphique (à l'exception de la prise en charge multimodèle de deux modèles graphiques simultanément : RDF et LPG ; voir ceci dans ). Les plus grandes difficultés proviennent de l’implémentation d’un modèle de document au-dessus d’un modèle graphique, plutôt que d’un modèle relationnel.
La question de savoir comment implémenter un modèle relationnel au-dessus du modèle graphique a été envisagée dès la formation de ce dernier. Comment Par exemple, :
Il n'y a rien d'inhérent à l'approche graphique qui empêche de créer une couche (par exemple, par une indexation appropriée) sur une base de données graphique qui permet une vue relationnelle avec (1) récupération de tuples à partir des paires clé-valeur habituelles et (2) regroupement de tuples par type de relation.
Lors de l'implémentation d'un modèle de document au-dessus d'un modèle graphique, vous devez garder à l'esprit, par exemple, les éléments suivants :
- Les éléments d'un tableau JSON sont considérés comme ordonnés, mais ceux émanant du sommet d'un bord du graphe ne le sont pas ;
- Les données du modèle de document sont généralement dénormalisées ; vous ne souhaitez toujours pas stocker plusieurs copies du même document intégré et les sous-documents n'ont généralement pas d'identifiant ;
- D'un autre côté, l'idéologie des SGBD documentaires est que les documents sont des « agrégats » prêts à l'emploi qui n'ont pas besoin d'être reconstruits à chaque fois. Il est nécessaire de fournir au modèle de graphique la possibilité d'obtenir rapidement un sous-graphe correspondant au document fini.
Un peu de publicité
L'auteur de l'article est lié au développement du SGBD NitrosBase, dont le modèle interne est un graphe, et les modèles externes - relationnel et document - sont ses représentations. Tous les modèles sont égaux : presque toutes les données sont disponibles dans chacun d’entre eux en utilisant un langage de requête qui leur est naturel. De plus, dans n'importe quelle vue, les données peuvent être modifiées. Les changements seront reflétés dans le modèle interne et, par conséquent, dans d'autres vues.
J'espère décrire à quoi ressemble la correspondance de modèles dans NitrosBase dans l'un des articles suivants.
Conclusion
J'espère que les grandes lignes de ce qu'on appelle la multimodélisation sont devenues plus ou moins claires pour le lecteur. Les SGBD multimodèles sont très différents, et la « prise en charge multimodèle » peut être différente. Pour comprendre ce qu'on appelle « multi-modèle » dans chaque cas précis, il est utile de répondre aux questions suivantes :
- Parle-t-on de soutenir des modèles traditionnels ou une sorte de modèle « hybride » ?
- Les modèles sont-ils « égaux », ou l’un d’eux est-il le sujet des autres ?
- Les modèles sont-ils « indifférents » les uns aux autres ? Les données écrites dans un modèle peuvent-elles être lues dans un autre ou même écrasées ?
Je pense que la question de la pertinence des SGBD multimodèles peut déjà recevoir une réponse positive, mais la question intéressante est de savoir quels types d'entre eux seront les plus demandés dans un avenir proche. Il semble que les SGBD multimodèles prenant en charge les modèles traditionnels, principalement relationnels, seront de plus en plus demandés ; La popularité des SGBD multimodèles, proposant de nouveaux modèles combinant les avantages de divers modèles traditionnels, relève d’un avenir plus lointain.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Utilisez-vous un SGBD multimodèle ?
-
Nous ne l'utilisons pas, nous stockons tout dans un seul SGBD et dans un seul modèle
-
Nous utilisons les capacités multimodèles des SGBD traditionnels
-
Nous pratiquons la persévérance polyglotte
-
Nous utilisons de nouveaux SGBD multimodèles (Arango, Orient, CosmosDB)
19 utilisateurs ont voté. 4 utilisateurs se sont abstenus.
Source: habr.com