Questo confronto Neo4j con il tempo di esecuzione di RDBMS è corretto?

Contesto: Di seguito è riportato il libro Graph D Database , che copre un test delle prestazioni menzionato nel libro Neo4j in azione :

Le relazioni in un grafico formano naturalmente percorsi. Interrogazione o spostamento, il grafico prevede i seguenti percorsi. A causa della natura fondamentalmente orientata al percorso del modello di dati, la maggior parte delle operazioni del database dei grafici basate sul percorso sono altamente allineate con il modo in cui i dati sono disposti, rendendoli estremamente efficienti. Nel loro libro Neo4j in Action, Partner e Vukotic eseguono un esperimento usando un negozio relazionale e Neo4j.

Il confronto mostra che il database dei grafici è sostanzialmente più veloce per i dati connessi rispetto a un negozio relazionale. L'esperimento di Partner e Vukotic cerca di trovare amici di amici in un social network, fino a una profondità massima di cinque. Date due persone scelte a caso, esiste un percorso che le collega e che è lungo al massimo cinque relazioni? Per un social network contenente 1.000.000 di persone, ciascuna con circa 50 amici, i risultati suggeriscono fortemente che i database dei grafi sono la scelta migliore per i dati connessi, come vediamo nella Tabella 2-1.

Tabella 2-1 Trovare amici estesi in un database relazionale rispetto a risultati efficienti in Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

In profondità due (amici degli amici) sia il database relazionale che il database grafico funzionano abbastanza bene da consentirci di usarli in un sistema online. Mentre la query Neo4j viene eseguita in due terzi del tempo di quella relazionale, un utente finale noterebbe a malapena la differenza in millisecondi tra i due. Quando raggiungiamo la profondità tre (amico-di-amico-di-amico), tuttavia, è chiaro che il database relazionale non può più gestire la query in un lasso di tempo ragionevole: i trenta secondi necessari per il completamento sarebbero completamente inaccettabili per un sistema online. Al contrario, il tempo di risposta di Neo4j rimane relativamente piatto: solo una frazione di secondo per eseguire la query, decisamente abbastanza veloce per un sistema online.

Alla quarta profondità il database relazionale mostra una latenza paralizzante, rendendolo praticamente inutile per un sistema online. Anche i tempi di Neo4j sono leggermente peggiorati, ma la latenza qui è alla periferia di essere accettabile per un sistema online reattivo. Infine, alla profondità cinque, il database relazionale richiede semplicemente troppo tempo per completare la query. Neo4j, al contrario, restituisce un risultato in circa due secondi. Alla quinta profondità, sembra che quasi tutta la rete sia nostra amica: per molti casi d'uso reali, probabilmente potremmo tagliare i risultati e i tempi.

Le domande sono:

• Si tratta di un test ragionevole per emulare ciò che si potrebbe non trovare in un social network? (Significa che i social network reali normalmente hanno nodi con circa 50 amici, ad esempio; sembra che il modello " arricchisci diventa più ricco " sarebbe più naturale per i social network, anche se potrebbe essere sbagliato.)
• Indipendentemente dalla naturalezza dell'emulazione, c'è qualche motivo per credere che i risultati siano spenti o irripetibili?

Guardando questo documento chiamato Anatomia di Facebook, noto che la mediana è 100. Guardando il diagramma delle funzioni cumulative posso scommettere che la media è più alta, vicino a 200. Quindi 50 sembra non essere il numero migliore qui. Tuttavia, penso che questo non sia il problema principale qui.

Il problema principale è la mancanza di informazioni sull'utilizzo del database.

Sembra ragionevole che un archivio di dati progettato appositamente per le strutture grafiche sia più efficiente dei tradizionali RDBM. Tuttavia, anche se gli RDBM non sono nelle ultime tendenze come archiviazione di dati preferita, questi sistemi si sono evoluti continuamente in una corsa con le dimensioni del set di dati. Esistono vari tipi di possibili progetti, vari modi di indicizzare i dati, miglioramenti relativi alla concorrenza e così via.

Per concludere, penso che per quanto riguarda la riproducibilità, lo studio non abbia una descrizione adeguata di come è stato progettato lo schema del database. Non mi aspetto che un database domini su tale re degli interrogatori, tuttavia mi aspetto che con un design ben calibrato le differenze non siano così enormi.

Ci sono modi buoni / veloci per modellare i grafici in RDBMS e modi stupidi / lenti.

• Alcuni usano l'indicizzazione intelligente e Procs memorizzati, scambiando il carico della CPU e le tabelle temporanee ottimizzate sui dischi RAM per una maggiore velocità di recupero del grafico.

• Alcuni usano percorsi grafici precompilati (questo potrebbe essere meno fattibile nello scenario dei social network, ma in un albero con la maggior parte dei nodi costituiti da nodi foglia, è un ottimo compromesso spazio-temporale

• Alcuni semplicemente calcolano in un ciclo, usando una tabella temporanea non indicizzata. Dagli # lanciati nell'articolo, che odora di quello che hanno fatto (30 secondi di prestazioni su un set di dati abbastanza piccolo)

  Ad esempio, ho il mio calcolo dell'albero.

  • È incapsulato in un proc memorizzato altamente sintonizzato

  • Mentre è in esecuzione in un dataserver Sybase ASE15 hardware di dimensioni aziendali, quel server è condiviso con un paio di terabyte di dati da tutte le altre app aziendali, alcuni più affamati dei miei; e non è dedicato esclusivamente all'esecuzione delle mie query.

  • Ho fatto non hanno accesso allo strumento aumento di velocità principale, una tabella temporanea su un disco RAM.

  • Un insieme rappresentativo di dati che stavo recuperando e che sembra corrispondere in qualche modo al loro stava ottenendo una sottostruttura di 150.000 nodi da un set di dati completo della foresta di 2,5 milioni di nodi (profondità dell'albero illimitata, che varia tra 5 e 15, ma un'arità media più piccola di un dato nodo rispetto a i 50 amici elencati nell'esperimento)

  • L'ho sintonizzato al punto che questa query ~ 30-45 secondi. Certamente NON mostra il rallentamento esponenziale che le cifre nella domanda sembrano indicare sulle loro prestazioni RDBMS, che è molto più strano dato che non c'è crescita esponenziale nel set di risultati (che per me puzza di indice non accordato su un tabella temporanea per esperienza personale).

Quindi, questo confronto è probabilmente errato e basato su un design laterale RDBMS scadente, anche se, come notato nella risposta precedente, è impossibile accertare senza che si apra il 100% del codice e delle definizioni della tabella.