CODEWITHSUNDEEP
optimizationneo4jcypher
ajinkhya
ajinkhya

Reputation: 1

Neo4j Query Optimization - 15 diff labels

So I have 15 different Labels in Neo4j which represent 15 real world business Objects. All these Objects are related to each other. Each Object (Label) has thousands of nodes . What I'm trying to do is to do optional Matches between all these Labels and get the Related data. The query is running extremely slow with all 15 selected and works fine with 3-4 object types.

So Typically this is the query with less object types which works fine.

MATCH (incident:Incidents)
 WHERE incident.incident_number IN ["INC000005590903","INC000005590903"]
 MATCH (device:Devices)
 WHERE device.deviceid_udr in ["RE221869491800Uh_pVAevJpYAhRcJ"]
 MATCH (alarm:Alarms)
 WHERE alarm.entryid_udr in ["ALM123000000110"]
 MATCH incident-[a]-alarm
 MATCH device-[b]-alarm
 MATCH incident-[c]-device
 RETURN incident.incident_number, device.deviceid,alarm.entryid_udr

When I do a query to find data related between 15 different object types it runs extremely slow. Do you have any suggestions how I could approach this problem

Upvotes: 0

Views: 63

Answers (1)

Jim Biard
Jim Biard

Reputation: 2272

When you analyze what is happening in your query, it's not to hard to see why it is slow. Each of your initial matches is unrelated to the others, so the entire domain for each label is searched. If you use relationship matching up front, you can significantly reduce the size of each the time it takes to do the query.

Try this query and see how it goes in comparison with the one in your question.

MATCH (incident:Incidents {incident_number : "INC000005590903"})
WITH incident
MATCH (incident)--(device:Devices {deviceid_udr : "RE221869491800Uh_pVAevJpYAhRcJ"})
WITH incident, device
MATCH (device)--(alarm:Alarms {entryid_udr : "ALM123000000110"})
WITH incident, device, alarm
MATCH (incident)--(alarm)
RETURN incident.incident_number, device.deviceid_udr, alarm.entryid_udr

In this query, once you find the incident, the next match is a search of the relationships on the particular incident to find a matching device. Once that is found, matching the alarm is limited in the same fashion.

In addition, if you have a different relationship type for each of the relationships (incident to device, device to alarm, alarm to incident, etc), using the specifications of the relationship types in the matches will speed things up even further, since it will again reduce the number of items that must be searched. Without relationship typing, relationships to nodes with wrong labels will be tested.

I don't know if it is intentional or not, but you also are matching for a closed ring in your example. That's not a problem if you are careful not to allow match loops to occur, but the query won't succeed if there isn't a closed ring. Just thought I'd point it out.

Upvotes: 1

Related Questions