gDown Performances

Durabilité des bases mesurées

Pour ces chiffres de performances, toutes les bases sont mesurées en mode persistant (données écrites sur disque, rejouées au redémarrage).

Bases mesurées

Comment le banc tourne

Démarrage, mémoire, CPU et taille

Sans index

Avec index sur les identifiants

Démarrage : du docker run à la première réponse à RETURN 1, médiane de plusieurs essais, mesuré une fois et repris dans les deux configurations ; les autres lignes couvrent toute l'exécution des charges. Le CPU et le disque ne sont pas classés : une base qui n'écrit rien de durable a 0 Mo sur disque.

Lectures complexes : latence médiane — LDBC SNB Interactive

Les 29 requêtes de la charge Interactive du Social Network Benchmark du LDBC (14 lectures complexes, 7 lectures courtes, 8 mises à jour ; Apache 2.0, inchangées) tournent toutes sur un graphe engendré au schéma SNB.

• 29 / 29 requêtes exécutées : 14 lectures complexes, 7 lectures courtes, 8 mises à jour
• 3 / 3 membres d'un cluster à 3 nœuds renvoient les mêmes nombres de lignes pour les 21 lectures
• 18 ms médiane d'une écriture pendant que le leader en acquitte 1 365 (3 000 personnes)
• 0 ms médiane d'une lecture sur un suiveur pendant ces écritures (95e centile : 30 ms)

Toutes les bases, 3,000 personnes

Un tiret : la base refuse la requête, dépasse son délai ou renvoie un nombre de lignes différent de Neo4j (son temps ne voudrait rien dire). Cas par cas :

Toutes les bases, 30,000 personnes

• complex-1 : gDown 12.9 ms, Neo4j 51.5 ms
• complex-2 : gDown 2.8 ms, Neo4j 2 ms
• complex-3 : gDown 15.1 ms, Neo4j 13.3 ms
• complex-4 : gDown 1.6 ms, Neo4j 1.7 ms
• complex-5 : gDown 19.5 ms, Neo4j 16.9 ms
• complex-6 : gDown 6.7 ms, Neo4j 7 ms
• complex-7 : gDown 1.4 ms, Neo4j 1.4 ms
• complex-8 : gDown 0.8 ms, Neo4j 1 ms
• complex-9 : gDown 15.1 ms, Neo4j 8.5 ms
• complex-10 : gDown 4.4 ms, Neo4j 4.2 ms
• complex-11 : gDown 1.9 ms, Neo4j 1.8 ms
• complex-12 : gDown 2 ms, Neo4j 2.4 ms
• complex-13 : gDown 0.9 ms, Neo4j 1 ms
• complex-14 : gDown 4 ms, Neo4j 3.3 ms

