Un Graph Database est une base de données orientée graphe qui permet de représenter et stocker des données avec des noeuds et des arcs.
Temps de lecture : 10 minutes
Si vous lisez cet article, c'est que vous avez sans doute déjà entendu parler du concept de base de Graph Database et que vous cherchez à en savoir plus sur ce qu'elles sont et ce qu'elles peuvent faire pour vous.
Les bases de données orientées graphe suscitent actuellement beaucoup d'intérêt, car elles peuvent fournir des outils de modélisation de données très puissants qui permettent de mieux comprendre comment vos données fonctionnent dans le monde réel. Cela peut permettre une grande flexibilité pour représenter vos données d'une manière qui soit la plus logique possible pour toutes les personnes concernées, tout en tirant le meilleur parti des interactions complexes entre elles.
Cet article a pour but d’explorer ce qu’elles sont et la manière dont elles peuvent être utilisées dans votre paysage applicatif.
Avant de pouvoir comprendre ce qu'est un Graph Database, nous devons d'abord comprendre ce que l'on entend par graphique.
Dans ce contexte, une base de données orientée graphe représente un graphe mathématique. Plus précisément, une base de données graphique est généralement un graphe dirigé.
En termes mathématiques, un graphe est simplement un ensemble d'éléments - généralement appelés Nœuds (également appelés Sommets ou Points) - qui sont reliés entre eux par des arcs.
Chaque nœud représente un élément d'information dans le graphique, tandis que chaque arc représente une connexion entre deux nœuds.
Un graphique dirigé est un type spécial de graphique où les relations ont toujours une direction qui leur est associée. À l'inverse, un graphique non dirigé est un graphique où les relations sont simplement des arcs sans aucune direction associée.
Une fois que vous commencez à traiter des graphes, vous vous impliquez très rapidement dans la théorie des graphes. C'est une branche des mathématiques qui traite des complexités que les graphes peuvent contenir et de la meilleure façon d'en tirer des informations.
Les graphes sont déjà très répandus dans le monde réel et dans le développement de logiciels. Par exemple, chaque fois que vous essayez d'utiliser une carte de métro ou de tracer un arbre généalogique, vous avez affaire à un graphique.
Même l'utilisation quotidienne d’internet s’effectue à l'aide d'un graphique. Chaque ordinateur sur internet - serveurs, routeurs, commutateurs - est un nœud et chaque connexion entre eux est une relation. Certains éléments de la théorie des graphes sont donc très importants dans l'infrastructure utilisée ici, afin de connecter correctement des ordinateurs distants entre eux de la meilleure façon possible.
Au départ, un Graph Database est simplement un moteur de base de données qui modélise les nœuds et les arcs du graphique relationnel comme des entités de premier ordre. Cela vous permet de représenter les interactions complexes entre vos données sous une forme beaucoup plus naturelle, et permet souvent un ajustement plus proche des données du monde réel avec lesquelles vous travaillez.
Les bases de données orientées graphe sont souvent sans schéma - ce qui permet la flexibilité d'une base de données de type Document ou Key/Value Store - mais elles supportent les relations d'une manière similaire à celle d'une base de données relationnelle traditionnelle. Cela ne signifie pas pour autant qu'il n'y a pas de modèle de données associé à la base de données. Simplement qu'il y a davantage de flexibilité dans la façon dont vous la définissez, ce qui peut souvent conduire à une itération plus rapide de vos projets.
Tout cela est possible dans d'autres solutions de bases de données, mais pas toujours de manière aussi élégante que dans une base de données graphique et implique souvent des tables de liens ou des documents imbriqués pour atteindre le même niveau d'expressivité.
Les bases de données orientées graphe nous permettent également d'appliquer souvent la théorie des graphiques à nos données de manière efficace, ce qui nous permet de découvrir des liens à partir de nos données qui seraient autrement difficiles à voir. Par exemple, des itinéraires minimaux entre les nœuds, ou des ensembles disjoints au sein de nos données.
La meilleure façon de comprendre les avantages d'une telle solution est souvent de la voir en action. C'est pourquoi nous couvrirons un exemple concret de réseau social simple, mis en œuvre dans une base de données relationnelle, une base de données de documents et un Graph Database.
Ces trois solutions représenteront les mêmes données mais le feront à leur manière. Cela nous permet de voir rapidement les points communs et les différences entre les trois solutions.
Notre simple réseau social ne comportera que deux types d'entités - les utilisateurs et les messages (posts). Les utilisateurs ont des amis, sont capables d'écrire des messages et peuvent aimer les messages. Nous allons ensuite explorer la manière de récupérer une réponse relativement complexe à partir de cela : tous les amis de tout utilisateur qui a aimé un de mes messages, par ordre alphabétique de nom d'utilisateur.
Dans une base de données relationnelle typique, elle sera probablement modélisée à l'aide de quatre tables différentes : utilisateurs, messages, amis et like. Celles-ci pourraient ressembler à ceci :
Nous nous sommes retrouvés avec 4 tables différentes, avec 5 relations de clés étrangères entre elles. Deux de ces tableaux sont des données réelles, et les deux autres ne sont rien d'autre que des liens entre les entités de notre système.
Répondre à notre requête dans ce modèle de données est compliqué mais cela peut être réalisé avec une seule requête.
Ce n'est pas très esthétique, et il n'est pas particulièrement facile de lire cette requête pour
savoir quelles données elle récupère.
Elle finit par réunir 5 ensembles de résultats pour obtenir les résultats de l'un d'entre eux.
Mais elle fonctionnera et nous donnera toutes les informations souhaitées en une seule requête,
aussi efficace soit-elle.
Nous avons immédiatement réduit le nombre d'entités que nous modélisons à deux : ce qui est correct par rapport à notre modélisation initiale des données.
Nous avons également fait en sorte d'obtenir d'un seul coup certaines des données relatives à une entité : un message et tous les likes, par exemple.
Cependant, les liens croisés entre les messages et les utilisateurs et entre les utilisateurs eux-mêmes sont plus difficiles à gérer dans cette configuration.
De plus, n'oubliez pas que la plupart des bases de données documentaires ne prennent pas en charge l'intégrité relationnelle, de sorte que ces liens croisés doivent être maintenus par le logiciel, et qu'un support doit être intégré pour les cas où ils sont rompus.
Cependant, pour répondre à notre demande dans ce modèle de données, il faudra effectuer plusieurs requêtes. Comme les bases de données de stockage de documents ne prennent généralement pas en charge les liens croisés, nous devrons plutôt effectuer les différentes jointures dans le code. Dans ce cas, nous aurons besoin des requêtes suivantes :
Chacune de ces requêtes est relativement indolore à exécuter : il s'agit simplement de renvoyer des documents sur une simple clé.
Cependant, le fait que nous devions effectuer trois requêtes différentes et un certain traitement manuel entre chacune d'elles est tout simplement pénible. Nous pouvons éventuellement réduire ce problème en ayant certaines hypothèses sur notre modèle de données.
Par exemple, si les liens d'amis sont toujours à double sens, nous pouvons fusionner la deuxième et la troisième requête ensemble. Mais cela adjoint alors des limites à notre modèle de données pour améliorer ces requêtes.
Cela revient à ajouter des restrictions dans notre modèle de données pour améliorer ces requêtes. Et il n'est pas toujours correct d’effectuer cela.
Dans une base de données de stockage de documents, il existe plusieurs façons de modéliser cette dernière en fonction de ce que vous souhaitez exactement. Souvent, les relations entre des entités de différents types sont difficiles à réaliser, soit en étant modélisées comme un document imbriqué ou comme une clé étrangère appliquée manuellement. Nous opterons pour un mélange des deux, ce qui nous donnera une collection d'utilisateurs et de messages avec laquelle travailler.
Dans une base de données orientée graphe, nous pouvons choisir de modéliser les entités comme nos nœuds, et les relations comme nos arcs. Cela nous rapproche du modèle de la base de données de documents - où nous n'avons que deux types d'entités - mais avec la puissance du modèle relationnel - où nous n'avons pas à gérer manuellement les liens entre les entités, et où nous pouvons facilement parcourir ces liens à l'intérieur de la base de données elle-même. Cela pourrait ressembler à ceci :
Nous avons ici deux types différents de nœuds et trois types différents d’arcs.
Bien qu'ils ne soient pas visibles dans le diagramme, les nœuds et les arcs peuvent chacun contenir des
données, comme dans le modèle relationnel.
Par exemple, l’arc "AMIS" contient la date de création de la relation, ce qui nous permet de lister tous
les
amis par ordre chronologique.
Cela nous montre très rapidement que nous avons toute la puissance à laquelle nous sommes habitués avec le modèle relationnel, mais avec la flexibilité qui nous est familière dans le modèle de la base de données de stockage de documents.
Maintenant, pour répondre à notre exemple de requête, nous allons utiliser ceci. Elle peut être résolue comme suit (en utilisant le langage de requête Cypher)
En fait, cela n'est pas très différent de l'interrogation de la base de données relationnelle, sauf que l'interrogation est beaucoup plus lisible et que les liens sont beaucoup plus évidents. Nous pouvons également voir clairement qu'il y a une distinction entre les nœuds et les relations ici et que nous suivons les arcs pour aller d'un nœud à l'autre. Vous pouvez même parcourir cette requête en traçant simplement votre doigt sur les lignes nommées sur le schéma ci-dessus.
Il faut cependant noter que nous ne disons nulle part au moteur de la base de données comment relier les nœuds entre eux. Nous lui disons simplement de suivre une relation d'un certain type et il traite tout pour nous automatiquement. Il n'est plus nécessaire de faire correspondre les ID dans les différentes tables et d'espérer qu'ils correspondent correctement.
Il est évident qu'une base de données graphique ne sera pas toujours la mieux adaptée à vos besoins. Chaque situation est différente et vous devez évaluer vos besoins à chaque fois. La chose la plus importante que vous devez faire est d'évaluer votre modèle de données. Il est très probable qu'il soit hautement relationnel. C'est le cas de la plupart des modèles de données du monde réel. Dans ce cas, il est probable qu'un Graph Database soit déjà bien adapté à vos besoins.
Ensuite, déterminez le type de relations que présentent vos données. Si elle contient un certain nombre de relations multiples, une base de données graphique répondra probablement mieux à vos besoins qu'une base de données relationnelle traditionnelle. Même si elle contient un certain nombre de relations de type "un à un" ou "un à plusieurs", une base de données graphique peut faciliter la représentation.
Troisièmement, déterminez le schéma de vos données.
Les bases de données graphiques sont généralement beaucoup plus flexibles dans la manière dont elles vous permettent de stocker les données, ce qui permet une plus grande fluidité des données présentes à chaque endroit. Si vos besoins en matière de données sont tels que le schéma n'est pas absolument rigide, une base de données graphique peut être plus adaptée, même si une base de données relationnelle répond à vos besoins autrement.
Enfin, déterminez ce que vous voulez faire avec vos données. Si vous souhaitez effectuer des analyses de données complexes ou des requêtes potentiellement coûteuses portant sur plusieurs types de données, une base de données graphique peut vous faciliter la tâche et vous permettre d'exécuter les requêtes plus efficacement.
Une fois que vous avez décidé d'utiliser une base de données graphique, l'obstacle suivant est de décider laquelle choisir. Il existe un grand nombre d'options disponibles, et nous allons en présenter brièvement quelques-unes ici pour vous aider à déterminer celle qui convient le mieux à votre projet.
Nous allons résumer les caractéristiques de Neo4J, OrientDB, ArangoDB et JanusGraph pour vous aider à déterminer laquelle est la mieux adaptée à votre projet. Notez que ce ne sont pas les seules options parmi lesquelles vous pouvez choisir. Nous vous invitons à étudier les solutions suivantes en détail avant de prendre votre décision.
Neo4J est probablement le nom que la plupart des gens connaissent lorsqu'ils pensent aux bases de données graphiques. C'est la plus ancienne solution et la plus connue. Cependant, elle n'est pas aussi riche en fonctionnalités que les autres, et peut-être pas aussi performante (basée uniquement sur d'autres benchmarks en ligne, donc pas nécessairement fiable).
JanusGraph, en revanche, est très récent dans le monde des bases de données graphiques. Il est en développement depuis 2012 mais sa première version est sortie en 2017. Elle est en cours de développement sous l'égide de la Fondation Linux et est entièrement gratuite pour tous ceux qui veulent l'utiliser ou y contribuer.
Lorsqu'on démarre un nouveau projet, on a souvent tendance à utiliser des technologies qui sont bien connues, ou alors qui sont nouvelles et au cœur des conversations. Il convient d'examiner si ces technologies sont vraiment les mieux adaptées à vos besoins ou si une autre technologie pourrait vous convenir.
Une base de données relationnelle est souvent considérée comme l'option la plus sûre, et il existe une myriade de solutions de bases de données NoSQL qui font l'objet de nombreuses discussions en ligne ces jours-ci et qui peuvent aussi être tentantes à utiliser.
Mais si vous voulez le meilleur des deux - la flexibilité et la rapidité d'itération qui sont communes aux bases de données NoSQL, combinées à la puissance de modélisation relationnelle d'une base de données relationnelle - alors vous devriez plutôt envisager une base de données graphique, et voir ce qu'elle peut faire pour vous.
Découvrez la nouvelle génération d’infrastructure cloud