Implementing a graph on top of a RDBMS is trivial, and if the semantics are correct (the same as the ones exposed by a graph db?), then I'm not sure why would people want to use a proper graph db.
I thought that probably it'd be an issue of performance: the "right tool for the job" that "does one thing and does it well" probably is leaner and more efficient. After all, unlike a trivial implementation, getting a graph on a RDBMS to perform well might not be that simple after all (still, your idea of inheriting tables might make things more flexible and maybe more efficient)
But then, when looking up some Neo4j benchmarks, the numbers seems to not be good at all:
I'd like to hear from someone that used Neo4j (also, other graph databases are interesting) in production, and benchmarked it against a RDBMS prototype, finding the former as the better solution of the two.
A proper graph db is almost mandatory if there are complex, ad hoc queries that need to be made on real time data.
Using an RDBMS is great if the graph query types are going to be known in advance - so they can be prepared for using materialized views and indexes, and if they aren't too complex - so one doesn't descend into JOIN-hell.
But most applications aren't like that, and not all applications can be completely satisfied using only a graphdb. Hence the rise of the new multimodel databases like OrientDB and ArangoDB. So I think it is a question of what risk one is prepared to tolerate.
While the author admits that the documentation advises to use the traversal API (which gives the best performance) he goes with cypher over the REST interface which would never match a direct db connection. It's a fundamental flaw in his comparison.
Comments
I was also wondering about the same thing:
Implementing a graph on top of a RDBMS is trivial, and if the semantics are correct (the same as the ones exposed by a graph db?), then I'm not sure why would people want to use a proper graph db.
I thought that probably it'd be an issue of performance: the "right tool for the job" that "does one thing and does it well" probably is leaner and more efficient. After all, unlike a trivial implementation, getting a graph on a RDBMS to perform well might not be that simple after all (still, your idea of inheriting tables might make things more flexible and maybe more efficient)
But then, when looking up some Neo4j benchmarks, the numbers seems to not be good at all:
http://baach.de/Members/jhb/neo4j-performance-compared-to-my...
I'd like to hear from someone that used Neo4j (also, other graph databases are interesting) in production, and benchmarked it against a RDBMS prototype, finding the former as the better solution of the two.
AFAIK:
A proper graph db is almost mandatory if there are complex, ad hoc queries that need to be made on real time data.
Using an RDBMS is great if the graph query types are going to be known in advance - so they can be prepared for using materialized views and indexes, and if they aren't too complex - so one doesn't descend into JOIN-hell.
But most applications aren't like that, and not all applications can be completely satisfied using only a graphdb. Hence the rise of the new multimodel databases like OrientDB and ArangoDB. So I think it is a question of what risk one is prepared to tolerate.
While the author admits that the documentation advises to use the traversal API (which gives the best performance) he goes with cypher over the REST interface which would never match a direct db connection. It's a fundamental flaw in his comparison.
I noticed that, but he's doing a single REST query for every timing:
https://github.com/jhb/neo4j-experiements/blob/master/query_...
There's no way that a single HTTP request is responsible for a difference in hundreds of seconds
(his benchmark code isn't really sound, but I don't see how this can affect a difference so striking)