Goals This guide quickly explains how graph databases are related to other NoSQL databases. Prerequisites You need no prior knowledge of other NoSQL stores, although it might be helpful to have read the guide on graph databases. Beginner Overview Neo4j… Learn More →
This guide quickly explains how graph databases are related to other NoSQL databases.
You need no prior knowledge of other NoSQL stores, although it might be helpful to have read the guide on graph databases.
Although somewhat vaguely named, the NoSQL (“Not only SQL”) space brings together many interesting solutions offering different data models and database systems, each suitable for different use cases and shapes of data. With the advent of the NoSQL movement, the “one-size-fits-all” proposition of large relational systems was replaced by making conscious decisions about finding the right tool for the job.
With this larger toolbox, developers have to gain the insight necessary to make informed decisions about which approaches are best suited to their particular applications.
Most NoSQL systems are aggregate oriented, providing only atomic operations within their natural aggregate, which forms only one dedicated view of your data. Other projections have to be computed crunching your data. Focusing on one aggregate at a time allows for easy sharding of bucketed data across a network of machines along the aggregate dimension, for instance the Document in Document Databases.
Graph databases handle fine-grained networks of information providing any perspective on your data that fits your use-cases. Known and trusted from relational systems, transactional guarantees protect updates of that web of data conforming to ACID standards.
Most NoSQL databases store sets of disconnected aggregates. This makes it difficult to use them for connected data and graphs.
One well-known strategy for adding relationships to such stores is to embed an aggregate’s identifier inside the field belonging to another aggregate — effectively introducing foreign keys.
But this requires joining aggregates at the application level, which quickly becomes prohibitively expensive.
— Jim Webber, Ian Robinson
Let’s compare graph databases to other NoSQL systems.
Neo4j as a NoSQL Database
With the advent of the NoSQL movement, businesses of all sizes have a variety of modern options from which to build solutions relevant to their use cases.
- Calculating average income? Ask a relational database.
- Building a shopping cart? Use a key-value Store.
- Storing structured product information? Store as a document.
- Describing how a user got from point A to point B? Follow a graph.
Uncover the Graph in a Relational Database
Connect the rows of tables in a Relational Database by uncovering all the relationships, and you’ll see a graph. Dumb JOIN tables are replaced by interesting relationships.
Where a RDBMS is optimized for aggregated, highly structured data, Neo4j is optimized for highly connected heterogeneous data.
For several decades, developers have tried to accommodate connected, semi-structured datasets inside relational databases. But whereas relational databases were initially designed to codify paper forms and tabular structures—something they do exceedingly well—they struggle when attempting to model the ad hoc, exceptional relationships that crop up in the real world.
Ironically, relational databases deal poorly with relationships. Relationships do exist in the vernacular of relational databases, but only as a means of joining tables.
— Jim Webber, Ian Robinson
Relate Key-Value Stores with Graph Databases
The Key-Value model is great and highly performant for lookups of huge amounts of simple or even complex values.
When the values are themselves interconnected, you’ve got a graph. Neo4j lets you traverse quickly among all the connected values and find insights in the relationships.