Cyper query drastically slowed down when created multiple duplicate relations

[kadoshada]

I am very new to neo4j graph DB. in my current project, it need to have multiple duplicate relations between two nodes but with the different properties(minimum two properties which contain text values) and relationship label will be the same.
first i created 21 nodes with 24 relations and run a query to get all paths between two nodes without travel one node twice.
this is the query I executed.

---

MATCH p=(a)-[*]-(b) 
WHERE id(a)=10 AND id(b)=11
AND NONE (n IN nodes(p) 
	  WHERE size([x IN nodes(p) 
		     WHERE n = x])> 1) 
RETURN p

---

this was executed properly without delaying.

but after i added multiple duplicate relations between several nodes(another 12 relations have been added ) and again executed this query. then it took around 15 mins to complete and the given results are correct. any help to rectify this issue highly appreciate.

later i've added unique constraint and index on id and name properties but there were no improvements.

below i've added profile and explain results of the query.

[david_allen]

You can probably improve this immediately by changing your query a bit:

MATCH (a) where id(a) = 10
WITH a
MATCH (b) WHERE id(b) = 11
WITH a, b
MATCH p=(a)-[*]-(b)
WHERE NONE (n IN nodes(p) 
	  WHERE size([x IN nodes(p) 
		     WHERE n = x])> 1) 
RETURN p

[kadoshada]

hi allen, thank u very much for your answer but this query also not given any improvement on the query time. anything that i need to change in DB design itself but i think 21 nodes with 36 relations won't be a that much issue when executing a query. or duplicate relations make any drawback on the performance?

[david_allen]

So the path match in your query is matching every possible path through the entire graph, undirected. This causes an explosion of paths, since every path will be traversed, forwards, backwards, and partially. A literal explosion of possibilities.

The best way to constrain it is to limit the path length to use shortestPath, and constrain it to paths < some length, and give the path a direction, and also only use some relationship types, not all.

[kadoshada]

thank u again allen for your promt replying. i got ur point in this regards but the requirement was to find all possible path between the selected two nodes. if i want to fulfill this requirement how do i improve my DB design or infrastructure or with any server resources. because still we are in the POC stage and i need to find out a way to fullfil this requirement as it is. when it comes to the real application scenario it will have atleast 1000 nodes with more than 10000 relations. still i'm working with my local pc and when i moved this to a server environment what kind of approach should i taken to overcome this issue to fulfill this requirement. highly appreciate your valueble inputs in this regards.

[david_allen]

You can still find all possible paths, without traversing all possible paths twice in both directions. At least start by making the path directed.

[kadoshada]

thank you allen for your reply and i've tried both ways as mentioned below and it given me no records.

MATCH (a) where id(a) = 10
WITH a
MATCH (b) WHERE id(b) = 11
WITH a, b
MATCH p=(a)<-[*]-(b)
WHERE NONE (n IN nodes(p) 
	  WHERE size([x IN nodes(p) 
		     WHERE n = x])> 1) 
RETURN p

MATCH (a) where id(a) = 10
WITH a
MATCH (b) WHERE id(b) = 11
WITH a, b
MATCH p=(a)-[*]->(b)
WHERE NONE (n IN nodes(p) 
	  WHERE size([x IN nodes(p) 
		     WHERE n = x])> 1) 
RETURN p

could you please give me some examples queries to try out the way you suggesting.