Database Reference
In-Depth Information
Cypher optimizations
Cypher query execution engine plans and selects the best possible path to execute a given
query in the shortest possible time, but human (or rather developer) intervention is neces-
sary for optimizing those aspects of the query that are dependent upon the understanding of
the data and the domain.
Although there is no single universal method of achieving optimum performance, we do
have some guidelines, which if followed and used appropriately, could give you the best
results.
Let's discuss these guidelines and see how they can help us in achieving optimal perform-
ance for our Cypher queries:
•
Divide and conquer
: The fundamental law of performance / optimization is, "You
need to measure first and then optimize," and it is true for Cypher too. We need to
plan and strategize our efforts. So as a first step, divide your complete Cypher
query into multiple pieces and see how each of the pieces perform with respect to
the number of records and time. Next, start from the worst performing piece and
try tuning it. In the majority of cases, half of the problem is solved just by knowing
what to optimize; otherwise, it takes a good amount of time and effort just to un-
cover the areas that require tuning/optimization.
Note
Append your Cypher queries with
profile
keywords to get the execution plan
and statistics.
•
Plan for the worst
: Always tune your queries on the worst or minimum hardware
and see the blazing fast speed on production boxes.
•
Execution engine and plans
: Cypher internally creates an execution plan for each
and every Cypher query. Once the plan is created, it is cached and re-used in the
future for the same set of Cypher queries. Enabling Cypher to re-use the cache
plans saves a good amount of time and resources. There are two different ways that
enable the Cypher to cache/re-use execution plans:
◦
Using parameters
: Replacing literals with parameters in your Cypher will
enable the execution engine to re-use the cached query plans, though para-
meters of the query might be different. It is similar to the
Pre-
paredStatement
in the
java.sql
package.
