Thanks for sharing. We have been using Riak for the last year and have had lots of fun learning a few lessons the hard way. Now we have learnt it though, everyt

Thanks for sharing. We have been using Riak for the last year and have had lots of fun learning a few lessons the hard way. Now we have learnt it though, everything seems to be fine - apart from when nodes stop responding when they start merging Bitcask data. I think one of the biggest issues we had was that we saw it as a kind of drop in replacement for MySQL. We originally used the Ripple library (protip: don't) which talked to Riak over the HTTP interface (it now supports Protobuffs, but still don't) and plonked loads of data in, then wrote some lovely MapReduces to get it out. It worked fine, except it was slow. Dog slow. The issue is that to do a MapReduce you need to get a list of keys to process. However in Riak listing the keys of a bucket is slow as it has to walk the whole keyspace (even other buckets) to find the matching keys. I'm guessing this is why Riak Search is slow for you as well. We didn't try it, but if you kept track of the keys and fed these to a MapReduce I suspect it would be a lot faster. Now we are using it as in your epiphany as a persistent distributed version of memcached. We use predictable keys for everything, so just need to do gets and puts. We also found that trying to deal with siblings is a pain, so we turned them off (allow_mult=false, last_write_wins=true). For any important documents that need to be updated, where we can't afford to lose data due to race conditions, we just write a new version with a different predictable key (kind of like a linked list). It works lovely now :) As stated in the article, enterprise support is good, however we have had most of our questions answered rather quickly in IRC or the mailing list. There is usually always somebody around from Basho to help you out. The Riak Recaps are also a great way to keep up to date with what is going on in the community.