Graph Databases: How Do They Work?
Heard lots of things about graph databases and do not know where to use them? Here is an ultimate description for you: use cases, explanations, and examples.
Join the DZone community and get the full member experience.
Join For FreeTo understand how graph databases work, let’s define it first. A graph database is a type of NoSQL databases which stores nodes and relationships instead of tables or documents. The data is stored without restricting it to a pre-defined model giving flexibility. 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 four types of databases: document, key-value, wide-column, and graph.
- SQL database examples: MySQL, PostgreSQL, OrientDB, MariaDB, CouchDB, and more.
- NoSQL database examples: MongoDB, Apache Cassandra, Neo4j, Redis, DynamoDB, HyperTable, and more.
In fact, there are so many databases now that it’s difficult to choose. However, there are lists of best or top databases that have descriptions of functionality and use cases.
Why Use a Graph Database?
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, a 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.
Most Popular Use Cases for Graph Databases
- Social networks
- Supply chain mapping
- AI knowledge graphs/machine learning
- Network/operations mapping
- Any type of analytics
- Recommendations engines in retail
- Telecommunications apps
- Data privacy, risk, and compliance
- Network and IT management
- Fraud detection
Components of Graph Databases
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.
Neo4j Main Features
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, meaning 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 as 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
Three lines do the impressive work of finding the needed data.
Popular Graph Databases
Now let’s look at graph database examples and their strong sides.
- Neo4j is probably the most well-known graph database. It looks simple and user-friendly and, at the same time, powerful. Query language commands are relatively easy to learn. The most important thing about Neo4j is that it clearly represents connected data. Just from the look at it, you’ll understand relationships between many nodes. Neo4j only provides services related to graph database type. It can be said that Neo4j wins in terms of popularity and well-established functionality.
- ArangoDB is a multitool designed specifically to maintain various types of NoSQL databases. If the project or business demands several databases at the same time, ArrangoDB will be of great help. What’s even more unique about this service is that it allows combining SQL and NoSQL in one project.
- Apollo was a database but has overgrown it and now is an ecosystem of tools, libraries extensions, etc. It’s highly compatible with Javascript frameworks and supports third-party extensions. So, the main difference from others is increased levels of integrations. Some important things are the automation of various processes, GraphQL and its usage possibilities, and continuous development process (yes, it’s still actively developing). It’s newer than the first two, so it has a way to go.
Conclusion
Now that you know this 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.
Published at DZone with permission of Tetiana Stoyko. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments