gDown Prestazioni

Durabilità dei database misurati

Per queste misure delle prestazioni, tutti i database sono misurati in modalità persistente (dati scritti su disco, riprodotti al riavvio).

Database misurati

Come gira il banco

Avvio, memoria, CPU e dimensione

Senza indice

Con indici sugli identificatori

Avvio: da docker run alla prima risposta a RETURN 1, mediana di più tentativi, misurato una volta e ripreso in entrambe le configurazioni; le altre righe coprono l'intera esecuzione dei carichi. CPU e disco non sono classificati: una base che non scrive nulla di durevole ha 0 MB su disco.

Letture complesse: latenza mediana — LDBC SNB Interactive

Le 29 query del carico Interactive del Social Network Benchmark dell'LDBC (14 letture complesse, 7 letture brevi, 8 aggiornamenti; Apache 2.0, invariate) girano tutte su un grafo generato con lo schema SNB.

• 29 / 29 query eseguite: 14 letture complesse, 7 brevi, 8 aggiornamenti
• 3 / 3 membri di un cluster a 3 nodi restituiscono lo stesso numero di righe per le 21 letture
• 18 ms mediana di una scrittura mentre il leader ne conferma 1.365 (3.000 persone)
• 0 ms mediana di una lettura su un follower durante queste scritture (95° percentile: 30 ms)

Tutti i database, 3,000 persone

Un trattino: la base rifiuta la query, supera il suo timeout o restituisce un numero di righe diverso da Neo4j (il suo tempo non significherebbe nulla). Caso per caso:

Tutti i database, 30,000 persone

• 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

Mediana su 5 persone dopo un giro di riscaldamento, un passaggio per base, in container limitati come nella tabella delle proprietà; ogni base è interrogata con il proprio trasporto (Bolt da entrambe le parti per gDown e Neo4j: l'andata e ritorno conta da entrambe le parti). «< 1 ms»: la mediana si arrotonda a zero millisecondi. Letture brevi: mediana sotto il millisecondo per gDown (da 0,5 a 0,7 ms) contro 0,7-1 ms per Neo4j, stesso protocollo da entrambe le parti.

Con 3.000 persone (90.000 nodi e 470.000 relazioni, caricati tramite Raft in 16 s), le mediane restano sotto i 60 ms. Due ottimizzazioni trovate da questo test: complex-1 è passata da 0,6 s a 34 ms, complex-14 da 2 s a 8 ms.

Risultati non ufficiali: queste cifre derivano dal carico LDBC SNB Interactive e non sono state verificate dal LDBC (Linked Data Benchmark Council). I dati sono generati dal test, non dal Datagen dell'LDBC: i tempi non sono confrontabili con i risultati LDBC pubblicati. Una sola esecuzione per configurazione. Il test ha anche trovato due difetti, ora corretti.

Fonte: gluonify-gdown, README e rapporti di LdbcSnbTest e LdbcClusterTest.

La copertura di Cypher (il TCK di openCypher su ogni base) è nella pagina di confronto.

Latenza e throughput, carico per carico

Stesso grafo, stesse query e stessa macchina per ogni base della tabella sopra: le cifre che seguono sono la mediana dei giri della tabella delle proprietà, misurate su arm64.

La latenza è la mediana (p50) in millisecondi, più basso è meglio; i carichi con più client sono in richieste al secondo, più alto è meglio. Il valore migliore di ogni riga è in grassetto. Nulla è regolato oltre i valori predefiniti di ogni immagine; gDown gira sulla JVM con un heap di 6 GB e una cache di pagine di 2 GB, Neo4j con un heap di 4 GB e una cache di pagine di 2 GB. Ogni esecuzione parte da un container nuovo, carica il grafo a lotti UNWIND, verifica che le basi concordino sui risultati, poi misura.

Senza indice

ArcadeDB (indicizzato) è sempre misurato con indice: i suoi identificatori interni escludono la ricerca per id() usata per le altre colonne. La sua colonna è qui perché non manchi nulla, ma i suoi rapporti senza indice confrontano un indice con una scansione: vedere la tabella con indici per il confronto alla pari.

Con indici sugli identificatori

Caricamento del grafo

Senza indice

Con indici sugli identificatori

Cosa ricavarne

• FalkorDB è il più veloce sulle operazioni brevi (letture per identificatore, salti, scrittura di un nodo) e nel throughput con più client, con il percorso client più corto (RESP). Guardate «scritture durante un lungo attraversamento»: le sue scritture aspettano dietro una lettura lunga; non scrive nulla di durevole per impostazione predefinita e il suo caricamento con indici è il più lento.
• gDown è più veloce di Neo4j sulla maggior parte dei carichi (media geometrica sotto 1 in entrambe le configurazioni), carica più in fretta e tiene i dati in molto meno spazio su disco. È pari o più lento sulle prime righe di un grande risultato e sulla scrittura di un nodo: vedete quelle righe.
• Rispetto a Memgraph, gDown vince su raggruppamenti, conteggi di etichetta e throughput con 8 client, e perde su letture brevi, salti e scritture. Memgraph non forza ogni volta i commit su disco, a differenza di gDown e Neo4j.
• ArcadeDB, misurato sempre con indice, è competitivo in lettura ma lento sugli intervalli e sulle scritture con più client.
• Memoria: i database che tengono tutto in RAM (Memgraph, FalkorDB) ne usano meno. gDown e Neo4j girano qui con heap generosi, e a gDown basta molto meno con un heap più piccolo per le stesse latenze (vedere la misura nativa più in alto).

Cosa questo confronto non dice

• La durabilità differisce: gDown e Neo4j sincronizzano il disco a ogni commit; Memgraph solo ogni 100 000 transazioni; FalkorDB non scrive nulla di durevole per impostazione predefinita; le impostazioni degli altri database non sono state verificate. Le righe di scrittura non confrontano quindi la stessa garanzia.
• I database che parlano Bolt condividono lo stesso driver Java; FalkorDB è misurato con un client RESP minimo scritto per il banco, che accorcia il suo percorso in lettura (vedere la colonna del trasporto).
• ArcadeDB è sempre misurato con indice, in entrambe le tabelle (i suoi identificatori interni escludono la ricerca per id()); un database senza valore in una configurazione non vi è stato misurato.
• Il grafo sta in memoria per tutti. Un grafo più grande della RAM, la replica, il failover, la ricerca vettoriale, gli algoritmi su grafo e le letture durante scritture concorrenti non sono misurati. Un solo nodo per database.
• ArcadeDB gira con un heap non limitato: la sua cifra di memoria non è confrontabile. La sua immagine è un'istantanea di sviluppo.
• Una macchina non a riposo, pochi giri: contate su ±10 % per ogni cella.

Fonte: gluonify-gdown, i risultati grezzi di ogni giro (docs/bench) e scripts/bench-compare.py, assemblati da uno script di questo sito; lo script del banco è nello stesso repository.