Database Reference
In-Depth Information
In a graph database, a join operation will never need to be performed: all we need
todoistoindastartingnodeinthedatabase(forexample,London),usuallywith
an index lookup, and then just use the index free adjacency characteristic and hop
from one node (London) to the next (Restaurant) over its connecting relationships
(Restaurant-[LOCATED_IN]->London). Every hop along this path is, in effect, the
equivalent of a join operation. Relationships between nodes can therefore also be
thought of as an explicitly stored representation of such a join operation.
We often refer to these types of queries as pattern matching queries. We specify a
pattern (refer to the following diagram: blue connects to orange, orange connects to
green, and blue connects to green), we anchor that pattern to one or more starting
points, and start looking for matching occurrences of that pattern. As you can see,
the graph database will be an excellent tool to spin around the anchor node and
igureoutwhethertherearematchingpatternsconnectedtoit.Non-matching
patterns will be ignored, and matching patterns that are not connected to the
starting node will not even be considered.
This, actually, is one of the key performance characteristics of a graph database: as
soon as you "grab" a starting node, the database will only explore the vicinity of that
starting node and will be completely oblivious to anything that is not connected to
the starting node. The key performance characteristic that follows from this is that
query performance is very independent of the data set size, because in most graphs
everything is not connected to everything. By the same token, as we will see later,
performance will be much more dependent on the size of the result set, and this
will also be one of the key things to keep in mind when putting together your
persistence architecture.
Matching patterns connected to an anchor node
