Benefit of Neo4j over Relational
As mentioned in the last lesson, index-free adjacency is a huge differentiator between relational and graph databases. While relationships are stored at write-time in a graph database, the joins made in a relational database are computed at read-time. This means that, as the number of records in a relational database increases, the slower the query becomes. The query time in a graph database will remain consistent to the size of the data that is actually touched during a query.
Having relationships treated as first class citizens also provides an advantage when starting out. Modelling relationships in a graph is more natural than creating pivot tables to represent many-to-many relationships.
Northwind RDBMS to graph
Let’s look at the Northwind RDBMS data model.
In this example, an order can contain one or more products and a product can appear in one or more orders. In a relational database, the Order Details table is required to handle the many-to-many relationships. The more orders added, and subsequently the larger the Order Details table grows, the slower order queries will become.
In a graph, we can simply model a CONTAINS relationship from the Order node to each Product node. The Product node has a unit price property and the CONTAINS relationship which has properties to represent the quantity and discount.
NoSQL datastores to graph
NoSQL databases solve many of the problems, and they are great for write throughput.
But there are problems with how data is queried. The two most common NoSQL databases represent key/value stores and documents.
Key-value stores
The key-value model is great and highly performant for lookups of huge amounts of simple or even complex values. Here is how a typical key-value store is structured.
Key-value as a graph
However, when the values are themselves interconnected, you have a graph. Neo4j lets you traverse quickly among all the connected values and find insights in the relationships. The graph version shows how each key is related to a single value and how different values can be related to one another (like nodes connected to one another through relationships).
Document stores
The structured hierarchy of a Document model accommodates a lot of schema-free data that can easily be represented as a tree. Although trees are a type of graph, a tree represents only one projection or perspective of your data. This is how a document store hierarchy is structured as pieces within larger components.
Document model as graph
If you refer to other documents (or contained elements) within that tree, you have a more expressive representation of the same data that you can easily navigate using a graph. A graph data model lets more than one natural representation emerge dynamically as needed. This graph version demonstrates how moving this data to a graph structure allows you to view different levels and details of the tree in different combinations.
Check your understanding
NoSQL datastores
As shown with the Northwind example, you learned that a Relational model can be implemented as a graph. What other NoSQL models have you learned about in this lesson that can be implemented as graphs to improve performance?
-
❏ Object store
-
✓ Key-value store
-
❏ Tuple store
-
✓ Document store
Hint
These two examples of NoSQL stores benefit greatly by adding relationships in a graph as shown in this lesson.
Solution
As described in this lesson, these NoSQL models can be implemented as graphs to improve performance:
-
Key-value store
-
Document store
Summary
In this lesson you learned how some non-graph data models can be represented as graphs. Next, you will learn about the Movie graph that is used in many GraphAcademy courses.