I did a lot of research on graph database technologies recently and read a lot of these "let's compare X to Y" articles. What I found is that most benchmarks - especially those done by people affiliated with a given product - often tend to show a distorted and sometimes plain wrong picture.
For example, concerning the performance and scalability of graph databases the main argument of proponents of this technology is the "join bomb" argument, which states that you can't efficiently store a graph in a relational database since it will require O(log(n)) time to lookup neighboring nodes from the index when crawling the graph. However, this is of course only true for B-tree indexes, whereas hash-based indexing would give you basically the same performance (O(1)) on a graph implemented in a relational database.
Additional features like documents and deep indexes are nice of course but can be (and often are) implemented using relational databases as well, so in the end there really isn't such a large advantage to be gained from using a graph database, especially when taking into account the immaturity of many solutions in that space.
>Additional features like documents and deep indexes are nice of course but can be (and often are) implemented using relational databases as well, so in the end there really isn't such a large advantage to be gained from using a graph database, especially when taking into account the immaturity of many solutions in that space.
I've worked with graph data stored in rdbms in the medical informatics space. As you say, there are ways to correctly handle complex graph data in rdbms.
I've also used neo4j as the backend for a wall street analytics app that's in production. Could it have been done in rdms? Sure, but the ad hoc queries that needed to be run against the data were much easier to express as graph traversals than SQL.
There are some obvious downsides with using a graph database, mainly that it's practically impossible to find programmers with non trivial production experience, but it's been a great fit at the two startups I used it at since I got to implement it from the ground up and didn't need a large team.
That being said, database pragmatism is the main lesson to be learned here. Use the right tool(s) for the right jobs.
(Disclaimer: Max from ArangoDB here)
I am all for database pragmatism. Fortunately, the choice "graph database" or "non-graph database" is no longer binary. We at ArangoDB are convinced that graphs in data modelling have their merits (namely when you need "graphy" queries), but you do not want to be locked in to the graph data model. Therefore we argue for multi-model databases, which can give you graphs, but do not force you to use graphs for all and everything.
With "graphy" I mean queries that involve paths in a graph whose length is not a priori known (e.g. ShortestPath).
The purpose of this benchmark series was not to provide a comprehensive test of all these databases. We only wanted to demonstrate that a multi-model database can successfully compete with specialised solutions like document stores and specialised graph databases.
I agree to your comment about graph databases, the crucial thing is that the neighbors of a vertex can be found in time proportional to their number, and that the queries involving an a priori unknown number of steps (graph traversals, path matching, shortest path, etc.) run efficiently in the database server and can be accessed conveniently from the query language.
Understood, I did not mean to be overly critical, I just think that there is a lot of misleading information out there concerning graph databases, and for many people it is hard to get good information about their real benefits and drawbacks.
ArangoDB seems to be a very interesting project btw, I might evaluate it again for my project in the future (we are currently creating a very large graph of code data, so we need something that can scale beyond 1B nodes and 100B vertices)
No worries, yes, there is a lot of bad information about graph databases, to begin with, some seem to believe that everything out there can best described by a graph, which is clearly wrong. I have myself written something about this in this article: https://medium.com/@neunhoef/graphs-in-data-modeling-is-the-...
Furthermore, I am currently working on another article for the O'Reilly radar blog presenting a nice case study in which a multi-model database was very useful, because document queries and graph queries were both used extensively.
1B vertices and 100B edges will definitely be a challenge for any graph database and I find it highly likely that ArangoDB in its current version will not show a very good performance for a data set of this size. Obviously, it will always depend on the particular queries you need, and on whether the graph has a natural cluster structure that can be used for sharding.
For example, concerning the performance and scalability of graph databases the main argument of proponents of this technology is the "join bomb" argument, which states that you can't efficiently store a graph in a relational database since it will require O(log(n)) time to lookup neighboring nodes from the index when crawling the graph. However, this is of course only true for B-tree indexes, whereas hash-based indexing would give you basically the same performance (O(1)) on a graph implemented in a relational database.
Additional features like documents and deep indexes are nice of course but can be (and often are) implemented using relational databases as well, so in the end there really isn't such a large advantage to be gained from using a graph database, especially when taking into account the immaturity of many solutions in that space.