In this chapter, you will learn how to estimate if our queries are under performing. It may well happen, and if this is the case, what are the rules to apply to improve them? The rule of thumb is to reduce the number of db hits.
A DB hit is a unit of work for the database. So, how do we do this?
We will cover the following topics in the chapter:
Explain and profile are the two Cypher instructions that will help us get facts where we see possible performance issues.
Explain will give you the execution plan of your query without executing it, while profile will execute the query and return results.
The execution plan is not determined by a hitman but out of the text defining the query by a component of Cypher named the planner; there are two planners: cost planner and rule planner. Cost planner is used by default; it appeared in version 2.2. Its action is to smoothly turn a text into a list of operators (remember this name).
To illustrate, here is an example of a query plan, which reads from top to bottom. You can see the related query in the image; it is based on the Movies dataset that is available if you follow the slides tied to the :play movies command:
A short execution plan
The first operator is NodeByLabelScan because I mentioned the labels. If I drop them, the execution plan becomes...
In Neo4j, indexes are used to find the starting points of the queries. You can count on them. Indexes are automatically created on properties that have a constraint. Otherwise, you can create an index with a query like the following:
CREATE INDEX ON :LabelName(propertyName)
However, refrain from creating an index for every property of each label as they need to be maintained by the server when data is inserted. It is taken care of here, but there is no magic.
The command to get the list of indexes in use in your graph is as follows:
CALL db.indexes
You may force the use of an index by specifying it in your query, as follows:
MATCH (t:Tower {name: ""})
USING INDEX t:Tower(name)
RETURN ...Here is a list of rules to help you make your queries the most performant possible.
Once written and their results verified, explain all your queries on a decent dataset to look for possible bottlenecks, as explained earlier in this chapter.
In your query plans, the row counts should decrease rapidly from top to bottom. If not, did you use enough labels? Enough indexes? Are the properties you use indexed?
Virtual resources are resources too. Do not waste CPU cycles, memory, and energy by returning more data than you need. Do not get the full nodes if you only want to use a few properties of each.
Unless authorized, you should not do a cartesian product in your queries. You may already know this, but sometimes it happens. For example, here is one, the most obvious:
MATCH (n),(m) RETURN n,m
Mind that the number of results is the square of the number of nodes. Recognize cartesian products by the lack of relation expressed...
We have seen how to check whether our queries are wasting resources and how to correct them, because CPU cycles are time and electric power, and your time is precious! Notwithstanding the fact that it generates heat and the climate is already a mess.
We saw Neo4j's execution plans, how to read them, and spot what may be an issue. We saw what the parameters are and how they might remind you of JDBC's PreparedStatements. We saw how to force the use of indexes or labels (you may have to do a comparison of the performances of both, depending on your graph and queries). Remember this old saying that elders transmit to younger disciples of our profession: Make it work, then, and only then, optimize!
Now, let's switch to something totally different: Chapter 8, Importing data into Neo4j.
The import queries can be profiled too!
© 2017 Packt Publishing Limited All Rights Reserved
