Wydajność neo4j w porównaniu do mysql (jak to poprawić?)

Question

To jest kontynuacja do can't reproduce/verify the performance claims in graph databases and neo4j in action books. Zaktualizowałem konfigurację i testy, i nie chcę zbytnio zmieniać pierwotnego pytania.

Cała historia (w tym skrypty itp) jest https://baach.de/Members/jhb/neo4j-performance-compared-to-mysql

Krótka wersja: podczas próby zweryfikowania roszczeń wydajności wykonanych w książce „Graph Database” doszedłem do następujących wyników (zapytania do losowy zbiór danych zawierający N ludzie, każdy z 50 znajomych):

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 

"*": pojedynczy uruchomić tylko

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 

"*": jednym razem tylko

Korzystanie 1.9.2 na Ubuntu 64bit mam neo4j.properties konfiguracji z tych wartości:

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

i neo4j-wrapper.conf z:

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

Moje zapytanie do neo4j wygląda to (przy użyciu API odpoczynek)

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

Node_auto_index ma miejsce, oczywiście

Czy jest coś, co mogę zrobić, aby przyspieszyć działanie neo4j (aby być szybszym od mysql)?

A także jest another benchmark in Stackoverflow z tym samym problemem.

Answer 1

Przykro mi, nie można odtworzyć wyników. Jednak w przypadku MacBooka Air (1,8 GHz i7, 4 GB RAM) z stosem 2 GB, pamięci podręcznej GCR, ale bez ocieplania pamięci podręcznych i bez innych ustawień, z podobnym zestawem danych (1 milion użytkowników, 50 znajomych na osobę) , ja wielokrotnie dostać około 900 ms za pomocą ramy przemierzanie na 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 jest wolniejszy, ale nigdzie w pobliżu tak wolno, jak sugerujesz: około 3 sekund:

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

poważaniem

ian

Answer 2

Tak, sądzę, że interfejs API REST jest znacznie wolniejszy niż zwykłe powiązania, a tym samym problem z wydajnością.