Dans un précédent article, nous avons introduit quelques concepts à propos des graphes, et les avons illustrés par deux exemples en utilisant la base de données graphe Neo4j.
Au cours de ces dernières années, de nombreuses compagnies ont développé leur solution de base de données graphe, en tant qu’éditeur comme Neo Technology avec Neo4j, Objectivity avec InfiniteGraph ou encore Sparsity avec dex*, ou en développant leur propre solution pour l’intégrer à leur application, comme LinkedIn ou Twitter.
Il est donc assez difficile de s’y retrouver dans ce paysage riche, qui continue à évoluer très vite.
Dans ce nouvel article qui se focalise sur les bases de données graphes, nous donnerons les éléments nécessaires à la compréhension de leur positionnement dans leur écosystème, par rapport aux autres types de base de données et aux autres types d’outils dédiés au traitement de graphes.
Plus précisément, nous essaierons de répondre à une question importante, à savoir quand utiliser une base de données graphes et quand ne pas en utiliser, ce qui n’est pas forcément évident.
Qu’est-ce qu’une base graphe?
Une base de données graphe est une base de données spécifiquement dédiée au stockage de structures de données de type graphe. Il s’agit donc de stocker exclusivement les données dans des noeuds et des arcs. Par définition, une base graphe correspond à tout système de stockage fournissant une adjacence entre éléments voisins sans indexation : tout voisin d’une entité est accessible directement par un pointeur physique. Les types de graphes pouvant être stockés peuvent varier, du graphe non orienté “single-type” à l’hyper-graphe, en passant bien sûr par les property-graphs. Une telle base de données répond donc généralement aux critères suivants :- Stockage optimisé pour des données représentées dans un graphe, avec possibilité de stocker des noeuds et des arcs.
- Stockage optimisé pour la lecture et le parcours de données dans le graphe (ou Traversal), sans recourir à un index pour parcourir les relations. Une base graphe est optimisée pour des recherches exploitant la localité des données, à partir d’un ou plusieurs noeuds racines, plutôt que des recherches globales.
- Modèle de données flexible pour certains produits : pas besoin de créer explicitement une entité pour les noeuds ou les arêtes, à la différence du modèle rigide par tables d’une base de données relationnelle.
- API intégrée permettant d’utiliser certains algorithmes classiques de la théorie des graphes (plus court chemin, Dijsktra, A*, calcul de centralité…)
Positionnement
Le mouvement NoSQL connaît son heure de gloire depuis quelques années, notamment car il cherche à adresser plusieurs problématiques auxquelles les bases relationnelles ne répondent pas suffisamment :- disponibilité pour traiter de très gros volumes et partitionnement (trop axées sur la consistance, le C du théorème de CAP),
- flexibilité du schéma,
- difficulté de représenter et traiter des structures complexes comme des arbres, des graphes, ou des relations en très grand nombre.
- traiter des données fortement connectées
- gérer facilement un modèle complexe et flexible
- offrir des performances exceptionnelles pour les lectures locales, par parcours de graphe.
Keywords: Bases de Données Graphes • DEX • InfiniteGraph • twitter