Comparaison des bases de données relationnelles et des bases de données graphiques


90

Quelqu'un peut-il m'expliquer les avantages et les inconvénients d'une base de données de relations comme MySQL par rapport à une base de données de graphes comme Neo4j?

En SQL, vous avez plusieurs tables avec différents identifiants les liant. Ensuite, vous devez vous joindre pour connecter les tables. Du point de vue d'un débutant, pourquoi concevriez-vous la base de données pour exiger une jointure plutôt que d'avoir les connexions explicites comme des arêtes dès le départ comme avec une base de données de graphes. Conceptuellement, cela n'aurait aucun sens pour un débutant. Il y a probablement une raison très technique mais non conceptuelle à cela?


Les méthodes d'accès sont différentes. Dans une base de données relationnelle, vous utilisez l' algèbre relationnelle , mieux augmentée avec la récursivité, une représentation maladroite mais populaire de ce qui est (récursif, avec des extras procéduraux) SQL. Dans une base de données de graphes, vous utilisez des langages de parcours de graphes comme Gremlin . Les implémentations de base de données sous-jacentes jusqu'à la disposition sur disque seraient choisies pour fournir les meilleures performances pour la méthode d'accès respective, et des réglages / variations arbitraires peuvent être trouvés dans les implémentations.
David Tonhofer

Réponses:


115

Il y a en fait un raisonnement conceptuel derrière les deux styles. Wikipedia sur le modèle relationnel et les bases de données de graphes en donne un bon aperçu.

La principale différence est que dans une base de données de graphes, les relations sont stockées au niveau de l'enregistrement individuel, tandis que dans une base de données relationnelle, la structure est définie à un niveau supérieur (les définitions de table).

Cela a des ramifications importantes:

  • Une base de données relationnelle est beaucoup plus rapide lorsqu'elle fonctionne sur un grand nombre d'enregistrements. Dans une base de données de graphes, chaque enregistrement doit être examiné individuellement lors d'une requête afin de déterminer la structure des données, alors que cela est connu à l'avance dans une base de données relationnelle.
  • Les bases de données relationnelles utilisent moins d'espace de stockage, car elles n'ont pas à stocker toutes ces relations.

Le stockage de toutes les relations au niveau de l'enregistrement individuel n'a de sens que s'il va y avoir beaucoup de variations dans les relations; Sinon, vous ne faites que dupliquer les mêmes choses encore et encore. Cela signifie que les bases de données de graphes sont bien adaptées aux structures irrégulières et complexes. Mais dans le monde réel, la plupart des bases de données nécessitent des structures régulières et relativement simples. C'est pourquoi les bases de données relationnelles prédominent.


16
Le stockage des relations au niveau de l'enregistrement a également du sens dans d'autres cas, car il fournit une contiguïté sans index. Autrement dit, les traversées de graphe peuvent être effectuées sans aucune recherche d'index, ce qui améliore les performances. Et ce n'est pas une duplication, car vous stockez les relations réelles, qui diffèrent.
nawroth

4
Vous dites: «Dans une base de données graphique, chaque enregistrement doit être examiné individuellement lors d'une requête afin de déterminer la structure des données». Est-ce une propriété universelle des bases de données de graphes ou plus ou moins vrai en général? Que diriez-vous d'OrientDb qui prend en charge le schéma complet pour les sommets et les arêtes?
Lodewijk Bogaards

@LodewijkBogaards certaines bases de données de graphes, comme Neo4j, permettent une indexation de base. Si la requête atteint les index, je pense qu'il n'est pas nécessaire de déterminer la structure des données derrière l'index. Mais cela dépend de la requête.
Vojtěch Vít

3
Je ne suis pas du tout d’accord sur les deux points. La base de données graphique est toujours plus rapide lorsqu'il existe des clés étrangères. Parce que nous n'avons pas besoin d'opérations de jointure. Les bases de données relationnelles doivent stocker la clé étrangère dans de nombreuses tables. Une arête et une clé étrangère doivent occuper le même espace de stockage.
cegprakash

3
@cegprakash Avez-vous également une documentation à partir de laquelle nous pouvons également conclure la même chose?
Victor

102

La principale différence entre un graphique et une base de données relationnelle est que les bases de données relationnelles fonctionnent avec des ensembles tandis que les bases de données graphiques fonctionnent avec des chemins.

Cela se manifeste de manière inattendue et inutile pour un utilisateur de SGBDR. Par exemple, lorsque vous essayez d'émuler des opérations de chemin (par exemple des amis d'amis) en se joignant récursivement à une base de données relationnelle, la latence des requêtes augmente de manière imprévisible et massive, tout comme l'utilisation de la mémoire, sans oublier qu'elle torture SQL pour exprimer ce type d'opérations. Plus de données signifie plus lent dans une base de données basée sur des ensembles, même si vous pouvez retarder la douleur grâce à une indexation judicieuse.

