Databases Reference
In-Depth Information
CHAPTER 6
Graph Database Internals
In this chapter we peek under the hood and discuss the implementation of graph data‐
bases, showing how they differ from other means of storing and querying complex,
semi-structured, densely connected data. Although it is true that no single universal
architecture pattern exists, even among graph databases, this chapter describes the most
common architecture patterns and components you can expect to find inside a graph
database.
We illustrate the discussion in this chapter using the Neo4j graph database, for several
reasons. Neo4j is a graph database with native processing capabilities as well as native
graph storage (see
Chapter 1
for a discussion of native graph processing and storage).
In addition to being the most common graph database in use at the time of writing, it
has the transparency advantage of being open source, making it easy for the adven‐
turesome reader to go a level deeper and inspect the code. Finally, it is a database the
authors know well.
Native Graph Processing
We've discussed the property graph model several times throughout this topic; by now
you should be familiar with its notion of nodes connected by way of named and directed
relationships, with both the nodes and relationships serving as containers for properties.
Although the model itself is reasonably consistent across graph database implementa‐
tions, there are numerous ways to encode and represent the graph in the database en‐
gine's main memory. Of the many different engine architectures, we say that a graph
database has native processing capabilities if it exhibits a property called
index-free
adjacency
.
A database engine that utilizes index-free adjacency is one in which each node maintains
direct references to its adjacent nodes; each node, therefore acts as a micro-index of
other nearby nodes, which is much cheaper than using global indexes. It means that
