Comparison of Relational Databases and Graph Databases

Comparison of Relational Databases and Graph Databases

There actually is conceptual reasoning behind both styles. Wikipedia on the relational model and graph databases gives good overviews of this.

The primary difference is that in a graph database, the relationships are stored at the individual record level, while in a relational database, the structure is defined at a higher level (the table definitions).

This has important ramifications:

• A relational database is much faster when operating on huge numbers
  of records. In a graph database, each record has to be examined
  individually during a query in order to determine the structure of
  the data, while this is known ahead of time in a relational database.
• Relational databases use less storage space, because they don't have
  to store all of those relationships.

Storing all of the relationships at the individual-record level only makes sense if there is going to be a lot of variation in the relationships; otherwise you are just duplicating the same things over and over. This means that graph databases are well-suited to irregular, complex structures. But in the real world, most databases require regular, relatively simple structures. This is why relational databases predominate.

Performance of Graph vs. Relational databases

The deeper the object graph, the more the performance advantage swings to object/graph databases.

Relational database performance drops off markedly with more than seven JOINs.

Geometric systems such as CAD/CAM, with deep object graphs for bills of materials, outperform their relational counterparts.

Relational databases have one huge advantage: relational algebra and a clear separation between the data and the "how" of accessing and manipulating it. But they are not perfect for every problem.

neo4j - graph database along with a relational database?

Graph DB is mainly used for maintaining relations. If app has a graph DB that does not mean that app needs to store everything in Graph DB.

Every node request on Graph is in memory and thus if you have unnecessary properties in your node it will be bloated and may make things slower and take more memory.I usually decide what needs to go in graph and what needs to go in DB by very simple rule.

High level property (that defines the relation and other important properties that defines the node) goes in graph whereas additional information goes in RDMS.

For example in FB may be FBID, Name goes in Graph as it defines the relationship of one node with another. But when user clicks on someones facebook ID, he/she gets to see other users DOB, Age , College .All these can go in RDBMS.

PS: RDMS has another advantage, it can be used for quick analytics. I know with graph also you can do that but i am not sure if its as scalable and easy as RDBMS.

Downside to this approach is : You need to maintain two DBS.

Graph and Relational Data Models

one of the cases you would want to use neo4j instead of relational DB:

as soon as you are using mostly several joins between tables, especially when joining a table on itself, consider using graph DB.

in my eyes using a graph DB is a method to store those kind of information, which i'm querying in very few ways (or maybe i'm using just one pattern of query) and i'm looking for the speed of the answer.
having relational DB is better when you use plenty query types and still have plenty of computational power.

if you would like to know more and go deeper into graph DB, i suggest you to read smthing about math graphs in general (http://en.wikipedia.org/wiki/Graph)

GraphDatabase (Neo4J) vs Relational database (MySql) - query on specific column of a specific table

As you already mentioned: you would create indices for this purpose. The default index provider in Neo4j is lucene, which is very fast and allows fine grained indexing and querying possibilities.

Indices can be used for nodes or relationships and (normally) keep track which values have been set on certain properties on nodes or relationships.

You normally have to do the indexing in your application code unless you're using neo4j's auto indexing feature that automatically indexes all nodes and/or relationships with given properties.

So queries like "search for all events that took place in Paris" are absolutely no problem and are very performant when indices are used.

---

Related Topics