Bases de données graphiques vs magasins triples - quand les utiliser?
Je sais qu'il y a des questions similaires sur Stackoverflow mais je ne pense pas qu'ils répondent aux questions suivantes.
Graphique Bases de données à ma compréhension stocker des données suivant principalement ce schéma:
Table/Collection 1: store nodes with UID
Table/Collection 2: store relations referencing nodes via UID
Cela permet de stocker des types arbitraires de graphiques. Maintenant, si je comprends bien, les magasins triples ne stockent que des triples:
Triple/Collection 1: store triples (2 nodes, 1 relation)
Maintenant, je verrais la distinction suivante concernant les cas d'utilisation:
- Bases de données graphiques: lorsque vous avez des connexions statiques connues
- Magasins triples: lorsque vous avez des nœuds peu connectés et que vous recherchez souvent de nouvelles connexions
Je suis confus par le fait que les gens ne semblent pas discuter lequel utiliser selon ces critères. La plupart des articles que je trouve parlent d'arguments comme la vitesse ou la compatibilité. Mais n'est-ce pas là le point le plus pertinent?
Autrement dit:
- Imaginez avoir un graphique clairement connecté et défini par l'utilisateur. Pourquoi diable voudriez-vous stocker cela en triples uniquement, perdant ainsi toutes les informations sur les connexions? Ou avoir à implémenter une solution personnalisée stockant les ID dans le triple
subject. - Imaginez que vous ayez collecté de manière lâche des nœuds que vous souhaitez interroger pour des relations inconnues à l'aide de SPARQL. Les bases de données graphiques le supportent. Mais pour cela, ils doivent construire un autre indice que je suppose et serait plus lent?
EDIT: Je vois que "perdre des informations sur les connexions" est la mauvaise façon de le dire. Si vous faites comme indiqué dans la réponse acceptée et insérez plusieurs triplets pour 2 nœuds + 1 relation, vous conservez toutes les informations et en particulier les informations sur les nœuds exacts qui sont connectés.
La principale différence entre les bases de données graphiques et les magasins triples est la façon dont ils modélisent le graphique. Dans un triple magasin (ou quadruple magasin), les données ont tendance à être très atomiques . Ce que je veux dire, c'est que les "nœuds" dans le graphique ont tendance à être des types de données primitifs comme une chaîne, un entier, une date, etc. Les relations relient les primitives entre elles, et donc "l'unité de discours" dans un magasin triple est un triple, et non un nœud ou une relation, généralement.
En revanche, d'autres bases de données graphiques sont souvent appelées "magasins de propriétés" car les nœuds sont des conteneurs de données qui correspondent aux objets d'un domaine. Un nœud remplace un objet et possède des propriétés; ils agissent comme des types de données riches spécifiés par les modélisateurs de graphes, plus que de simples types de données primitifs. Dans ces bases de données graphiques, les nœuds et les relations sont "l'unité de discours".
Disons que j'ai une personne nommée "Bob" qui connaît "Susan". En RDF, ce serait quelque chose comme ceci:
<http://example.org/person/1> :hasName "Bob".
<http://example.org/person/1> foaf:knows <http://example.org/person/2>.
<http://example.org/person/2> :hasName "Susan".
Dans une base de données graphique comme neo4j, ce serait ceci:
(a:Person {name: "Bob"})-[:KNOWS]->(b:Person {name: "Susan"})
Notez que dans RDF, il s'agit de 3 relations, mais une seule de ces relations exprime réellement la sémantique entre deux entités. Les deux autres relations ne font que suivre les propriétés d'une seule entité de niveau supérieur (la personne). Dans neo4j, c'est une relation 1 entre deux nœuds, chaque nœud ayant une propriété. Dans RDF vous aurez tendance à identifier les choses par URI, dans neo4j c'est un objet de base de données qui obtient automatiquement un ID de base de données. C'est ce que je veux dire sur la différence entre un magasin plus atomique/primitif (triple magasins) et un graphique de propriété plus riche.
RDF et les magasins triples sont principalement conçus pour les types de défis architecturaux que vous rencontriez avec le Web sémantique. Par exemple, l'espace de noms XML est intégré, dans l'hypothèse architecturale que vous allez mélanger et faire correspondre l'utilisation de nombreux vocabulaires et espaces de noms différents. (À droite, il y a une hypothèse très "web sémantique"). Donc, dans SPARQL et RDF vous verrez généralement au moins l'utilisation de xsd, rdf et rdfs espaces de noms simultanément, et probablement aussi owl, skos, et bien d'autres. SPARQL et RDF/RDFS ont également de nombreux crochets et fonctionnalités qui sont là explicitement pour faciliter des choses comme l'inférence d'ontologie. Vous 't tendance à identifier les choses avec des URI comme un moyen de "nommer vos identifiants" mais aussi parce que certaines personnes peuvent vouloir dé-référencer l'URI ... encore une fois l'hypothèse ici est un large accord de partage de données entre de nombreuses parties.
Les magasins de propriétés, en revanche, sont axés sur différents cas d'utilisation, comme la modélisation flexible des données au sein d'un modèle/espace de noms, les mappages entre les objets et les graphiques pour la persistance des applications d'entreprise, l'évolutivité rapide, etc. Vous aurez tendance à identifier les choses avec votre propre schéma (ou un ID de base de données interne). Un entier à incrémentation automatique n'est peut-être pas la meilleure forme d'identification pour un consommateur aléatoire sur le Web, (et ils ne peuvent certainement pas être dé-référencés comme des URL), mais ils ne sont peut-être pas votre première pensée pour une application interne de l'entreprise.
Alors quoi de mieux? Le format de magasin triple plus atomique, ou un graphique de propriété riche? Avez-vous besoin de mélanger et de faire correspondre de nombreux vocabulaires différents dans une requête ou un modèle de données? Avez-vous besoin de créer une ontologie OWL ou de faire une inférence? Avez-vous besoin de sérialiser un tas d'objets Java en mémoire dans une base de données? Avez-vous besoin de parcourir rapidement de longs chemins? Ces types de questions guideraient votre sélection.
Les graphiques sont des graphiques, les deux font des graphiques, et donc je ne pense pas qu'il y ait beaucoup de différence en termes de ce qu'ils peuvent représenter, ou comment vous envisagez un problème en "termes de graphique". Les différences se résument à l'architecture sous le capot et aux types de cas d'utilisation dont vous pensez avoir besoin. Je ne vous dirai pas que l'un est meilleur que l'autre, mais choisissez judicieusement.