When developing web applications when would you use a Graph database versus a Document database?

Question

I am developing a web-based application using Rails. I am debating between using a Graph Database, such as InfoGrid, or a Document Database, such as MongoDB.

My application will need to store both small sets of data, such as a URL, and very large sets of data, such as Virtual Machines. This data will be tied to a single user.

I am interested in learning about peoples experiences with either Graph or Document databases and why they would use either of the options.

Thank you

Detroit

Answer 1

I don't feel enough experienced with both worlds to properly and fully answer your question, however I'm using a document database for some time and here are some personal hints.

The document databases are based on a concept of key,value, and static views and are pretty cool for finding a set of documents that have a particular value.

They don't conceptualize the relations between documents.

So if your software have to provide advanced "queries" where selection criteria act on several 'types of document' or if you simply need to perform a selection using several elements, the [key,value] concept is not appropriate.

There are also a number of other cases where document databases are inappropriate : presenting large datasets in "paged" tables, sortable on several columns is one of the cases where the performances are low and disk space usage is huge.

So in many cases you'll have to perform "server side" processing in order to pick up the pieces, and with rails, or any other ruby based framework, you might run into performance issues.

The graph database are based on the concept of tripplestore, meaning that they also conceptualize the relations between the entities.

The graph can be traversed using the relations (and entity roles), and might be more convenient when performing searches across relation-structured data.

As I have no experience with graph database, I'm not aware if the graph database can be easily queried/traversed with several criterias, however if an advised reader has such an information I'd really appreciate any examples of such queries/traversals.

I'm currently reading about InfoGrid and trying to figure if such databases could by handy in order to perform complex requests on a very large set of data, relations included ....

From what I can read, the InfoGrah should be considered as a "data federator" able to search/mine the data from several sources (Stores) wich can also be a NoSQL database such as Mongo.

Wich means that you could use a mongo store for updates and InfoGraph for data searching, and maybe spare a lot of cpu and disk when it comes to complex searches inside a nosql database.

Of course it might seem a little "overkill" if your app simply stores a large set of huge binary files in a database and all you need is to perform simple key queries and to retrieve the result. In that cas a nosql database such as mongo or couch would probably be handy.

Hope some of this helps ;)

Zimmerman

Graph databases: how many mutual friends do we have? how many friends of mutual friends whose name is not "Joe" do we have? Who are the first 10 friends, of friends, of friends, who live in Austin, ordered by age? These types of queries are not easily done with document databases, and is very slow and cumbersome using relational databases. – Ponder

Answer 2

When connecting related documents by edges, will you get a shallow or a deep graph? I think the answer to that question is important when deciding between graphdbs and documentdbs. See Square Pegs and Round Holes in the NOSQL World by Jim Webber for thoughts along these lines.

Cutinize