Comparaison des bases de données relationnelles et des bases de données graphiques
Quelqu'un peut-il m'expliquer les avantages et les inconvénients d'une base de données relationnelle telle que MySQL par rapport à une base de données graphique telle que Neo4j?
En SQL, vous avez plusieurs tables avec différents identifiants les reliant. 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 des connexions explicites en tant qu'arêtes dès le début, comme avec une base de données graphique. Conceptuellement, cela n'aurait aucun sens pour un débutant. Vraisemblablement, il y a une raison très technique mais non conceptuelle à cela?
Il y a en fait un raisonnement conceptuel derrière les deux styles. Wikipedia sur le modèle relationnel et bases de données graphiques donne un bon aperçu de cela.
La principale différence est que dans une base de données graphique, 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 graphique, 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 doit y avoir beaucoup de variations dans les relations; sinon vous reproduisez simplement les mêmes choses encore et encore. Cela signifie que les bases de données graphiques 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.
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 du SGBDR. Par exemple, lorsque vous essayez d'émuler des opérations de chemin (par exemple des amis d'amis) en vous 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 un ensemble, 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 graphiques 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 de propriétés (c'est ce qu'on appelle le modèle de graphique des propriétés, voir: https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model ). Cela signifie que si vous le souhaitez, vous pouvez regarder les relations sur le disque et voir comment elles "rejoignent" les entités. Les relations sont donc des entités de première classe dans une base de données de graphiques et sont sémantiquement beaucoup 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:
- 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 cela est que la latence des requêtes dans une base de données de graphiques 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 rejoindre la bombe =.
- 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 ami-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.
Dan1111 a déjà donné une réponse marquée comme correcte. Quelques points supplémentaires méritent d'être notés au passage.
Premièrement, dans presque toutes les implémentations de bases de données de graphiques, les enregistrements sont "épinglés" car il existe un nombre inconnu de pointeurs pointant sur l'enregistrement à son emplacement actuel. Cela signifie qu'un enregistrement ne peut pas être mélangé vers un nouvel emplacement sans laisser une adresse de transfert à l'ancien emplacement ou 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. Dans la pratique, il s'agit d'une opération qui pourrait prendre des semaines sur une grande base de données de graphiques, période pendant laquelle la base de données devrait être éteinte. 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 importante, mais loin d'être aussi importante que l'équivalent d'une base de données de graphiques.
Le deuxième point à noter en passant est que le World Wide Web peut être considéré comme une gigantesque base de données graphiques. Les pages Web contiennent des hyperliens et des hyperliens 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 est rompu. Ces liens rompus donnent alors lieu au redouté message "Erreur 404: page non trouvée" qui interrompt le plaisir de tant de surfeurs.
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 bons pour gérer les relations. Le mot relationnel dans le SGBDR découle 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. Il doit être représenté explicitement comme une clé étrangère ou 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 descendons 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 graphiques stocke les relations en tant qu'objets distincts. Cependant, les performances de lecture supérieures se font au détriment des écritures plus lentes.
Dans certaines situations, il est plus facile de modifier le modèle de données dans une base de données graphique que dans un SGBDR, par ex. 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 en revanche des avantages dans d'autres domaines, par ex. agréger des données ou effectuer un contrôle de version horodaté sur les données.
Je discute de certains des autres avantages et inconvénients dans mon article de blog sur bases de données graphiques pour l'entreposage de données
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 dans la pratique:
- SQL n'a pas la syntaxe pour effectuer facilement une traversée de graphe, en particulier des traversées dont la profondeur est inconnue ou illimitée. Par exemple, utiliser SQL pour déterminer les amis de vos amis est assez facile, mais il est difficile de résoudre le problème des "degrés de séparation".
- Les performances se dégradent rapidement lorsque nous parcourons le graphique. Chaque niveau de parcours augmente considérablement le temps de réponse aux requêtes.
Référence: Bases de données de nouvelle génération