2013-07-23 10 views
37

Questo è un seguito fino a can't reproduce/verify the performance claims in graph databases and neo4j in action books. Ho aggiornato la configurazione e i test e non voglio modificare troppo la domanda originale.prestazioni di neo4j rispetto a mysql (come può essere migliorato?)

L'intera storia (inclusi gli script, ecc) è in https://baach.de/Members/jhb/neo4j-performance-compared-to-mysql

Versione corta: durante il tentativo di verificare le prestazioni dichiarate fatte nel libro 'Graph Database' Sono venuto per i seguenti risultati (interrogazione di un set di dati casuali contenente n persone, con 50 amici ciascuno):

My results for 100k people 

depth neo4j    mysql  python 

1  0.010    0.000  0.000 
2  0.018    0.001  0.000 
3  0.538    0.072  0.009 
4  22.544    3.600  0.330 
5  1269.942   180.143  0.758 

"*": corsa singola solo

My results for 1 million people 

depth neo4j    mysql  python 

1  0.010    0.000  0.000 
2  0.018    0.002  0.000 
3  0.689    0.082  0.012 
4  30.057    5.598  1.079 
5  1441.397*   300.000  9.791 

"*": single solo eseguire

Utilizzando 1.9.2 su un ubuntu 64bit Ho neo4j.properties di impostazione con questi valori:

neostore.nodestore.db.mapped_memory=250M 
neostore.relationshipstore.db.mapped_memory=2048M 

e Neo4j-wrapper.conf con:

wrapper.java.initmemory=1024 
wrapper.java.maxmemory=8192 

La mia domanda a Neo4j assomiglia questo (utilizzando l'API REST):

start person=node:node_auto_index(noscenda_name="person123") match (person)-[:friend]->()-[:friend]->(friend) return count(distinct friend); 

Node_auto_index è a posto, ovviamente

0.123.516,410617 millions

C'è qualcosa che posso fare per velocizzare neo4j up (per essere più veloce di mysql)?

E inoltre c'è lo another benchmark in Stackoverflow con lo stesso problema.

risposta

4

Mi dispiace che non è possibile riprodurre i risultati. Tuttavia, su un MacBook Air (1,8 GHz i7, 4 GB RAM) con un heap da 2 GB, cache GCR, ma nessun riscaldamento di cache e nessun altro tuning, con un set di dati di dimensioni simili (1 milione di utenti, 50 amici per persona) , ho più volte ricevo circa 900 ms utilizzando il quadro Traversal on 1.9.2:

public class FriendOfAFriendDepth4 
{ 
    private static final TraversalDescription traversalDescription = 
     Traversal.description() 
      .depthFirst() 
      .uniqueness(Uniqueness.NODE_GLOBAL) 
      .relationships(withName("FRIEND"), Direction.OUTGOING) 
      .evaluator(new Evaluator() 
      { 
       @Override 
       public Evaluation evaluate(Path path) 
       { 
        if (path.length() >= 4) 
        { 
         return Evaluation.INCLUDE_AND_PRUNE; 
        } 
        return Evaluation.EXCLUDE_AND_CONTINUE; 

       } 
      }); 

    private final Index<Node> userIndex; 

    public FriendOfAFriendDepth4(GraphDatabaseService db) 
    { 
     this.userIndex = db.index().forNodes("user"); 
    } 

    public Iterator<Path> getFriends(String name) 
    { 
     return traversalDescription.traverse( 
      userIndex.get("name", name).getSingle()) 
       .iterator(); 
    } 

    public int countFriends(String name) 
    { 
     return count(traversalDescription.traverse( 
      userIndex.get("name", name).getSingle()) 
       .nodes().iterator()); 
    } 
} 

Cypher è più lento, ma in nessun posto vicino lento come lei suggerisce: circa 3 secondi:

START person=node:user(name={name}) 
MATCH (person)-[:FRIEND]->()-[:FRIEND]->()-[:FRIEND]->()-[:FRIEND]->(friend) 
RETURN count(friend) 

Cordiali saluti

ian

+2

Siamo spiacenti, lo scenario in neo4j in azione è 'restituire tutti gli amici di amici ...', non trovando un percorso tra amici dati. Mi riferisco al capitolo 1 di Neo4j in azione. Le istruzioni sql riguardano la ricerca di tutti gli amici e lo stesso vale per i risultati nelle tabelle (record restituiti). E ancora più importante: non riesco assolutamente a riprodurre i 3 secondi. La query, ad es. 'start person = node (100) match (person) - [: friend] ->() - [: friend] ->() - [: friend] ->() - [: friend] -> (amico) ritorno conteggio (amico); 'richiede 28,9 secondi. Molto strano ... –

+3

E sì: sul dataset di 1m trovare un percorso tra un dato A e B richiede circa 2390 ms su mysql, e solo circa 25ms su neo4j. –

+0

alias neo4j mostra la sua potenza quando si tratta di interrogare le relazioni (percorso) anziché i nodi, giusto? –

3

Sì, credo che l'API REST sia molto più lenta delle associazioni regolari e in ciò risiede il problema delle prestazioni.

+0

Buon punto.Sì, immagino che otterresti risultati diversi eseguendo embedded o standalone (con una procedura/plugin). – yngwietiger

Problemi correlati