Les graphes ne sont peut-être pas le futur des bases de données, mais ils ont le mérite de faciliter le traitement de données complexes et connectées à des coûts bien moindres qu’en utilisant des bases relationnelles classiques. Le Graph, c’est merveilleux… mais non interopérable en raison des langages divers et variés existants. Le futur standard GQL pourrait bien régler ce problème.
La théorie des graphes n’est pas récente. Dénes Kõnig en fait un théorème en 1926 et on le retrouve en informatique dès les années 60, avec notamment le NDL (Network Database Language) ou encore le support dans IBM IMS des structures en arborescence. Pourtant, il faut attendre les années 2000 pour que soient développées des bases de données Graph commerciales à l’instar de celles d’Oracle et de Neo4J. Entre temps, SQL s’est imposé comme le langage de référence dès lors qu’il s’agit de manipuler des données dans des bases de données relationnelles. Attention, il ne s’agit pas de mettre en concurrence bases de données relationnelles traditionnelles et bases de données orientées Graph : chacune sert des usages différents. Il sera plus aisé avec Graph, puisqu’il se base sur des nœuds et les liens entre eux, de modéliser des relations entre plusieurs tables, par exemple tel client a acheté tel pot de peinture à tel revendeur, quand SQL sera plus approprié lorsqu’il s’agira de déterminer combien de pots de peinture ont été vendus. Ou, comme nous l’explique Cédric Fauvet, responsable du Business Development France chez Neo4J, « SQL a dominé l’industrie pendant longtemps, mais ce n’est pas forcément la bonne technologie ni le bon langage pour tout, par exemple les données connectées. SQL répond a de très nombreux besoins mais il en est certains pour lesquels il vaut mieux utiliser des bases Graph».
Simple fonction
C’est d’autant plus vrai que, dans le cas de données complexes, réaliser une opération exploitant les relations entre les données via SQL nécessitera de faire des jointures, des bonds entre les tables, dans le cas de notre exemple précédent entre la table client, la table des pots de peinture et la table revendeur. Or plus il y a de jointures, plus le temps et le coût de traitement sont élevés. On pourra toutefois arguer qu’entre les bases de données multi-modèles et l’intégration de moteurs Graph dans les bases relationnelles, à l’instar de SQL Server depuis sa version 2017, le graphe est relégué au rang des fonctions des bases relationnelles traditionnelles et que la réflexion sur le choix d’une base Graph ou d’une base SQL n’a pas lieu d’être. Cédric Fauvet reconnaît que Graph peut effectivement être une fonction des bases de données. D’ailleurs, historiquement, Neo4j a fait ses débuts en qualité d’éditeur de moteur Graph. Mais il ne faut pas négliger le problème posé par les données elles-mêmes : « Si le moteur s’appuie sur des données et un stockage sous-jacent non Graph, au-delà d’un certain volume, qui est relativement bas, la transformation en données Graph ne fonctionnera pas puisque le temps nécessaire augmente de manière exponentielle.» Nicolas Rouyer, responsable avantventes chez Neo4j, abonde en ce sens : « Avec des technologies qui ne sont pas Graph-native, pour des questions de limitation de la mémoire disponible, les coûts et les durées de traitement vont exploser. Il faut bien distinguer la couche de peinture et le moteur sousjacent : on peut toujours représenter sous forme de graphe des données, le problème c’est le traitement derrière.» Ainsi l’ajout de fonctions Graph à leurs solutions par les éditeurs de bases relationnelles correspondrait surtout à un effet de mode, Graph étant devenu avec le Big Data un buzzword. Cédric Fauvet ajoute néanmoins que, pour tout un pan de l’industrie des bases noSQL, notamment les bases orientées colonnes, il n’existe pas de jointure, à moins de monter en mémoire les colonnes et de faire la jointure dans le code. Graph est pour ce secteur le moteur de jointure.
Mais, contrairement aux bases relationnelles avec SQL, les bases de données orientées graphes n’ont pas de langage standardisé. Entre SPARQL, basé sur le format Resource Description Framework (RDF), Gremlins, qui dépend du projet Apache TinkerPop, GraphQL, développé par Facebook et open source depuis 2015, GSQL de TigerGraph, Morpheus avec Apache Spark,PGQL d’Oracle ou encore Cypher, le langage de Neo4j décliné en OpenCypher, son pendant libriste, il y a de quoi s’y perdre et, surtout, les bases Graph, selon le langage choisi, ne sont pas interopérables.
De Cypher à Morpheus, GQL est-il Neo?
Et c’est là que GQL entre en scène. Projet né en 2017 de deux initiatives quasi-simultanées, d’Oracle d’une part et de Neo4j de l’autre, GQL a été inauguré en septembre 2019 comme projet officiel de l’ISO. Ce qui implique à terme que GQL deviendra un standard et sera aux bases Graph ce que SQL est aux bases relationnelles.
« Deux modèles de graphes sont actuellement utilisés : le modèle RDF (Resource Description Framework) et le modèle Property Graph », annonce le projet en préambule. « Le modèle RDF a été normalisé par le W3C dans un certain nombre de spécifications. Le modèle Property Graph, quant à lui, a une multitude d'implémentations dans des bases de données de graphes, des algorithmes de graphes et des installations de traitement de graphes. Cependant, il manque un langage de requête commun et standardisé pour Property Graph (comme SQL pour les systèmes de base de données relationnelle). GQL est proposé pour combler ce vide.»
Langage de requête de base de données déclaratif, comme SQL, GQL veut prendre le meilleur des deux mondes, à savoir l’intuitivité du parcours de graphe, sautant d’un nœud à l’autre liés par des relations, et la structuration du langage SQL, de sorte qu’il soit accessible au plus grand nombre. Une «colonne vertébrale» pour l’industrie du Graph, souligne Cédric Fauvet, et un moyen de rendre l’écosystème interopérable en y instaurant un minimum de formalisme. Évidemment, Neo4j étant l’un des fers de lance du projet, on retrouve beaucoup de Cypher dans GQL, ce dernier empruntant au premier les représentations visuelles des topologies de nœuds et de relations. Une «inspiration» assure pourtant Cédric Fauvet. Pour Nicolas Rouyer, il est dans l’intérêt de Neo4j de « donner un standard à l’industrie. C’est aussi une question de maturité du marché : les bases Graph sont en forte croissance ». Et plutôt que d’être contraint de couper le gâteau en parts toujours plus petites, l’éditeur préfère agrandir le gâteau, c’est le sens de ce travail autour d’un standard commun.
Avec, pour les entreprises utilisatrices, une promesse de valeur. Car il ne s’agit pas de faire de la techno pour le plaisir de faire de la techno : les bases Graph permettent de ne pas s’intéresser qu’à la valeur intrinsèque des données mais aussi à la façon dont elles sont interconnectées. « Ces informations sont souvent présentes dans les bases de données des entreprises mais pas valorisées car les outils historiques ne permettent pas d’analyser ces relations », indique Cédric Fauvet. Soit une mine d’or qui n’attend que d’être exploitée. Et à ce point-là du récit, vous aurez certainement compris la suite : données complexes et connectées + volumes importants = IA. Ou plus exactement la Graph Datascience, qui selon Neo4j permet non seulement une meilleure précision, mais aussi et surtout d’expliquer les choix de l’IA. Et pour ce faire, il suffit de remonter les relations, nœud par nœud, pour comprendre comment un algorithme est parvenu à telle ou telle conclusion. Le graph va notamment être utilisé dans la détection de fraudes, le parcours client en marketing ou le parcours de soin en santé, un sujet particulièrement sensible par les temps qui courent.
