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

Il y a vingt ans, mon équipe de développement a construit un moteur de traitement du langage naturel qui analysait les annonces d'emploi, d'automobile et d'immobilier pour les catégories de recherche. Je savais que nous avions un défi de gestion des données difficile. Les données de certains types d'annonces étaient relativement simples, comme l'identification des marques et des modèles de voitures, mais d'autres nécessitaient plus d'inférence, comme l'identification d'une catégorie d'emploi sur la base d'une liste de compétences.

Nous avons développé un modèle de métadonnées qui capturait tous les termes interrogeables, mais 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 des points de données dans une base de données relationnelle était complexe, nous avons donc exploré l'utilisation de bases de données d'objets pour gérer le modèle.

Ce que nous essayions d'accomplir à l'époque avec des bases de données d'objets peut être mieux fait aujourd'hui avec des bases de données graphiques. Les bases de données graphiques stockent des informations sous forme de nœuds et des données spécifiant leurs relations avec d'autres nœuds. Ce sont des architectures éprouvées pour stocker des données avec des relations complexes.

L'utilisation des bases de données Graph a certainement augmenté au cours de la dernière décennie, les entreprises envisageant d'autres technologies NoSQL et Big Data. Le marché mondial des bases de données de graphes était estimé à 651 millions de dollars en 2018 et devrait atteindre 3,73 milliards de dollars d'ici 2026. Mais de nombreuses autres technologies de gestion du big data, notamment Hadoop, Spark et d'autres, ont connu une croissance beaucoup plus significative de leur popularité, de l'adoption de compétences, et des cas d'utilisation de production par rapport aux bases de données graphiques. À titre de comparaison, la taille du marché de la technologie du Big Data était estimée à 36,8 milliards de dollars en 2018 et devrait atteindre 104,3 milliards de dollars d'ici 2026.

Je voulais comprendre pourquoi de plus en plus d'organisations n'envisagent pas les bases de données graphiques. Les développeurs pensent aux objets et utilisent régulièrement des représentations de données hiérarchiques en XML et JSON. Les technologues et les acteurs commerciaux comprennent intrinsèquement les graphiques puisque Internet est un graphique interconnecté par le biais d'hyperliens et de concepts tels que les amis et amis d'amis des réseaux sociaux. Alors pourquoi les équipes de développement n'ont-elles pas plus utilisé des bases de données graphiques dans leurs applications?

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

Bien qu'il puisse être relativement facile de comprendre la modélisation des nœuds et des relations utilisées dans les bases de données graphiques, leur interrogation nécessite l'apprentissage de nouvelles pratiques et compétences.

Regardons cet exemple de calcul d'une liste d'amis et d'amis d'amis. Il y a quinze ans, j'ai cofondé un réseau social de voyage et j'ai décidé de garder le modèle de données simple en stockant tout dans MySQL. La table stockant une liste d'utilisateurs avait une auto-jointure pour représenter les amis, et c'était une requête relativement simple pour extraire la liste d'un ami. Mais parvenir à un ami de la liste d'un ami nécessitait une requête monstrueusement complexe qui fonctionnait mais qui ne fonctionnait pas bien lorsque les utilisateurs avaient des réseaux étendus.

J'ai parlé avec Jim Webber, scientifique en chef chez Neo4j, l'une des bases de données graphiques établies, sur la façon de créer une requête d'amis d'amis. Les développeurs peuvent interroger les bases de données de graphes Neo4j en utilisant RDF (Resource Description Framework) et Gremlin, mais Webber m'a dit que plus de 90% des clients utilisent Cypher. Voici à quoi ressemble la requête dans Cypher pour extraire des amis et des amis d'amis:

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

WHERE me f

RETURN f

