Qu'est-ce qu'une base de données de graphes? Une meilleure façon de stocker les données connectées

Valeur-clé, orientée document, famille de colonnes, graphe, relationnel ... Aujourd'hui, il semble que nous ayons autant de types de bases de données que de types de données. Bien que cela puisse rendre le choix d'une base de données plus difficile, cela facilite le choix de la  bonne base de données. Bien sûr, cela nécessite de faire vos devoirs. Vous devez connaître vos bases de données. 

L'un des types de bases de données les moins compris est la base de données de graphes. Conçue pour travailler avec des données hautement interconnectées, une base de données de graphes peut être décrite comme plus «relationnelle» qu'une base de données relationnelle. Les bases de données graphiques brillent lorsque l'objectif est de capturer des relations complexes dans de vastes réseaux d'informations. 

Voici un aperçu de ce que sont les bases de données de graphes, pourquoi elles diffèrent des autres bases de données et quels types de problèmes de données elles sont conçues pour résoudre.

Base de données graphique vs base de données relationnelle

Dans une base de données relationnelle ou SQL traditionnelle, les données sont organisées en tables. Chaque table enregistre les données dans un format spécifique avec un nombre fixe de colonnes, chaque colonne avec son propre type de données (entier, heure / date, texte libre, etc.).

Ce modèle fonctionne mieux lorsque vous traitez principalement avec des données d'une seule table. Cela ne fonctionne pas trop mal lorsque vous agrégez des données stockées sur plusieurs tables. Mais ce comportement a des limites notables.

Considérez une base de données de musique, avec des albums, des groupes, des labels et des interprètes. Si vous voulez rapporter tous les artistes qui ont été présentés sur cet album par ce groupe sorti sur ces étiquettes - quatre tableaux différents - vous devez décrire explicitement ces relations. Avec une base de données relationnelle, vous y parvenez au moyen de nouvelles colonnes de données (pour les relations un-à-un ou un-à-plusieurs) ou de nouvelles tables (pour les relations plusieurs-à-plusieurs).

C'est pratique tant que vous gérez un nombre modeste de relations. Si vous avez affaire à des millions, voire des milliards de relations - des amis d'amis ou d'amis, par exemple - ces requêtes ne s'adaptent pas bien.

En bref, si les  relations entre les données , et non les données elles-mêmes, sont votre principale préoccupation, alors un autre type de base de données - une base de données de graphiques - est en ordre.

Fonctionnalités de la base de données graphique

Le terme «graphe» vient de l'utilisation du mot en mathématiques. Là, il est utilisé pour décrire une collection de nœuds (ou sommets ), chacun contenant des informations ( propriétés ) et avec des relations étiquetées (ou arêtes ) entre les nœuds.

