For all I can imagine you can have view, say, 'edges', with key [type,start,end] To traverse graph for query 'friends-of-friends' you do multiple queries to view's _bulk_doc with (at first) include_docs=false (that is default) and start_key=[<type-of-edge>,<current-node-id>,'aaaaaaaaa'] and end_key=[<type-of-edge>,<current-node-id>,'ZZZZZZZZZZ'] then, having all neighbor nodes on output from this query, you iterate over their neighbours, having each node's neighbours in alike query at each turn.
That will probably work good for not too intensive and deep traversals, but you may get too many queries for deep and frequent "graph queries". For what I have read from neo4j papers, they have tight compressed edges structure with memory mapped io on it, so if IO to edges don't have a very 'long tail', i.e. many edges are accessed frequently, and you have fair big ratio of ram/pending io on edges, neo4j will give you stronger platform for deep traversal. These are rather diffuse reasonings, But you can get the real answer suitable to you if you do benchmark on your estimated avarage use-case. 2009/7/3 David Beckwith <[email protected]>: > Hi, > > I'm deciding between CouchDB and Neo4j for a project. What's really > important to me is the speed of graph traversal and scalability. > > CouchDB wins in scalability I think, but probably Neo4j wins in graph > traversal. > > http://highscalability.com/neo4j-graph-database-kicks-buttox > > How well does CouchDB with graph traversal. And is there a way to map- > reduce graph traversal? > > Thanks, > David :) >
