To understand how graph databases work, let’s give a definition first. A graph database is a type of NoSQL databases that stores nodes and relationships instead of tables, or documents. The data is stored without restricting it to a pre-defined model giving flexibility. The abovementioned NoSQL databases are often perceived as “no SQL” at all but it’s actually “not only SQL”. In SQL databases, the data is only stored in tables. Using NoSQL you can store 4 types of databases: Document, Key-value, Wide-column, and Graph.
In fact, there are so many databases now that it gets hard to choose. However, there are lists of best or top databases which have descriptions of functionality and use cases.
Graph databases are multi-relational by nature opposed to relational databases (SQL). It seems more practical too as data is shown in an intuitive way. Relationships are already stored in the database so no need to calculate. Graph databases can store large quantities, be quick, and support a diversity of current data. If you want to develop a social media app or community app, graph database would be the most reasonable choice. Not only will the database handle a large number of users, but it’ll also form relationships between them. For any app involving social networking, graph database will be suitable.
Moreover, graph database is perfect for real-time big data as you can add new nodes and relationships between nodes easily. This doesn’t affect performance though. NoSQL databases and graph databases in particular are better performings as they don’t need to load or touch unrelated data for a given query.
The most popular use cases for graph databases:
Fraud detection
There are three main components in every graph database: nodes, properties, and edges (or relationships). Nodes in simple words are entities or some objects in a domain like users, locations, and things. Properties are added to nodes to add more context. In some cases, edges have properties as well. And edges connect nodes and show a type of connection. Take a look at the image:
Edges or relationships might have values attached. Here it’s “Follows” but there might be more than one value. One more addition are labels which define (classify) what kind of nodes they are (Student and Teacher). So, multiple nodes together form a sort of mind map ecosystem.
It wouldn’t be such a popular graph database if it didn’t have unique features. The first thing is that Neo4j is a native graph database. It means that the underlying architecture of how the data is stored isn’t built on top of tables. This type of data model is actually a highly connected graph. And when doing a query, in Neo4j you don’t have to index every time you make a hop like in relational databases.
The query language Cypher is pretty straightforward. It's a declarative language where parentheses and relationships represent nodes are arrows and brackets. Below is an example of a Neo4j query. It demonstrates the query of which neighbor games share the most characteristics with the selected (i.e., searched-for) game.
The most beautiful part of it is the code:
MATCH p=(game:Game)--(characteristic:ConceptEntry)
WHERE game.uid = 'game-borderlands_2' OR game.uid = 'game-fallout_3'
RETURN p
Three lines do the impressive work of finding needed data.
Now let’s look at graph database examples and their strong sides.
Now that you know that much about graph databases, you can be delighted with powerful data sets. It might be used in industries with high volumes of data and different types of it. Of course, every project is unique and has different business logic. So, weigh both pros and cons of graph databases before choosing. You know now how graph databases work and use cases with them. In software development, there is no final answer to such questions: what database is the best? what programming language is the coolest? The context matters, so choose wisely.