A graph database stores data structured in the nodes and relationships of a graph. How does this compare to other persistence models? Because a graph is a generic structure, let’s compare how a few models would look in a graph.
A Graph Database transforms a RDBMS
Topple the stacks of records in a relational database while keeping all the relationships, and you’ll see a graph. Where an RDBMS is optimized for aggregated data, Neo4j is optimized for highly connected data.
Figure 2.1. RDBMS
Figure 2.2. Graph Database as RDBMS
A Graph Database elaborates a Key-Value Store
A Key-Value model is great for lookups of simple values or lists. When the values are themselves interconnected, you’ve got a graph. Neo4j lets you elaborate the simple data structures into more complex, interconnected data.
Figure 2.3. Key-Value Store
K* represents a key, V* a value.
Note that some keys point to other keys as well as plain values.
Figure 2.4. Graph Database as Key-Value Store
A Graph Database relates Column-Family
Column Family (BigTable-style) databases are an evolution of key-value, using "families" to allow grouping of rows. Stored in a graph, the families could become hierarchical, and the relationships among data becomes explicit.
A Graph Database navigates a Document Store
The container hierarchy of a document database accommodates nice, schema-free data that can easily be represented as a tree. Which is of course a graph. Refer to other documents (or document elements) within that tree and you have a more expressive representation of the same data. When in Neo4j, those relationships are easily navigable.
Figure 2.5. Document Store
D=Document, S=Subdocument, V=Value, D2/S2 = reference to subdocument in (other) document.
Figure 2.6. Graph Database as Document Store
