Pourquoi les développeurs devraient utiliser des bases de données graphiques

Isaac Sacolick d’Infoworld raconte qu’il y a vingt ans, son équipe de développement avait construit un moteur de traitement du langage naturel qui scannait les petites annonces d'emploi, d'automobile et d'immobilier pour en extraire des catégories pouvant être interrogées par les moteurs de recherche. Il savait que le défi serait difficile à relever en matière de gestion des données. Si les données de certains types d'annonces étaient relativement simples, comme l'identification des marques et le modèle des voitures, d'autres nécessitaient plus d'inférence, par exemple l'identification d’un type d'emploi en fonction des compétences requises.

Alors que ladite équipe a mis au point un modèle de métadonnées capable de saisir tous les termes pouvant être recherchés, le moteur de traitement du langage naturel exigeait que le modèle expose des relations de métadonnées significatives. « Nous savions que la conception d'un modèle de métadonnées avec des connexions arbitraires entre les points de données dans une base de données relationnelle était complexe, nous avons donc exploré l’usage de bases de données objets pour gérer le modèle », explique encore Isaac Sacolick. Ce qu’il essayait d'accomplir à l'époque avec des bases de données objets peut être mieux réalisé aujourd'hui avec des bases de données graphiques. Les bases de données graphiques stockent des informations sous forme de nœuds et de données spécifiant leurs relations avec d'autres nœuds. Ce sont des architectures éprouvées pour le stockage de données ayant des relations complexes.

Une technologie proche des hyperliens

Au cours de la dernière décennie, l’usage des bases de données graphiques a certainement augmenté, en particulier parce que les entreprises se sont intéressées à d'autres technologies NoSQL et Big Data. En 2018, le marché mondial des bases de données graphiques était estimé à 651 millions de dollars et il devrait atteindre 3,73 milliards de dollars d'ici 2026. Mais beaucoup d'autres technologies de gestion de données big data, dont Hadoop, Spark et d'autres, ont connu une croissance beaucoup plus importante en termes de popularité, d’acquisition de compétences et de cas d’usage en production par rapport aux bases de données graphiques. Comparativement, en 2018, le marché des technologies big data était estimé à 36,8 milliards de dollars et devrait atteindre 104,3 milliards de dollars en 2026.

Isaac Sacolick voulait comprendre pourquoi plus d’entreprises n'envisageaient pas d'utiliser des bases de données graphiques. Les développeurs pensent en objets et utilisent régulièrement des représentations de données hiérarchiques en XML et JSON. Les experts en technologies et les acteurs du monde des affaires comprennent intimement les graphes puisque l'Internet est un graphe interconnecté par des hyperliens et des concepts comme celui « d’amis » et « d’amis d’amis » des réseaux sociaux. Alors, pour quelle raison leurs équipes de développement ne sont-elles pas plus nombreuses à utiliser des bases de données graphiques dans leurs applications ?

Apprendre les langages de requête des bases de données graphiques

Si la compréhension des relations utilisées dans les bases de données graphiques peut être relativement facile, leur interrogation nécessite l'apprentissage de nouvelles pratiques et compétences. Voici, à titre d’exemple, un calcul de liste « d'amis » et « d'amis d'amis ». Il y a quinze ans, Isaac Sacolick a cofondé un réseau social de voyage et, afin d’avoir un modèle de données simple, il avait tout stocké dans MySQL. La table dans laquelle était stockée la liste d'utilisateurs incluait une fonction d’auto-adhésion pour représenter les amis, et il était relativement simple d'extraire la liste d'un ami. Mais pour accéder à la liste d'un ami d’ami, il fallait une requête monstrueusement complexe qui fonctionnait, mais n'était pas performante quand les réseaux d’utilisateurs étaient étendus. Pour améliorer cette requête « d'amis d'amis », Isaac Sacolick a consulté Jim Webber, responsable scientifique de Neo4j, une base de données graphiques bien établie parmi d’autres. Les développeurs peuvent interroger les bases de données graphiques de Neo4j en utilisant RDF (Resource Description Framework) et Gremlin, mais selon M. Webber, plus de 90 % des clients utilisaient Cypher.

Voilà à quoi ressemble la requête dans Cypher pour l'extraction « d'amis » et « d'amis d'amis » :

MATCH (me:Person {name:'Rosa'})-[:FRIEND*1..2]->(f:Person)

WHERE me <> f

RETURN f

Et voilà comment comprendre cette requête :

• Trouvez-moi le modèle où il y a un nœud avec le label « Person » et un nom de propriété : « Rosa », et liez cela à la variable « me ». La requête spécifie que « me » a une relation FRIEND sortante de niveau 1 ou 2 avec tout autre nœud avec un label « Person », et lie ces correspondances à la variable « f ».

