Hacker News Reader

Hmmm... This looks to only store first order relations efficiently, its seems that to traverse many nodes, you would need to repeatedly query the database (e.g. I can only get my friends, not the friends of my friends etc...). This severely limits the use for most problem domains you would want to use a graph Db for. Still, possibly useful if you have to solve a problem that looks alot like twitter's.

View on HN

Once you start getting out to second order it becomes a much more complicated (and interesting) problem -- one that I've been kicking around for a while.

Data-locality is the kicker in a distributed graph database; when doing traversals that cross multiple nodes you need to have a partitioning scheme that coordinates with your traversal algorithms so that you need the minimum number of machine-to-machine hops in a multi-level traversal. Getting that right is far more difficult than traditional database sharding.

Yeah sure.... it is much harder and involves minimizing the number of relations across shard boundaries. Not easy. However, to call a system that only allows depth 1 traversals a 'graph database' is slightly pushing the definition. To me, its more a "key value database with relations between keys".

Everyone has different requirements though, if depth 1 and huge scale are what you need, flock db might be for you.

Reply on news.ycombinator.com