Voici comment comprendre cette requête:

  • Trouvez-moi le modèle où il y a un nœud avec l'étiquette Person et un nom de propriété: 'Rosa', et liez-le à la variable «me». La requête spécifie que «moi» a une relation FRIEND sortante à la profondeur 1 ou 2 avec tout autre nœud avec un libellé Personne, et lie ces correspondances à la variable «f».
  • Assurez-vous que «moi» n'est pas égal à «f», car je suis un ami de mes amis!
  • Renvoyez tous les amis et amis d'amis

La requête est élégante et efficace mais présente une courbe d'apprentissage pour ceux qui ont l'habitude d'écrire des requêtes SQL. C'est là que réside le premier défi pour les organisations qui s'orientent vers les bases de données graphiques: SQL est un ensemble de compétences omniprésentes, et Cypher et d'autres langages de requête graphique sont une nouvelle compétence à apprendre.

Conception de 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 catégoriser et étiqueter les informations. Le problème, bien sûr, est que certaines informations ne sont pas vraiment hiérarchiques et que les sujets doivent créer une approche cohérente pour structurer l'architecture de l'information. Cela peut être un processus douloureux, en particulier s'il y a un débat interne sur la structuration des informations, ou lorsque les utilisateurs finaux de l'application ne peuvent pas trouver les informations qu'ils recherchent parce qu'elles se trouvent dans une partie différente de la hiérarchie.

Non seulement les bases de données de graphes autorisent des hiérarchies arbitraires, mais elles permettent également 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 peut apparaître sous les hiérarchies d'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'utilisation courants de bases de données graphiques ou par rôles technologiques. Un moteur de recommandation dispose alors d'un ensemble de données beaucoup plus riche pour faire correspondre le contenu avec l'intérêt de l'utilisateur.

J'ai parlé à Mark Klusza, co-fondateur de Construxiv, une entreprise vendant des technologies à l'industrie de la construction, y compris Grit, une plateforme de planification de la construction. Si vous regardez le calendrier d'un projet de construction commerciale, vous verrez des références à plusieurs métiers, équipements, pièces et références de modèles. Un seul lot de travail peut facilement avoir des centaines de tâches avec des dépendances dans le plan de projet. Ces plans doivent intégrer les données des ERP, de la modélisation des informations du bâtiment et d'autres plans de projet et présenter des vues aux planificateurs, aux chefs de projet et aux sous-traitants. Klusza a expliqué: «En utilisant une base de données de graphes dans Grit, nous créons 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 conflits de planification des tâches. »

Pour tirer parti des hiérarchies flexibles, il aide à concevoir des applications à partir de zéro avec une base de données de graphiques. L'application entière est ensuite conçue en fonction de l'interrogation du graphique et de l'exploitation des nœuds, des relations, des étiquettes et des propriétés du graphique.

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

Le déploiement de solutions de gestion de données dans un centre de données n'est pas anodin. L'infrastructure et les opérations doivent tenir compte des exigences de sécurité; examiner les considérations de performances pour dimensionner les serveurs, le stockage et les réseaux; et aussi opérationnaliser les systèmes répliqués pour la reprise après sinistre.

Les organisations qui expérimentent des bases de données graphiques disposent désormais de plusieurs options cloud. Les ingénieurs peuvent déployer Neo4j sur GCP, AWS, Azure ou exploiter Aura de Neo4j, une base de données en tant que service. TigerGraph propose une offre cloud et des kits de démarrage pour des cas d'utilisation tels que le client 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. En outre, les fournisseurs de cloud public disposent de capacités de base de données de graphes, notamment AWS Neptune, l'API Gremlin dans Azure's CosmoDB, l'open source JanusGraph sur GCP ou les fonctionnalités de graphes d'Oracle Cloud Database Services.

Je reviens à ma question initiale. Avec tous les cas d'utilisation intéressants, les plates-formes de bases de données graphiques matures disponibles, les opportunités d'apprendre le développement de bases de données graphiques et les options de déploiement dans le cloud, pourquoi les organisations technologiques n'utilisent-elles pas davantage de bases de données graphiques?