What are the differences, advantages, dis-advantages between Riak and CouchDB? I haven't found a comprehensive comparison till date.
Edit: Yes, I have been a bit lazy not to go and try Riak first hand. I think I will do it sooner then later but as of now, any light on the subject will be appreciated.
They serve different purposes. Riak is a DHT (for key sharding) layer intended to run on top of different backends, just like Dynamo. CouchDB has an integrated storage engine. Riak doesn't support range queries (nature of DHT). I'm pretty sure CouchDB does, which is easy for a single node. CouchDB doesn't scale in the sense that it doesn't do any automatic sharding yet. It's quite possible to use CouchDB as a backend of Riak, though it implies crippling some interesting features in CouchDB.
Technically, I found CouchDB more interesting as it's more "different" from other approaches.
DHT can certainly support range queries by broadcast and merge. The keyword in the context though is efficiently. Scalaris not a typical Dynamo like DHT. It's based on Chord, so it's possible support range scan with O(logn) metadata RPCs (n is number of nodes.) per query, which I wouldn't call efficient as these RPCs are expensive in that they not very cachable (nature of the DHT, unless the range query is exactly the same.) Typical Bigtable implementation can easily cache portion of metadata with clients and resulting 0 metadata RPC in many cases.
i was at the nyc nosql conference where mongodb, couchdb and riak were all discussed by core contributors. google nyc nosql for more details and possibly slide links. i know slides, video are floating around somewhere.
anyway, mongodb and couchdb are more closely related to each other than they are to riak. a closer comparison to riak would be cassandra (also based off dynamo).
riak is based off the amazon dynamo paper and it is a pretty faithful adaptation at that. circular hashing, node chit chat protocol, eventual consistency. CAP theorem. uses n,w,r paradigm where n=number of replicas, w=number of replicas that must be available in cluster to write and r=number of replicas that must be available in cluster to read. so in this mechanism the balance of CAP is up to you, the programmer. disconnected writes written to two separate nodes due to a network flap are both returned to the client for conflict resolution. interestingly riak is written in erlang and uses rest heavily. because they do they were able to demo access libraries in virtually every language.
regarding mongo v couch:
mongo (written in c++) has sharding/replication and rebalancing (via addition to cluster) in production now. rebalancing via removal is on the drawing board. mongo also supports dynamic querying. mongo also supports bson (binary json). i also believe there is a 4MB max row limitation. multiple daemons for different functions. limited creature comforts like web gui, efforts underway to rectify.
couch is more complete in its restful implementation and general overall approach. i feel it is an easier setup and administration. one daemon pretty much handles everything i believe. couch is a never-delete database in that it always appends writes and internally versions them. this allows for very interesting replication topologies like master-master-master due to their unique versioning scheme. this will also lead to and "offline" couch version that you can run on your desktop. couch also has "fouton" which is their admin web gui.
the teams behind each of them are committed and talented.
I ran the conference and have been shamefully behind in cutting all the video. So far I've only gotten the video linked in the article done. Working on more today. They should all be available on that vimeo page when all is said and done.
That said, Bryan gave a fantastic presentation and really knows his stuff.
Edit: Yes, I have been a bit lazy not to go and try Riak first hand. I think I will do it sooner then later but as of now, any light on the subject will be appreciated.