• Assurez-vous que « me » n'est pas égal à « f », car je suis un ami de mes amis !

• Retournez tous les « amis » et « amis d'amis »

La requête est élégante et efficace, mais sa courbe d'apprentissage est importante pour les personnes habituées à écrire des requêtes SQL. C'est là que se situe le premier défi pour les entreprises qui s’intéressent aux bases de données graphiques : le SQL demande des compétences étendues, mais pour utiliser Cypher et d'autres langages de requête de graphes, il faut aussi acquérir de nouvelles compétences.

Concevoir des hiérarchies flexibles avec des bases de données graphiques

Les catalogues de produits, les systèmes de gestion de contenu, les applications de gestion de projet, les ERP et les CRM utilisent tous des hiérarchies pour classer et étiqueter les informations. Le problème, bien sûr, est que certaines informations ne sont pas vraiment hiérarchisées, et les sujets doivent créer une approche cohérente pour structurer l'architecture de l'information. Ce processus peut être compliqué, surtout s'il y a un débat interne sur la structuration de l'information, ou si les utilisateurs finaux des applications ne peuvent pas trouver l'information qu'ils recherchent parce qu'elle se trouve ailleurs dans l’arborescence.

Les bases de données graphiques permettent non seulement de créer des hiérarchies arbitraires, mais elles permettent aussi aux développeurs de créer différentes vues de la hiérarchie pour différents besoins. Par exemple, cet article sur les bases de données graphiques pourrait apparaître dans différentes catégories, comme un système de gestion de contenu pour la gestion des données, les technologies émergentes, les industries susceptibles d'utiliser des bases de données graphiques, les cas d’usage courants des bases de données graphiques, ou par rôles technologiques. Un moteur de recommandation disposera alors d'un ensemble de données beaucoup plus riche pour faire correspondre le contenu aux intérêts des utilisateurs.

Isaac Sacolick a également consulté Mark Klusza, co-fondateur de Construxiv, une entreprise qui vend des technologies à l'industrie du bâtiment, et notamment Grit, une plateforme de planification de la construction. Le déroulé dans le temps d'un projet de construction comporte des références à de multiples métiers, équipements, pièces et modèles. Un seul groupe peut facilement comporter des centaines de tâches avec des dépendances dans le plan du projet. Ces plans doivent intégrer des données provenant des ERP, de la modélisation des informations sur les bâtiments%20is,and%20manage%20buildings%20and%20infrastructure.) et d'autres plans de projet et présenter des vues aux planificateurs, aux chefs de projet et aux sous-traitants. Mark Klusza explique qu’en utilisant une base de données graphique dans Grit, il peut créer des relations beaucoup plus riches sur qui fait quoi, quand, où, avec quel équipement, et avec quels matériaux. « Cela nous permet de personnaliser les vues et de mieux prévoir les incohérences dans le planning de travail ». Pour tirer parti de la souplesse des hiérarchies, il est utile de concevoir des applications à partir de la base de données graphique. L'application entière est alors conçue en interrogeant le graphe et en exploitant les nœuds, les relations, les étiquettes et les propriétés du graphe.

Les options de déploiement dans le cloud réduisent les complexités opérationnelles

Le déploiement de solutions de gestion des données dans un datacenter n'est pas anodin. L'infrastructure et les opérations doivent tenir compte des exigences de sécurité, reconsidérer les questions de performance pour augmenter la taille des serveurs, du stockage et des réseaux, et rendre opérationnels les systèmes répliqués pour la reprise après sinistre. Les entreprises qui expérimentent des bases de données graphiques disposent désormais de plusieurs options de déploiement dans le cloud. Les ingénieurs peuvent déployer Neo4j dans GCP, AWS, Azure, ou utiliser Aura de Neo4j, une base de données en tant que service. TigerGraph propose aussi une offre cloud et des kits de démarrage pour des cas d’usage comme l’expérience qualité Customer 360, la détection de fraude, les moteurs de recommandation, l'analyse des réseaux sociaux et l'analyse de la chaîne d'approvisionnement. Les fournisseurs de cloud public disposent aussi de capacités de base de données graphiques, comme AWS Neptune, l'API Gremlin pour CosmoDB d'Azure, le logiciel open source JanusGraph pour GCP, ou les fonctions graphiques dans les services de base de données cloud d'Oracle.

Au final, si l’on prend en compte tous les cas d’usage intéressants, le nombre de plates-formes de bases de données graphiques matures disponibles, les possibilités existantes pour se former au développement de bases de données graphiques et les options de déploiement dans le cloud, il y a lieu de se demander pourquoi les entreprises technologiques n'utilisent pas davantage les bases de données graphiques. La question initiale posée par Isaac Sacolick reste donc entière !