Database Reference
In-Depth Information
the defined depth). Again, this is for a data set of 1,000 users with an average of 50 friends
per user.
Table 1.2. The execution times for graph traversal using Neo4j on a data set of 1,000 users
Depth
Execution time (seconds) for 1,000 users
Count result
2
0.04
~900
3
0.06
~999
4
0.07
~999
5
0.07
~999
Note
Similar to the MySQL setup, no additional performance tuning was done on the Neo4j in-
stance. Neo4j was running in embedded mode, with the default configuration and 2,048
MB of JVM heap memory.
The first thing to notice is that the Neo4j performance is significantly better for all queries,
exceptthesimplestone.Onlywhenlookingforfriendsoffriends(atdepth2)istheMySQL
performance comparable to the performance of a Neo4j traversal. The traversal of friends
atdepth3isfourtimes faster thantheMySQLcounterpart. Whenperformingatraversal at
depth 4, the results are five orders of magnitude better. The depth 5 results are 10 million
times faster for the Neo4j traversal compared to the MySQL query!
Another conclusion that can be made from the results in
table 1.2
is that the performance
of the query degrades only slightly with the depth of the traversal when the count of nodes
returned remains the same. The MySQL query performance degrades with the depth of the
query because of the Cartesian product operations that are executed before most of the res-
ults are discarded. Neo4j keeps track of the nodes visited, so it can skip nodes it's visited
before and therefore significantly improve performance.
Tofindallfriendsatdepth5,MySQLwillperformaCartesianproductonthet_user_friend
table five times, resulting in 50,000
5
records, out of which all but 1,000 are discarded.
Neo4j will simply visit nodes in the database, and when there are no more nodes to visit,
it will stop the traversal. That is why Neo4j can maintain constant performance as long as
the number of nodes returned remains the same, whereas there's a significant degradation
in performance when using MySQL queries.