Un réseau social est un bon exemple de graphique. Les personnes dans le réseau seraient les nœuds, les attributs de chaque personne (comme le nom, l'âge, etc.) seraient des propriétés et les lignes reliant les personnes (avec des étiquettes telles que «ami» ou «mère» ou « superviseur ») indiquerait leur relation. 

Dans une base de données conventionnelle, le traitement des requêtes sur les relations peut prendre du temps. Cela est dû au fait que les relations sont implémentées avec des clés étrangères et interrogées en joignant des tables. Comme n'importe quel DBA SQL peut vous le dire, effectuer des jointures est coûteux, en particulier lorsque vous devez trier un grand nombre d'objets - ou, pire, lorsque vous devez joindre plusieurs tables pour effectuer les types de requêtes indirectes (par exemple «ami d'un ami») dans lesquelles les bases de données graphiques excellent. 

Les bases de données graphiques fonctionnent en stockant les  relations avec les données. Les nœuds associés étant physiquement liés dans la base de données, l'accès à ces relations est aussi immédiat que l'accès aux données elles-mêmes. En d'autres termes, au lieu de calculer la relation comme doivent le faire les bases de données relationnelles, les bases de données graphiques lisent simplement la relation à partir du stockage. Répondre aux requêtes est une simple question de marcher ou de «parcourir» le graphique.  

Une base de données de graphes stocke non seulement les relations entre les objets de manière native, rendant les requêtes sur les relations rapides et faciles, mais vous permet également d'inclure différents types d'objets et différents types de relations dans le graphique. Comme les autres bases de données NoSQL, une base de données de graphes est sans schéma. Ainsi, en termes de performances et de flexibilité, les bases de données graphiques sont plus proches des bases de données documentaires ou des magasins de valeurs clés qu'elles ne le font des bases de données relationnelles ou orientées table.

Cas d'utilisation de la base de données Graph

Les bases de données graphiques fonctionnent mieux lorsque les données avec lesquelles vous travaillez sont fortement connectées et doivent être représentées par la manière dont elles relient ou font référence à d'autres données , généralement au moyen de relations plusieurs-à-plusieurs.

Encore une fois, un réseau social est un exemple utile. Les bases de données graphiques réduisent la quantité de travail nécessaire pour créer et afficher les vues de données trouvées dans les réseaux sociaux, telles que les flux d'activité, ou pour déterminer si vous pouvez ou non connaître une personne donnée en raison de sa proximité avec d'autres amis que vous avez dans le réseau.

Une autre application pour les bases de données de graphes est de trouver des modèles de connexion dans les données de graphes qui seraient difficiles à identifier via d'autres représentations de données. Les systèmes de détection de fraude utilisent des bases de données graphiques pour mettre en évidence des relations entre des entités qui auraient autrement été difficiles à remarquer. 

De même, les bases de données de graphes conviennent naturellement aux applications qui gèrent les relations ou les interdépendances entre les entités. Vous trouverez souvent des bases de données graphiques derrière des moteurs de recommandation, des systèmes de gestion de contenu et d'actifs, des systèmes de gestion des identités et des accès, ainsi que des solutions de conformité réglementaire et de gestion des risques. 

Requêtes de base de données graphique

Les bases de données Graph, comme les autres bases de données NoSQL, utilisent généralement leur propre méthodologie de requête personnalisée au lieu de SQL.

Un langage de requête de graphes couramment utilisé est Cypher, développé à l'origine pour la base de données de graphes Neo4j. Depuis fin 2015, Cypher a été développé en tant que projet open source distinct, et un certain nombre d'autres fournisseurs l'ont adopté comme système de requête pour leurs produits (par exemple, SAP HANA).

Voici un exemple de requête Cypher qui renvoie un résultat de recherche pour tous ceux qui sont un ami de Scott:

MATCH (a: Personne {nom: 'Scott'}) - [: FRIENDOF] -> (b) RETURN b 

Le symbole de la flèche ( ->) est utilisé dans les requêtes Cypher pour représenter une relation dirigée dans le graphique.

Un autre langage de requête graphique courant, Gremlin, a été conçu pour le framework de calcul graphique Apache TinkerPop. La syntaxe de Gremlin est similaire à celle utilisée par les bibliothèques d'accès aux bases de données ORM de certains langages.

Voici un exemple de requête «amis de Scott» dans Gremlin:

gV (). has ("name", "Scott"). out ("friendof") 

De nombreuses bases de données de graphes prennent en charge Gremlin via une bibliothèque, intégrée ou tierce.

Encore un autre langage de requête est SPARQL. Il a été développé à l'origine par le W3C pour interroger les données stockées au format RDF (Resource Description Framework) pour les métadonnées. En d'autres termes, SPARQL n'a pas été conçu pour les recherches de bases de données graphiques, mais peut être utilisé pour celles-ci. Dans l'ensemble, Cypher et Gremlin ont été adoptés plus largement.

Les requêtes SPARQL ont certains éléments qui rappellent SQL, à savoir les  clauses SELECTet WHERE, mais le reste de la syntaxe est radicalement différent. Ne pensez pas du tout à SPARQL comme étant lié à SQL, ou d'ailleurs à d'autres langages de requête graphique.

Bases de données graphiques populaires

Étant donné que les bases de données de graphes servent un cas d'utilisation de niche, il n'y en a pas autant qu'il existe de bases de données relationnelles. Du côté positif, cela rend les produits hors concours plus faciles à identifier et à discuter.

Neo4j

Neo4j est de loin la plus mature (11 ans et plus) et la plus connue des bases de données de graphes à usage général. Contrairement aux produits de base de données de graphes précédents, il n'utilise pas de back-end SQL. Neo4j est une base de données de graphes native qui a été conçue de l'intérieur pour prendre en charge de grandes structures de graphes, comme dans les requêtes qui renvoient des centaines de milliers de relations et plus.

Neo4j est disponible à la fois dans des éditions d'entreprise gratuites et payantes, ces dernières n'ayant aucune restriction sur la taille d'un ensemble de données (entre autres fonctionnalités). Vous pouvez également expérimenter Neo4j en ligne via son bac à sable, qui comprend quelques exemples de jeux de données pour vous entraîner.

Voir la critique de Neo4j pour plus de détails.

Microsoft Azure Cosmos DB

La base de données cloud Azure Cosmos DB est un projet ambitieux. Il est destiné à émuler plusieurs types de bases de données (tables conventionnelles, orientées document, famille de colonnes et graphique) le tout via un service unique et unifié avec un ensemble cohérent d'API.

À cette fin, une base de données de graphes n'est que l'un des différents modes de fonctionnement de Cosmos DB. Elle utilise le langage de requête et l'API Gremlin pour les requêtes de type graphique et prend en charge la console Gremlin créée pour Apache TinkerPop comme une autre interface.

Un autre grand argument de vente de Cosmos DB est que l'indexation, la mise à l'échelle et la géo-réplication sont gérées automatiquement dans le cloud Azure, sans aucun changement de bouton de votre côté. On ne sait pas encore comment l'architecture tout-en-un de Microsoft est à la hauteur des bases de données graphiques natives en termes de performances, mais Cosmos DB offre certainement une combinaison utile de flexibilité et d'évolutivité.

Consultez la revue d'Azure Cosmos DB pour plus de détails.

JanusGraph

JanusGraph est issu du projet TitanDB et est maintenant sous la gouvernance de la Linux Foundation. Il utilise l'un des nombreux back-ends pris en charge (Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB) pour stocker des données graphiques, prend en charge le langage de requête Gremlin (ainsi que d'autres éléments de la pile Apache TinkerPop) et peut également incorporer la recherche en texte intégral via les projets Apache Solr, Apache Lucene ou Elasticsearch.

IBM, l'un des soutiens du projet JanusGraph, propose une version hébergée de JanusGraph sur IBM Cloud, appelée Compose pour JanusGraph. Comme Azure Cosmos DB, Compose for JanusGraph fournit une mise à l'échelle automatique et une haute disponibilité, avec une tarification basée sur l'utilisation des ressources.