Are graph databases better?
Databases play a central role in software development. Relational databases still dominate. However, we are increasingly finding other types of databases. These include graph databases. As the name suggests, the focus here is on relationships.
Relational databases
The classic relational databases were conceived and then developed back in the 1970s. The table is the leading data structure. As relational databases are very easy to implement, they have dominated IT for decades. High-performance queries are only possible with suitable indices.
Even though relational databases have proven their worth, they have several weaknesses. Firstly, they are relatively rigid: once the schema is in place, it cannot be changed easily. Or rather, changes require disciplined change management in order to avoid unexpected effects.
As already mentioned, queries are only performant with appropriate indexes. This problem used to be even worse, but modern databases are quite good at supporting the database administrator. Nevertheless, the indexes can quickly become large and the queries confusing.
The realization that data is valuable is leading to ever larger databases - Big Data! The stored data is also becoming increasingly complex. These drivers demand new approaches.
Graph databases
In contrast, graph databases focus on the relationship. This reflects the realization that the value of the data lies largely in the relationships between the data, not just in the data itself.
Graph databases belong to the Class of NoSQL databases. This refers to all non-relational databases. In this respect, this term is not particularly meaningful in my opinion.
Recommended reading: Graph Databases (Robinson, Webber & Eifrem) is available for free from neo4j
Real or simulated
Furthermore, it is easy to convert a relational database into a graph database by means of an abstraction. This may make work easier for developers. However, possible performance advantages fall by the wayside, as the underlying engine has not been optimized for graphs. Nevertheless, this approach can be useful, for example to build on an existing legacy database with graph concepts.
A "real" graph database, on the other hand, is optimized for handling complex graphs and usually scales much better. One of the reasons for this is that queries "follow" the graph. This means that there are many types of queries that do not require the entire graph to be considered. There is no need to index data, at least to the extent that would be necessary with relational databases.
Various graphs
The most important models implemented in graph databases are
- Propertygraph - This consists of nodes and directed edges. Both nodes and edges can have properties.
- Hypergraph - Here, a relation connects any number of nodes. Hypergraphs are useful where there are many n:m relationships. A property graph requires a larger number of edges.
- Triples - A triple consists of three elements in the form node-edge-node. This intuitive and flexible data structure is the basis for many semantic web applications. It is RDF a core technology that has now become established.
Conclusion
Are graph databases better? As is so often the case, the answer to this question is: "It depends". Graph databases are better if the data to be processed consists of complex graphs. In certain situations, graph databases also scale better than classic relational databases.