Comme l'a laissé entendre Dan1111, la plupart des bases de données de graphes ne souffrent pas de ce type de douleur de jointure car elles expriment des relations à un niveau fondamental. Autrement dit, les relations existent physiquement sur le disque et elles sont nommées, dirigées et peuvent elles-mêmes être décorées avec des propriétés (cela s'appelle le modèle de graphe de propriétés, voir: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Modèle ). Cela signifie que si vous choisissez de le faire, vous pouvez examiner les relations sur le disque et voir comment elles «rejoignent» les entités. Les relations sont donc des entités de premier ordre dans une base de données de graphes et sont sémantiquement bien plus solides que les relations implicites réifiées au moment de l'exécution dans un magasin relationnel.

Alors pourquoi devriez-vous vous en soucier? Pour deux raisons:

  1. Les bases de données graphiques sont beaucoup plus rapides que les bases de données relationnelles pour les données connectées - une force du modèle sous-jacent. Une conséquence de ceci est que la latence des requêtes dans une base de données de graphes est proportionnelle à la quantité du graphique que vous choisissez d'explorer dans une requête, et n'est pas proportionnelle à la quantité de données stockées, désamorçant ainsi la bombe de jointure .
  2. Les bases de données graphiques rendent la modélisation et l'interrogation beaucoup plus agréables, ce qui signifie un développement plus rapide et moins de moments WTF. Par exemple, exprimer l'ami d'un ami pour un réseau social typique dans le langage de requête Cypher de Neo4j est juste MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

3
"Les relations sont donc des entités de premier ordre dans une base de données de graphes". La même chose est généralement vraie dans une base de données relationnelle: les entités sont mappées à des tuples dans les relations, tout comme les relations plusieurs-plusieurs. La distinction que vous décrivez est-elle pour les relations un-plusieurs, qui sont souvent fusionnées dans des relations d'entité?
beldaz

52
Cette comparaison semble un peu biaisée. Qu'en est-il des inconvénients?
Kurren

9
Un peu? Trop partial à mon avis honnête. On dirait au mieux une annonce "C'est un bon produit! Achetez-moi cette" annonce!
ilgaar

37
Cela nécessite une mise en garde massive : ce type est le "scientifique en chef" de Neo Technology, qui crée la base de données de graphes Neo4J.
Rob Grant

4
Que diriez-vous d'une recherche arbitraire ... donnez-moi tous les utilisateurs qui ont entre 35 et 55 ans et ont acheté chez Walmart au cours des 90 derniers jours.
Matthew Whited

20

Dan1111 a déjà donné une réponse signalée comme correcte. Quelques points supplémentaires méritent d'être soulignés au passage.

Premièrement, dans presque toutes les implémentations de bases de données graphiques, les enregistrements sont «épinglés» car il existe un nombre inconnu de pointeurs pointant vers l'enregistrement à son emplacement actuel. Cela signifie qu'un enregistrement ne peut pas être mélangé à un nouvel emplacement sans laisser une adresse de transfert à l'ancien emplacement ou sans casser un nombre inconnu de pointeurs.

Théoriquement, on pourrait mélanger tous les enregistrements à la fois et trouver un moyen de localiser et de réparer tous les pointeurs. En pratique, il s'agit d'une opération qui pourrait prendre des semaines sur une grande base de données de graphes, période pendant laquelle la base de données devrait être désactivée. Ce n'est tout simplement pas faisable.

En revanche, dans une base de données relationnelle, les enregistrements peuvent être remaniés à une assez grande échelle, et la seule chose à faire est de reconstruire tous les index qui ont été affectés. Il s'agit d'une opération assez volumineuse, mais loin d'être aussi grande que l'équivalent d'une base de données de graphes.

Le deuxième point à noter au passage est que le World Wide Web peut être considéré comme une gigantesque base de données de graphes. Les pages Web contiennent des liens hypertexte et des liens hypertexte font référence, entre autres, à d'autres pages Web. La référence se fait via des URL, qui fonctionnent comme des pointeurs.

Lorsqu'une page Web est déplacée vers une URL différente sans laisser d'adresse de transfert à l'ancienne URL, un nombre inconnu d'hyperliens sera rompu. Ces liens rompus donnent alors naissance au redoutable message "Erreur 404: page non trouvée" qui interrompt le plaisir de tant d'internautes.


4
Seulement que la plupart des bases de données graphiques ont des règles d'intégrité qui ne permettent pas les liens rompus.
Michael Hunger

1
Si le SGBD épingle la cible, cela évitera évidemment la rupture de liaison due au déplacement de la cible du lien. Je ne connais pas de bases de données graphiques qui n'épinglent pas les enregistrements qui pourraient être des cibles de liens.
Walter Mitty

