Comparatif de bases de données graphiques : Neo4j vs FalkorDB vs Memgraph

Nous avons comparé les performances de Neo4j, FalkorDB et Memgraph sur un graphe synthétique issu de 120 000 avis clients Amazon (381 000 nœuds, 804 000 arêtes). Nous avons exécuté 12 modèles de requêtes avec 1 000 mesures chacun, testé l'ingestion avec 6 tailles de lots différentes, maintenu une charge simultanée pendant 60 secondes avec jusqu'à 32 threads, et mesuré l'impact sur la mémoire, le démarrage à froid, la charge de travail mixte et l'indexation.

FalkorDB a offert un débit supérieur à celui de Neo4j et de Memgraph avec 8 threads.

résultats de l'analyse comparative des bases de données graphiques

Débit simultané

Le QPS (requêtes par seconde) mesure le nombre de requêtes de lecture auxquelles la base de données répond par seconde sous une charge multithread soutenue. Chaque exécution dure 60 secondes. Plus le QPS est élevé, mieux c'est.

Latence de requête (p50)

p50 correspond à la latence médiane : la moitié des requêtes s’exécutent plus rapidement que cette valeur. Plus elle est basse, mieux c’est.

• Recherche ponctuelle : Récupérer un nœud unique par son ID. Les tables de hachage Redis de FalkorDB effectuent des recherches en mémoire en O(1), soit environ 3 fois plus rapides.
• Parcours : déplacement d’un nœud vers ses voisins (1 saut) ou vers les voisins de ses voisins (2 sauts). FalkorDB effectue le parcours en 2 sauts 2,9 fois plus rapidement.
• Agrégation : Compter les avis par marque, calculer la note moyenne en étoiles.
• Filtrer + analyser : Filtrer les avis par note (étoiles) sur l'ensemble des données.

Débit d'ingestion

Le débit d'ingestion mesure le nombre d'avis par seconde que la base de données peut traiter. Chaque point du graphique correspond à une taille de lot différente : le nombre d'avis regroupés dans une seule requête. Plus la valeur est élevée, mieux c'est.

Avec une taille de lot de 1, Memgraph domine (1 427 requêtes/s). À mesure que la taille du lot augmente, FalkorDB connaît une forte montée en puissance et dépasse Memgraph aux alentours du lot 500. Neo4j se stabilise à environ 10 600 requêtes/s, quelle que soit la taille du lot. Avec un lot de 5 000, FalkorDB atteint 22 784 requêtes/s, soit 77 fois sa performance avec un lot de 1.

Vous pouvez en savoir plus sur notre méthodologie d'analyse comparative des bases de données graphiques .

Principales conclusions

FalkorDB atteint 6 693 requêtes par seconde (QPS) sur 8 cœurs, soit 6,7 fois les performances de Neo4j.

Les structures de données en mémoire et la boucle d'événements de Redis lui permettent de combiner des requêtes à faible latence et un parallélisme élevé. Au-delà de 8 threads, le débit plafonne car le cœur monothread de Redis atteint ses limites. Neo4j atteint un pic à 16 threads (1 010 requêtes par seconde) puis chute à 32 (927 requêtes par seconde), ce qui indique une contention des threads.

Le démarrage à froid de FalkorDB s'effectue en 1,1 ms, soit 82 fois plus rapidement que Neo4j.

Neo4j met 90 ms à accepter sa première requête après un redémarrage. La première requête de préchauffage s'exécute en 274 ms, puis il faut environ trois requêtes pour que le temps de réponse se stabilise à 34 ms. FalkorDB est opérationnel en 1,1 ms, la première requête s'exécutant en 0,4 ms. Dans une architecture de microservices ou sans serveur où le nombre de pods est ajusté à la hausse ou à la baisse, cet écart est significatif.

Indexation : différence de 1 700x sur Neo4j, d’environ 1x sur FalkorDB

Sans index, la requête deep_feature_products de Neo4j a pris 293 ms. Avec index, 0,17 ms. Soit une différence d'un facteur 1 712. Memgraph a affiché une sensibilité similaire (de 160 à 898 selon la requête). Les résultats de FalkorDB sont restés sensiblement les mêmes avec ou sans index, car les tables de hachage Redis fonctionnent déjà comme des index implicites.

Mémoire : 415 Mo contre 2 668 Mo pour le même graphique

• Mémoire : 415 Mo
• FalkorDB : 496 Mo
• Neo4j : 2 668 Mo (mémoire JMX utilisée)

La JVM de Neo4j pré-alloue 4 Go au démarrage, de sorte que sa mémoire au niveau du processus (VmRSS) est toujours d'environ 5,2 Go, indépendamment de l'utilisation réelle des données. La métrique du tas JMX est la plus pertinente. Le pic de 2,7 Go est la valeur à prendre en compte pour la planification de la capacité.

Neo4j a remporté le plus gros agrégat

FalkorDB a affiché la latence la plus faible sur 11 des 12 requêtes. L'exception était agg_feature_sentiment (regroupement par sentiment avec filtrage), où l'optimiseur de requêtes de Neo4j a produit un meilleur plan d'exécution : 131 ms contre 152 ms pour FalkorDB.

Charge de travail mixte (80 % lecture, 20 % écriture)

8 threads, 60 secondes, zéro erreur sur les trois bases de données :

• FalkorDB : 50 223 opérations (837 QPS)
• Neo4j : 44 256 opérations (738 QPS)
• Memgraph : 28 040 opérations (467 QPS)