Médiane sur 5 personnes après un tour de chauffe, un passage par base, dans des conteneurs limités comme dans le tableau des propriétés ; chaque base est interrogée par son transport (Bolt des deux côtés pour gDown et Neo4j : l'aller-retour est compté des deux côtés). « < 1 ms » : la médiane s'arrondit à zéro milliseconde. Lectures courtes : médiane sous la milliseconde pour gDown (0,5 à 0,7 ms) contre 0,7 à 1 ms pour Neo4j, même protocole des deux côtés.

À 3 000 personnes (90 000 nœuds et 470 000 relations, chargés par Raft en 16 s), les médianes restent sous 60 ms. Deux optimisations trouvées par ce test : complex-1 est passée de 0,6 s à 34 ms, complex-14 de 2 s à 8 ms.

Résultats non officiels : ces chiffres sont dérivés de la charge LDBC SNB Interactive et n’ont pas été audités par le LDBC (Linked Data Benchmark Council). Les données sont engendrées par le test, pas par le Datagen du LDBC : les temps ne sont pas comparables aux résultats LDBC publiés. Une seule exécution par configuration. Le test a aussi trouvé deux défauts, corrigés.

Source : gluonify-gdown, README et rapports de LdbcSnbTest et LdbcClusterTest.

La couverture de Cypher (le TCK openCypher sur chaque base) est sur la page de comparaison.

Latence et débit, charge par charge

Même graphe, mêmes requêtes et même machine pour chaque base du tableau ci-dessus : les chiffres ci-dessous sont la médiane des tours du tableau des propriétés, mesurés sur arm64.

La latence est la médiane (p50) en millisecondes, plus bas = mieux ; les charges à plusieurs clients sont en requêtes par seconde, plus haut = mieux. La meilleure valeur de chaque ligne est en gras. Rien n'est réglé au-delà des défauts de chaque image ; gDown tourne sur la JVM avec un tas de 6 Go et un cache de pages de 2 Go, Neo4j avec un tas de 4 Go et un cache de pages de 2 Go. Chaque exécution part d'un conteneur neuf, charge le graphe par lots UNWIND, vérifie que les bases s'accordent sur les résultats, puis mesure.

Sans index

ArcadeDB (indexé) est toujours mesuré avec index : ses identifiants internes interdisent la recherche par id() des autres colonnes. Sa colonne est ici pour que rien ne manque, mais ses rapports sans index comparent un index à un parcours : voir le tableau avec index pour la comparaison à armes égales.

Avec index sur les identifiants

Chargement du graphe

Sans index

Avec index sur les identifiants

Ce qu'il faut en retenir

• FalkorDB est le plus rapide sur les opérations courtes (lectures par identifiant, sauts, écriture d'un nœud) et en débit à plusieurs clients, avec le chemin client le plus court (RESP). Regardez « écritures pendant un long parcours » : ses écritures attendent derrière une lecture longue ; il n'écrit rien de durable par défaut et son chargement avec index est le plus lent.
• gDown est plus rapide que Neo4j sur la plupart des charges (moyenne géométrique sous 1 dans les deux configurations), charge plus vite et garde ses données dans bien moins d'espace disque. Il est égal ou plus lent sur les premières lignes d'un grand résultat et sur l'écriture d'un nœud : voyez ces lignes.
• Face à Memgraph, gDown gagne sur les regroupements, les comptages d'étiquette et le débit à 8 clients, et perd sur les lectures courtes, les sauts et les écritures. Memgraph ne force pas ses validations sur disque à chaque fois, contrairement à gDown et Neo4j.
• ArcadeDB, toujours mesuré avec index, est compétitif en lecture mais lent sur les intervalles et sur les écritures à plusieurs clients.
• Mémoire : les bases qui gardent tout en mémoire vive (Memgraph, FalkorDB) en utilisent le moins. gDown et Neo4j tournent ici avec des tas généreux, et gDown se contente de bien moins avec un tas plus petit pour les mêmes latences (voir la mesure native plus haut).

Ce que cette comparaison ne dit pas

• La durabilité diffère : gDown et Neo4j synchronisent le disque à chaque validation ; Memgraph seulement tous les 100 000 transactions ; FalkorDB n'écrit rien de durable par défaut ; les réglages des autres bases n'ont pas été vérifiés. Les lignes d'écriture ne comparent donc pas la même garantie.
• Les bases qui parlent Bolt partagent le même pilote Java ; FalkorDB est mesuré avec un client RESP minimal écrit pour le banc, qui raccourcit son chemin en lecture (voir la colonne transport).
• ArcadeDB est toujours mesuré avec index, dans les deux tableaux (ses identifiants internes interdisent la recherche par id()) ; une base sans valeur dans une configuration n'y a pas été mesurée.
• Le graphe tient en mémoire pour toutes les bases. Un graphe plus grand que la RAM, la réplication, la reprise après panne, la recherche vectorielle, les algorithmes de graphe et les lectures pendant des écritures concurrentes ne sont pas mesurés. Un seul nœud de chaque base.
• ArcadeDB tourne avec un tas non borné : son chiffre de mémoire n'est pas comparable. Son image est un instantané de développement.
• Une machine qui n'était pas au repos, quelques tours : comptez ±10 % sur chaque cellule.

Source : gluonify-gdown, les résultats bruts de chaque tour (docs/bench) et scripts/bench-compare.py, assemblés par un script de ce site ; le script du banc est dans le même dépôt.