Les bases de données orientées graphe, vous en avez sans doute entendu parler, mais votre todo regorge de "trucs cool à essayer", alors pourquoi s'intéresser aux graph-databases dès aujourd'hui ?
Vous avez dit Graphe ?
Les bases de données orientées graphe sont des bases de donnée NoSql, sans schéma, dont la plupart des implémentations sont ACID.
Les objets stockés sont uniquement des nœuds (objets), des relations et des propriétés, ces dernières étant portées par les nœud et les relations.
Leur force réside en la connaissance à chaque nœud du pointeur physique menant à ses nœuds voisins au lieu de le retrouver en parcourant un index via son identifiant, rendant donc les recherches locales très rapides, entraînant ainsi un gain de performance dès lors que la recherche touche des données connexes.
Seul le premier nœud d'où part la recherche est recherché en parcourant l'index. En effet chaque recherche est un parcours partant d'un nœud.
Ici le nœud me représentant est lié par la relation [employé de] au nœud Arolla.
Les nœuds et les relations ont ici des propriétés.
Les nœuds ne sont pas typés: c'est l'effet schema-less. En effet un nœud est avant tout définit par sa disposition vis à vis d'une relation. Neo4J n'avait par exemple pas de notion de type sur ses nœuds bien que soit introduit la notion de label dans la version 2.0.
Nos données ont changé
Les bases de données relationnelles ont été créées à une époque où les applications servaient principalement à afficher des listes d'objets et à faire des opération de CRUD sur ces dernières. Stocker ses données dans des tables structurées était alors la meilleure solution, et aujourd'hui encore la plupart d'entre nous s'en sortent très bien avec ces technologies.
Cependant, non seulement le volume des données que nous devons traiter ne cesse de croître, mais elles ont aussi un besoin croissant d'être connectées entres elles. Car plus que la donnée elle-même, c'est souvent sa relation avec les autres données qui a de la valeur. L'accumulation de données de liaison permet de faire des recherches par motif et ainsi allier analyse comportementale et prédictibilité (impact d'une publicité, recommandations, etc).
Malgré l'évolution des bases de données relationnelles, un modèle où le temps d'une requête dépend du nombre de données de même type présent dans le référentiel ne sera sans doute plus adapté à nos besoins.
Mais que faire ? Laisser tomber les jointures et stocker vos données sous formes d'agrégats dans des bases orientées documents ? Pourquoi ne pas plutôt repenser nos données et les appréhender sous un autre angle .
Au delà du stockage
Lorsque j'ai acheté l'excellent livre graphDatabase, je m'attendais à une lecture très technique concernant du stockage de données. Les auteurs (tous 3 créateurs de neo4J) ont une vision très axée sur le domaine métier, toujours en quête d'apporter une valeur métier aux données.
Il faut d'ailleurs savoir que toutes les graphDatabases n'utilisent pas un stockage natif graphe. Certaines utilisent des bases de données relationnelles ou noSql orientée document pour stocker les nœud et relations.
Il s'agit donc avant tout d'une façon de penser, et non d'une simple amélioration technique.
Transformez la complexité accidentelle en valeur
Dans un modèle de type e-commerce simple, avec des utilisateurs passant des commandes et notant des produits, on pourrait se retrouver avec un schéma tel que celui ci:
Les relations représentées par des clés étrangères alourdissent le modèle sans y apporter de valeur et permettent juste de lier vos données techniquement.
L'ajout de clefs étrangères liant deux tables et de données qualifiant ce lien comme sa date de création, son créateur, vont alourdir vos tables. Lorsque certaines tables sont centrales et sont de plus en plus utilisées au fil du temps par différentes fonctionnalités, ces liens qualifiés deviennent lourds à maintenir. Cela va à terme créer des zones de friction entre vos différents domaines et polluer votre modèle.
De plus on se retrouve rapidement avec des risques de requêtes coûteuses, voire récursives, si l'on souhaite exploiter ce modèle.
En base de données orientée graphe, les relations sont des éléments de premier niveau au même titre que les nœuds et peuvent ainsi apporter une vraie valeur, et cela permet à n'importe qui arrivant hors contexte de mieux comprendre la nature de la connexion entre ces 2 objets.
L'optimisation apportée par la recherche locale désacralise la séparation des données. La facilité à retrouver les données connectées rend plus facile le découpage en petits objets, afin de ne pas mélanger les domaines métier.
Une fois le premier nœud trouvé, récupérer ses voisins (données directement reliées fonctionnellement) prendra toujours le même temps, indépendamment de la volumétrie.
The silver bullet ?
Bien entendu non, comme toute technologie celle-ci a ses limites et contre-indications:
- Traverser l'ensemble du graphe se révélera être coûteux : prix moyen d'une commande tous clients confondus par exemple (en opposition à une base relationnelle) ou toute autre valeur statistique globale telle que le chiffre d'affaires.
- Les recherches ne commençant pas par une entité identifiée sont contre-indiquées.
- Changer son modèle nécessitera de repasser sur tous ses objets manuellement, c'est le 2e effet kiss cool du schéma-less. L’intérêt étant aussi d'éviter une migration de schéma en cas d'ajout d'une nouvelle propriété.
- Sur une reprise d'existant, un schéma permet d'avoir une vue d'ensemble. Avec une base de données orientée graphe, on ne pourra se baser sur un seul nœud pour connaitre les cardinalités et attributs potentiels, mais regarder l'ensemble des données (ou se baser sur le code directement)
Cependant c'est la solution incontestables lorsque :
- vous auriez besoin de requêtes récursives sur une table relationnelle, cette notion de récursivité n'existe pas en graphe database car les objets ne sont pas stockés dans des tables structurées.
- vos recherches partent d'un objet précis et retournent les objets qui lui sont liés.
- vous souhaitez faire des recherches par motifs : (A)=like=>(B)<=like=(C) pour trouver les gens qui ont les même centres d’intérêt par exemple.
- vous avez atteint un cap avancé de dé-normalisation.
Entre deux il reste toute une gamme de cas d'utilisation où vous pouvez utiliser indifféremment l'une ou l'autre solution. Et gardez à l'esprit que nous sommes à l'ère de la Polyglot Persistence et qu'il ne faut pas forcement se restreindre à une seule solution de stockage.
A savoir tout de même que la version 2 de neo4J permettra l'utilisation de "labels" afin de pouvoir typer ces nœuds, et d'y définir des contraintes d'unicité sur certains champs (email dans le label Person par exemple), permettant ainsi à ceux et celles le désirant de retrouver un début de schéma.
A vous de jouer
Si le sujet vous intéresse, vous pouvez maintenant écouter l’épisode des CastCodeurs dédié à neo4J, regarder cette vidéo sur la théorie des graphes, ou encore lire l’excellent livre graphDatabase dont la première partie a très largement inspiré cet article.
Software gardener au quotidien, je suis adepte de TDD, d'XP et de tout ce qui peux me permettre de mener à bien mes missions
1 comment for “Pourquoi s’intéresser aux graph-databases ?”