Les opérations d'écriture n'ont pas sensiblement dégradé les performances de lecture sur aucun d'entre eux.

Architectures dans ce référentiel

Chaque base de données possède sa propre interface de gestion. Ces captures d'écran montrent le même jeu de données (16 127 nœuds, 24 318 arêtes) chargé dans les trois bases, exécutant la même requête de parcours COMPARED_WITH.

FalkorDB

FalkorDB est un module graphique basé sur le système de stockage clé-valeur en mémoire de Redis. Les requêtes utilisent OpenCypher, mais reposent sur des tables de hachage Redis. C'est pourquoi les recherches de points s'effectuent en 0,044 à 0,048 ms.
Les deux autres bases de données de ce test ont obtenu des résultats 2 à 3 fois supérieurs sur les mêmes requêtes. En contrepartie, le noyau monothread de Redis limite le débit simultané à 8 threads.

Neo4j

Neo4j s'exécute sur la JVM. La compilation JIT permet d'accélérer les requêtes répétées au fil du temps (temps de chauffe : 274 ms → 34 ms). Les pauses du GC affectent la latence de queue, mais sont compensées par la suppression des valeurs aberrantes de l'IQR. L'optimiseur de requêtes gère efficacement les plans d'agrégation complexes, ce qui explique le gain obtenu avec agg_feature_sentiment. Ce gain est dû à la pré-allocation de 4 Go de mémoire et à la surcharge du GC.

Memgraph

Memgraph est écrit en C++. Aucune surcharge JVM. Avec seulement 415 Mo pour l'ensemble des données, c'est le plus léger des trois. Il est le plus rapide pour les insertions individuelles (1 427/s) grâce à une surcharge minimale par requête. Cependant, son débit simultané est plus faible (684 QPS en pointe). Compatible Bolt, il fonctionne avec le pilote Neo4j.

Méthodologie d'évaluation comparative des bases de données graphiques

Environnement

• RunPod 8 vCPU (AMD EPYC x86_64), 32 Go de RAM, Ubuntu 24.04 LTS
• Installation native, sans Docker. Les trois bases de données sont sur la même machine, connexions localhost.
• Python 3.12.3. Sessions persistantes pour les tests monothread, sessions par appel à partir d'un pool de connexions pour les tests multithread.

Données

• 120 000 avis synthétiques générés à partir de distributions Zipf (marques, caractéristiques) et Poisson (entités, relations), graine fixe = 42.
• 6 types de nœuds : Avis, Produit, Évaluateur, Marque, Fonctionnalité, Catégorie
• 8 types d'arêtes : À PROPOS, ÉCRIT PAR, DANS LA CATÉGORIE, FABRIQUÉ PAR, A UN AVIS POSITIF, A UN AVIS NÉGATIF, MENTIONS, COMPARÉ AVEC

Requêtes

12 modèles Cypher répartis en 5 catégories : recherche de point (3), parcours à 1 saut (2), parcours à 2 sauts (2), agrégation (3), filtrage (1), analyse complète (1). Chaque requête paramétrée s’exécute avec 10 valeurs de paramètres différentes, 100 fois chacune, pour 1 000 mesures par requête et par base de données.

Les paramètres sont échantillonnés dans l'espace complet des identifiants à l'aide d'une sélection pondérée par Zipf, ce qui permet de tester à la fois les éléments populaires et rares.

Trois exemples :

Recherche de point : Récupérer un nœud unique par son ID indexé

Parcours en deux étapes : Passez d’une marque à ses produits, puis consultez les avis des utilisateurs.

Agrégation : Analyse complète du graphe avec jointure multi-sauts et calcul

Mesures

• Durée : time.perf_counter_ns(), 500 requêtes d’échauffement, minimum de 100 exécutions par requête
• Statistiques : 10 000 échantillons bootstrap, intervalle de confiance à 95 %, suppression des valeurs aberrantes (facteur 3,0x). Les données brutes et filtrées sont présentées.
• Mémoire : Neo4j via le tas JMX utilisé (VmRSS n'a aucun sens car la JVM pré-alloue), FalkorDB via Redis used_memory_rss, Memgraph via /proc/{pid}/status VmRSS.

Justice

• Même taille de pool de connexions, même nombre de connexions d'échauffement, mêmes requêtes Cypher, mêmes données et mêmes machines pour les trois bases de données.
• Test de concurrence : charge soutenue de 60 secondes sur 1, 2, 4, 8, 16 et 32 threads avec une taille de pool fixe de 32. Mix de requêtes : 40 % de parcours à 1 saut, 30 % de parcours à 2 sauts, 20 % d’agrégation, 10 % de parcours à 3 sauts.
  

Bases de données testées

Limites

Une seule machine, un seul nœud par base de données. Aucun test de performance distribué ou en cluster. Le clustering Neo4j Enterprise et la réplication Memgraph ne sont pas inclus dans le périmètre.

Données synthétiques dont les distributions sont issues d'avis clients Amazon réels. Elles peuvent ne pas correspondre aux modèles de charge de travail spécifiques à la production.

Non mesurés : persistance/récupération du disque, recherche en texte intégral, algorithmes de graphes (PageRank, détection de communautés) et charges de travail à forte intensité d’écriture (> 50 % d’écritures).

Pilotes différents : Neo4j et Memgraph utilisaient le pilote Python de Neo4j, tandis que FalkorDB utilisait le sien. La différence de latence était inférieure à 0,5 ms lors des tests monothread.

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire