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?
sql
relational-database
graph-databases
user782220
la source
la source
Réponses:
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:
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.
la source
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:
MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.la source
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.
la source
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
la source
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:
Référence: bases de données de nouvelle génération
la source
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
la source