When accessing the Neo4j datastore via hibernate.ogm.datastore.provider=neo4j_bolt, the runtime complexity of the query for BoltNeo4jEntityQueries.getFindEntityQuery() depends on how many nodes are reachable in the overall graph by following the outgoing relations of the searched node. This bad runtime complexity seems to be caused by the query pattern that is added to the findEntityQuery by BaseNeo4jEntityQueries.appendOptionalMatchOwnerEmbeddedNodes().
Given the following Entity class
{code:java}
@Entity
public class Node {
@Id
private UUID uuid;
@OneToOne(fetch = FetchType.LAZY)
private Node previousNode;
@OneToOne(mappedBy = "previousNode")
private Node nextNode;
//getter, setter ...
{code}
the findEntityQuery in BoltNeo4jEntityQueries is as follows:
{noformat}
MATCH (owner:ENTITY:Node {uuid: {0}}) OPTIONAL MATCH (owner) -[r*]-> emb:EMBEDDED) RETURN owner, r
{noformat}
The runtime complexity of this query depends on how many nodes can be reached from the node with {{ uuid: \ {0 \ } }} by following the previousNode relationship because the pattern " {{ (owner) \ -[r*] \ -> emb:EMBEDDED) " }} potentially expands all those previous nodes.
For example, if we are using the Node entity for basically saving a linked list of nodes, e.g. node1 <- previousNode - node2 <- previousNode - node3 ..., then Neo4J is using the following query plan during executing the findEntityQuery:
!queryplan.PNG|thumbnail!
This query plan becomes more and more inefficient, the more nodes are matched by the subpattern " {{ (owner) \ -[r*] \ ->(emb) " }} . In case of a linked list of several thousand nodes, when trying to retrieve the last node of the linked list via its uuid, this may lead to query times of the findEntityQuery of several seconds.
|
|
