Question

With key-value, document, and column-family databases, I understand you can scale out with combinations of replication and sharding in the keyspace. But, with common graph operations like shortest path, etc. — these don’t really seem to gain any benefit from replication…and I can’t see how you would shard a graph database without finding an independent subgraph (very difficult).

Are there graph databases that try to tackle this problem? What is the current research in this area?

Answer 1

Replication can be useful for any kind of database – it’s just creating multiple copies of data so you can serve more queries than a single server can handle.

Sharding is a little more complex, but actually not too different from key/value or document stores, because internally edges have to be represented as simple lists.

While it is true that finding independent subgraphs is impossible in most cases, it isn’t actually necessary. As long as the node processing the query is able to get data from other nodes, having the data available locally is just a performance optimisation.

Once you have that set up, you have a lot of options for optimising performance based on the type of graph you are working with – for example in a social graph you might use location to select the node for a user because you know that most connections are local.

I’m not aware of any existing graph databases that have sharding built in, probably because the problem is much harder to solve for the general case and the small size of edge data means you need a really large graph to exceed the capacity of a single server.