Graphe : Neo4j attend de pied ferme un langage de requête standard
Depuis trois ans, l’ISO/IEC œuvre à la normalisation d’un langage de requête type pour les bases de données orientées graphes. Les éditeurs, dont Neo4j, sont très attentifs concernant l’évolution de ce projet.
En septembre 2019, la filiale ISO/IEC du Joint Technical Committee 1 (JTC1), responsable de la standardisation des technologies au niveau international, annonçait la création du projet GQL pour Graph Query Language. C’est le deuxième de langage de requête à faire l’objet d’une norme internationale.
En effet, le groupe de travail « database languages » (WG3) de l’ISO/IEC n’a – depuis 1987 – standardisé qu’un seul langage de requête : SQL. Celui-ci est particulièrement utilisé pour interroger les bases de données relationnelles.
« Il y a quelques années, nous sommes allés à l’ISO et nous avons dit, “regardez, nous pensons que les graphes sont suffisamment importants et suffisamment distincts des autres types de données, que ce serait une bonne idée de leur attribuer un langage de requête spécifique” », relate Jim Webber, Chief Scientist chez Neo4j.
« Et à l’époque, en tant que membres du groupe, nous étions absolument convaincus que c’était vrai. Mais nous avions également compris qu’historiquement SQL avait tout dévoré ».
En effet, le standard SQL a petit à petit englobé d’autres sous-ensembles comme les objets ou XML.
« L’une des choses qui auraient pu se produire, c’est que ce groupe de travail plein de gens extrêmement expérimentés insère les graphes dans ce standard », ajoute Jim Webber. « Mais ça ne s’est pas passé comme ça ». Pas vraiment.
En route pour un deuxième langage de requête standard
Car trois jours après l’approbation du projet GQL le 13 septembre 2019, le SC32 (le sous-comité gestion et échanges de données de l’ISO/IEC qui englobe le groupe de travail WG3) validait la proposition 9075-16 : Property Graph Queries (SQL/PGQ). En clair, une manière d’appeler un modèle graphe en lecture seule à l’aide du langage SQL par-dessus une base de données relationnelle.
Sur le papier, les entités WG3 et SC32 semblent avoir fait exactement le contraire de ce qu’affirme le Chief Scientist de Neo4j. Sur le papier seulement, et vu de très loin. En effet, L’ISO/IEC travaille en coordination avec son homologue américain, l’ANSI. Plus précisément, sa filiale INCITS (International Committee for Information Technology Standards) et son groupe DM32 (un miroir du SC32), avaient déjà œuvré à la naissance de SQL/PGQ.
Cependant, GQL est voué à chapeauter le sous-ensemble SQL/PGQ. Pour Jim Webber, l’ISO/IEC a donc reconnu que le langage graphe était suffisamment spécifique pour avoir le droit à son propre standard.
« [Les responsables de l’ISO/IEC] ont reconnu que les besoins des graphes sont distincts des besoins liés au SQL », assure Jim Webber. « Le SQL ne peut pas englober facilement un modèle graphe, parce qu’ils dépendent de deux modèles mathématiques très différents ».
« Le SQL ne peut pas englober facilement un modèle graphe, parce qu’ils dépendent de deux modèles mathématiques très différents ».
Jim WebberChief Scientist, Neo4j
C’est ce que défend la représentante de l’éditeur dans un groupe « informel » monté dans le cadre de l’initiative de standardisation. Autour de la table, des ingénieurs d’autres fournisseurs de SGBD orienté graphe, dont TigerGraph et HypergraphDB, mais aussi Oracle et Redis Labs.
Un standard en faveur d’une « explosion de l’usage »
Neo4j, étant l’un des plus anciens acteurs sur la place à proposer une base de données orientée graphes, se sent l’un des éditeurs les plus expérimentés à travailler sur le sujet. Il en est à son troisième langage de requête avec Cypher, et sa déclinaison open source, OpenCypher.
« Nous profitons de cette expérience et nous la partageons avec la communauté de l’ISO afin que la notion de langage déclaratif à correspondance de motifs (pattern matching language en VO) soit à la base de GQL », affirme Jim Webber.
« Si vous comparez le brouillon actuel de GQL et Cypher, il est clair que les deux langages sont en train de converger », poursuit le Chief Scientist.
Et au moment où le standard sera prêt, la migration de l’un à l’autre devrait représenter un « effort minime ». Jim Webber anticipe que Neo4j supportera l’un ou l’autre langage de requête suivant les prérequis des clients. « Nous voulons faire comme Microsoft avec Windows : assurer un bon niveau de rétrocompatibilité des requêtes Cypher ».
Concernant, le standard GQL, les attentes du Chief Scientist sont grandes.
« Je pense que le standard GQL provoquera ce que le SQL a provoqué dans le monde relationnel : une explosion de l’usage », espère-t-il. Il faut dire que Gartner a prédit l’avènement des modèles graphes en 2021. Il faudra bien un jour que la/(l’auto ?) prophétie se réalise.
« Il n’y aura plus à apprendre dix langages, mais un seul, et toutes les solutions des éditeurs seront en partie interopérables – dans une certaine mesure ». Cela devrait empêcher – idéalement – l’enfermement propriétaire.
Une date de publication inconnue
Encore faut-il que les deux projets de normes passent les phases quatre (rédaction en comité), cinq (enquête publique), six (approbation) et sept (publication) du processus de standardisation.
Pour le moment, SQL/PGQ est plus avancé que le projet GQL. Property Graph Queries est au stade de ballottage DIS de l’enquête (phase cinq). En clair, le projet est soumis une première fois à l’avis du public, et les groupes de travail ont jusqu’au 27 décembre 2022 pour valider l’enquête.
Oracle n’a pas attendu la septième phase pour annoncer la prise en charge du futur standard SQL/PGQ dans Oracle 23c.
De son côté, GQL en est au deuxième stade de la phase trois : le comité chargé de GQL a délivré son brouillon du standard (nommé CD, pour Committee Draft), qui a été soumis au vote le 26 octobre 2022.
Aucune date n’a été communiquée quant à la fin de la procédure de normalisation. En moyenne, l’ISO mettrait 3 à 5 ans afin d’écrire et publier une norme. L’ISO 9075, la première version de la norme relative à SQL édité par l’ANSI, avait été adoptée en quatre ans.
