Database Reference
In-Depth Information
Why not use a graph database, and what to
use instead
As we discussed earlier in this chapter, the whole concept of the category of Not
Only SQL databases is all about task-orientation. Use the right tool for the job. So
that also must mean that there are certain use cases that graph databases are not as
perfectly suited for. Being a fan of graph databases at heart, this obviously is not easy
for me to admit, but it would be foolish and dishonest to claim that graph databases
arethebestchoiceforeveryusecase.Itwouldnotbecredible.So,let'sbrielytouch
on a couple of categories of operations that you would probably want to separate
from the graph database category that Neo4j belongs to.
The following operations are where I would personally not recommend using
a graph database like Neo4j, or at least not in isolation.
Large, set-oriented queries
If you think back to what we discussed earlier, and think about how graph databases
achieve the performance that they do in complex queries, it will also immediately
follow that there are a number of cases where graph databases will still work, but
willjustnotbeaseficient.Ifyouaretryingtoputtogetherlargelistsofthings,
effectively sets, that do not require a lot of joining or require a lot of aggregation
(summing, counting, averaging, and so on) on these sets, then the performance of
the graph database compared to other database management systems will be not as
favorable. It is clear that a graph database will be able to perform these operations, but
the performance advantage will be smaller, or perhaps even negative. Set-oriented
databases such as relational database management systems will most likely give just
as or even more performance.
Graph global operations
As we discussed earlier, graph theory has done a lot of fascinating work on the
analysis and understanding of graphs in their entirety. Finding clusters of nodes,
discoveringunknownpatternsofrelationshipsbetweennodes,anddeining
centralityand/orin-betweennessofspeciicgraphcomponentsareextremely
interesting and wonderful concepts, but they are very different concepts from the
ones that graph databases excel at. These concepts are looking at the graph in its
entirety, and we refer to them as graph global operations. While graph databases are
extremely powerful at answering "graph local" questions, there is an entire category
of graph tools (often referred to as graph processing engines or graph compute
engines) that look at the graph global problems.