Les bases de données de graphes sont-elles généralement sans schéma car un changement de schéma serait une opération très lourde en raison de la nécessité de réécrire tous les pointeurs? Le problème de remaniement ne peut-il pas être contourné en stockant simplement des pointeurs virtuels, qui passent par une table de consultation? Cela fonctionnerait toujours à O (1), non?
Lodewijk Bogaards

J'ai fonctionné sous une définition de bases de données graphiques qui incluraient des bases de données pré-relationnelles telles que des bases de données hiérarchiques ou en réseau. Certaines de ces bases de données avaient des schémas, mais pas des schémas relationnels. Je ne sais pas si ma définition opérationnelle correspond ou non à la définition standard.
Walter Mitty

Une structure de données qui fournit un mappage entre des pointeurs virtuels et des pointeurs physiques est essentiellement la même chose qu'un index, avec à peu près les mêmes coûts. Vous pourriez aussi bien aller de l'avant et utiliser une base de données relationnelle.
Walter Mitty

7

Avec une base de données relationnelle, nous pouvons modéliser et interroger un graphique en utilisant des clés étrangères et des auto-jointures. Ce n'est pas parce que les SGBDR contiennent le mot relationnel qu'ils sont capables de gérer les relations. Le mot relationnel dans le SGBDR provient de l'algèbre relationnelle et non de la relation. Dans un SGBDR, la relation elle-même n'existe pas en tant qu'objet à part entière. Elle doit soit être représentée explicitement comme une clé étrangère, soit implicitement comme une valeur dans une table de liens (lors de l'utilisation d'une approche de modélisation générique / universelle). Les liens entre les ensembles de données sont stockés dans les données elles-mêmes.

Plus nous augmentons la profondeur de recherche dans une base de données relationnelle, plus nous devons effectuer d'auto-jointures et plus les performances de nos requêtes en souffrent. Plus nous allons dans notre hiérarchie, plus nous devons joindre de tables et plus notre requête est lente. Mathématiquement, le coût augmente de façon exponentielle dans une base de données relationnelle. En d'autres termes, plus nos requêtes et relations sont complexes, plus nous bénéficions d'un graphique par rapport à une base de données relationnelle. Nous n'avons pas de problèmes de performances dans une base de données de graphiques lors de la navigation dans le graphique. En effet, une base de données de graphes stocke les relations en tant qu'objets séparés. Cependant, les performances de lecture supérieures se font au prix d'écritures plus lentes.

Dans certaines situations, il est plus facile de changer le modèle de données dans une base de données de graphes que dans un SGBDR, par exemple dans un SGBDR si je change une relation de table de 1: n à m: n Je dois appliquer DDL avec un temps d'arrêt potentiel.

Le SGBDR présente par contre des avantages dans d'autres domaines, par exemple l'agrégation de données ou le contrôle de version horodaté des données.

Je discute de certains des autres avantages et inconvénients dans mon article de blog sur les bases de données graphiques pour l'entreposage de données


4

Alors que le modèle relationnel peut facilement représenter les données contenues dans un modèle graphique, nous sommes confrontés à deux problèmes importants en pratique:

  1. SQL n'a pas la syntaxe pour effectuer facilement la traversée de graphes, en particulier les traversées où la profondeur est inconnue ou illimitée. Par exemple, utiliser SQL pour déterminer les amis de vos amis est assez simple, mais il est difficile de résoudre le problème des «degrés de séparation».
  2. Les performances se dégradent rapidement lorsque nous parcourons le graphique. Chaque niveau de parcours augmente considérablement le temps de réponse des requêtes.

Référence: bases de données de nouvelle génération


0

Les bases de données de graphes valent la peine d'être étudiées pour les cas d'utilisation dans lesquels elles excellent, mais j'ai eu des raisons de remettre en question certaines assertions dans les réponses ci-dessus. En particulier:

Une base de données relationnelle est beaucoup plus rapide lorsqu'elle fonctionne sur un grand nombre d'enregistrements (premier point de dan1111)

Les bases de données graphiques sont beaucoup plus rapides que les bases de données relationnelles pour les données connectées - une force du modèle sous-jacent. Une conséquence de ceci est que la latence des requêtes dans une base de données de graphes est proportionnelle à la quantité de graphique que vous choisissez d'explorer dans une requête, et n'est pas proportionnelle à la quantité de données stockées, désamorçant ainsi la bombe de jointure. (Premier point de Jim Webber)

En d'autres termes, plus nos requêtes et relations sont complexes, plus nous bénéficions d'un graphique par rapport à une base de données relationnelle. (2ème paragraphe d'Uli Bethke)

Bien que ces affirmations puissent avoir du mérite, je n'ai pas encore trouvé de moyen d'aligner mon cas d'utilisation spécifique sur elles. Référence: Base de données de graphes ou bases de données relationnelles Extensions de table communes: comparaison des performances des requêtes de graphes acycliques

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.