neo4j - downloads - apoc date

El complemento APOC de Neo4J(3.1.3.6) funciona muy lento

Question

Recientemente actualicé mi Neo4j a 3.1.3 y, junto con eso, obtuve el complemento APOC más reciente (3.1.3.6).

Tenía un poco de código que funcionaba bien, y podía crear ~ 3 millones de relaciones en aproximadamente un minuto y medio de tiempo de pared. Pero ahora, ha estado funcionando por más de 8 horas y no muestra señales de parar ...

Debido a que el código solía ejecutarse sin problemas, espero que algo haya cambiado entre versiones que ha llevado a que mi código haya sido modificado.

¿Es rock_n_roll que debería cambiarse (tal vez a apoc.periodic.commit con argumentos posicionales o algo así)? Gracias por cualquier idea.

Esto es lo que estoy ejecutando.

CALL apoc.periodic.rock_n_roll(
  "MATCH (c:ChessPlayer),(r:Record) WHERE c.ChessPlayer_ID = r.ChessPlayer RETURN c,r",
  "CYPHER planner=rule WITH {c} AS c, {r} AS r CREATE (c)-[:HAD_RECORD]->(r)",
  200000)

Answer 1

Según tengo entendido, llamar cuestiona el producto cartesiano de ChessPlayers y Records, y luego tratar de filtrarlos fila por fila, y luego hacer la actualización por lotes de esos resultados finales (que consume mucha memoria, creo que esta transacción de apertura) es lo que te está matando). Por lo tanto, si puede dividirlo para que cada transacción pueda tocar la menor cantidad posible de nodos, debería poder funcionar enormemente mejor (especialmente si r.ChessPlayer está indexado, ya que ahora no necesita cargarlos todos)

CALL apoc.periodic.rock_n_roll(
  "MATCH (c:ChessPlayer) WHERE NOT EXISTS((c)-[:HAD_RECORD]->()) RETURN c",
  "MATCH (r:Record) WHERE c.ChessPlayer_ID = r.ChessPlayer WITH c,r CREATE UNIQUE (c)-[:HAD_RECORD]->(r)",
  100000)

periodic.commit () funcionaría en un principio similar. Cuanto más pequeño (menos nodos tocados) puede realizar cada transacción, más rápido se convertirá el lote.