Neo4j GC Overhead Limit

Ich baue eine neo4j Grafik. Die Größe beträgt ca. 5 GB. Wenn ich eine Beziehung zu jedem Knoten hinzufügen möchte, indem ich eine Chiffrierabfrage wie match (a)-[:know]-(b),(b)-[:know]-(c) merge (a)-[:maybe_know]-(c) verwende, erhalte ich einen GC overhead limit Fehler. Ich möchte den Speicher für neo4j nicht erhöhen. Gibt es eine Möglichkeit, Knoten Schritt für Schritt zu aktualisieren? Wie zuerst, 5000 Knoten, dann weitere 5000 Knoten ... Oder haben Sie andere Vorschläge dazu?Neo4j GC Overhead Limit

Quelle

2016-07-27 Bing

'LIMIT 5000' vielleicht? Wenn die Abfrage stabil ist (erzeugt jedes Mal die gleiche Reihenfolge), könnten Sie mit "SKIP 5000 LIMIT 5000" und dann mit "SKIP 10000 LIMIT 5000" usw. fortfahren. –

Wie @tobit sagt, schränken Sie Ihre Stapel auf etwas Überschaubares ein, aber auch nur Übereinstimmungen mit Dingen, die noch nicht abgeglichen wurden. wenn a und c bereits know miteinander oder die maybe_know-Beziehung bereits erstellt wurde, dann passen Sie sie nie wieder an. Yould könnte auch sicherstellen, dass die ID von einem größer als die andere ist, was sicherstellen würde, dass du nicht zweimal die gleiche Übereinstimmung machst (einmal in jede Richtung).

match (a)-[:know]-(b),(b)-[:know]-(c) 
where a <> c 
    and not (a)-[:know|maybe_know]-(c) 
    and id(a) > id(c) 
merge (a)-[:maybe_know]-(c) 
limit 1000

Quelle

2016-07-27 17:46:33

Eine Frage, spielt die Position des LIMIT eine Rolle? Würde es eine Leistungsverbesserung geben, wenn wir nach dem WHERE mit einem LIMIT einen WITH verwenden würden, dann den Merge, oder kümmert es sich um die Optimierung unter der Haube? – InverseFalcon

Ich würde erwarten, dass sie ungefähr gleich sind. Eine Möglichkeit, dies herauszufinden, wäre jedoch, jede Version auf genau demselben Datensatz zu profilieren. –

Antwort

Verwandte Themen