Quand utiliser une base de données graphe telle que Neo4j

Une base de données en graphe représente les données sous forme de nœuds (entités) et d’arêtes (relations entre les entités). Chaque arête est un objet à part entière, doté d’un type et de ses propres propriétés. Contrairement aux bases de données relationnelles ou documentaires, où les relations sont déduites de clés étrangères ou de références intégrées, les bases de données en graphe stockent les relations comme des connexions explicites, avec un parcours en O(1) pour chaque saut : suivre une relation prend un temps constant, quelle que soit la taille de la base de données.

Les bases de données documentaires et relationnelles sont optimisées pour retrouver des entités — récupérer un utilisateur par son identifiant, interroger les commandes par statut. Elles peinent à parcourir les relations — « trouver tous les amis des amis d’Alice qui ont acheté le même produit qu’Alice au cours du dernier mois ». Chaque saut nécessite un $lookup ou une jointure. Trois sauts de profondeur impliquent trois jointures imbriquées. À 10 sauts sur des millions de nœuds, les performances de MongoDB se dégradent de façon exponentielle, tandis que celles de Neo4j restent stables.

Neo4j est la base de données en graphe la plus répandue. Elle utilise le langage de requête Cypher, un langage déclaratif fondé sur des motifs pour parcourir les graphes. Une requête Cypher décrit le motif de graphe recherché à l’aide d’une notation en ASCII : les nœuds sont représentés par () et les relations par -[]->. Le moteur de requêtes trouve efficacement tous les sous-graphes correspondant au motif grâce à une adjacence native sans index.

Les systèmes de recommandation reposent sur le parcours de réseaux de relations : « les utilisateurs qui ont acheté ce que vous avez acheté ont également acheté X ». Dans un graphe, chaque achat est une arête entre un nœud utilisateur et un nœud produit. Trouver des recommandations par filtrage collaboratif consiste en un parcours à deux sauts : Utilisateur → Produit → (autres utilisateurs ayant acheté ce produit) → (autres produits achetés par ces utilisateurs). Neo4j gère des millions de ces parcours par seconde. Le $graphLookup de MongoDB peut effectuer cette opération, mais ses performances se dégradent à grande échelle.

Les réseaux de fraude impliquent souvent des informations d’identité partagées : plusieurs comptes utilisant le même identifiant d’appareil, numéro de téléphone, adresse IP ou adresse de facturation. Les bases de données en graphe excellent dans la détection de ces réseaux en parcourant les relations : « trouver tous les comptes reliés à ce compte suspect par des attributs communs en trois sauts maximum ». L’évaluation de la fraude en temps réel au moment de la transaction — interroger en quelques millisecondes un graphe couvrant des millions d’entités liées — est une force native de Neo4j que MongoDB ne peut égaler.

Un graphe de connaissances modélise les entités et leurs relations sémantiques — comme les informations de Wikipédia structurées sous forme de graphe. Les graphes de connaissances alimentent la reconnaissance des entités par les moteurs de recherche, les réponses factuelles des assistants d’IA et les ontologies d’entreprise. Le modèle en graphe s’y adapte naturellement : Personne connaît Personne, Personne worksAt Entreprise, Entreprise isLocatedIn Ville, Ville isCapitalOf Pays. Le parcours de ces chaînes sémantiques est précisément ce pour quoi les bases de données en graphe sont conçues.

Tous les problèmes de graphe ne nécessitent pas Neo4j. Le $graphLookup de MongoDB gère assez bien les parcours d’arbres et de graphes dans les cas suivants : hiérarchies peu profondes (moins de 5 ou 6 sauts) ; graphes de taille modérée (quelques milliers à quelques millions de nœuds) ; et requêtes de parcours peu fréquentes pouvant tolérer une latence plus élevée. Si les requêtes sur le graphe constituent une fonctionnalité secondaire d’une application principalement fondée sur des données documentaires, tout conserver dans MongoDB simplifie considérablement la pile technique.

Choisissez Neo4j (ou une autre base de données en graphe) lorsque les parcours profonds sur plusieurs sauts constituent une fonctionnalité essentielle (réseaux sociaux, graphes de connaissances, détection de fraude) ; lorsque la relation elle-même porte des propriétés riches (par exemple, une arête FOLLOWS enregistrant la date du suivi et indiquant s’il est réciproque) ; lorsque les requêtes sur le graphe doivent renvoyer des résultats en temps réel avec une forte concurrence ; ou lorsque l’ensemble du domaine est centré sur les relations plutôt que sur les entités. Pour les réseaux sociaux, les graphes d’identités, les topologies réseau et les graphes de dépendances, choisissez Neo4j.

De nombreux systèmes de grande taille utilisent une persistance polyglotte — des bases de données différentes pour des besoins différents. Une plateforme sociale peut stocker les profils utilisateurs et les publications dans MongoDB (requêtes documentaires riches), les graphes d’amitié et d’intérêts dans Neo4j (parcours rapides), les données de session dans Redis (recherches en moins d’une milliseconde) et les analyses dans un système en colonnes. Chaque base de données fait ce qu’elle sait le mieux faire. La difficulté consiste à gérer la cohérence entre les systèmes, mais les gains de performances et d’évolutivité justifient souvent cette complexité.

Dans MongoDB, une relation sociale est modélisée comme un document dans une collection follows, avec les champs followerId et followeeId. Dans Neo4j, il s’agit d’une arête FOLLOWS reliant directement deux nœuds User. Le modèle en graphe élimine la collection intermédiaire et permet un parcours direct fondé sur des pointeurs. Le modèle documentaire convient mieux pour récupérer les données du profil d’un utilisateur ; le modèle en graphe convient mieux pour parcourir ses connexions sociales.

Les arêtes d’un graphe Neo4j possèdent un type (semblable à une étiquette) et peuvent avoir des propriétés. Un graphe social peut contenir les types d’arêtes FOLLOWS, LIKES, PURCHASED et REVIEWED, chacun possédant ses propres propriétés. Les requêtes Cypher peuvent rechercher selon le type d’arête et filtrer selon les propriétés des arêtes, ce qui permet d’effectuer des requêtes riches sur les relations. Cette approche est bien plus naturelle que de stocker un champ type dans une collection relationships de MongoDB et d’effectuer une jointure dessus.

Dans cette leçon, vous avez appris que les bases de données en graphe comme Neo4j excellent dans les parcours relationnels profonds sur plusieurs sauts — moteurs de recommandation, détection de fraude et graphes de connaissances — là où les chaînes de $lookup de MongoDB se dégradent de façon exponentielle ; que le langage Cypher de Neo4j exprime les motifs de graphe de manière déclarative, d’une façon qu’aucun langage de requête documentaire ne peut égaler ; et que la persistance polyglotte, qui consiste à utiliser MongoDB pour les données documentaires et Neo4j pour parcourir les relations, est une architecture courante en production. Nous allons maintenant aborder le projet final : concevoir l’architecture d’une application MongoDB prête pour la production.