Riak instead of memcached?

Ryan Zezeski rzezeski at gmail.com
Wed Feb 16 21:21:59 EST 2011

On Wed, Feb 16, 2011 at 8:38 PM, Joshua Partogi <joshua.java at gmail.com>wrote:

> Why don't you use Membase/Couchbase instead? It provides the same
> capability as memcached but adds clustering capability on top of it.
Interesting you mentioned that.  At work today, I went over the architecture
of an application I've been writing for the last 6 months.  It makes heavy
use of riak.  One of the architects questioned me about my choice to use
Riak, as he and others are pushing strongly for Membase.  I said that, for
me, Riak was the path of least resistence.  However, his question stuck with
me and I've bee trying to read up on Membase most of the afternoon.

>From what I've found, Membase does seem similar in certain ways, but vastly
different in others.  For example, one of the things I love about Riak is
that it's built on the foundations laid out in Dynamo.    Things like
consistent hashing, vector clocks, hinted handoff, merkle trees, etc.  I'm
able to read that paper and have a good understanding of what Riak does with
my data.  Furthermore, I can take this knowledge with me to any other
Dynamo-based solution such as BigCouch.  After searching around on the
Membase site for the last hour and a half I still have no idea how it
achieves HA.  The only thing I've found so far was a post by Dustin Sallings
about memcached-vbuckets [1] which at first glance appears to be a less
robust version of consistent hashing?  I only skimmed, so I'm not sure.

The truth is, I know very little about Membase so it's easy for me to prefer
Riak.  There are so many things to like:

* highly available: I can destroy one (or more) of my coffe mugs [2], err I
mean riak nodes, and the cluster and all it's data are still completely

* configurable CAP: N, R, W -- not only is N _trivially_ configured per
bucket, but I can also configure R and W _per_ request!

* scalable: adding more nodes to a running cluster is stupid simple, and the
cluster remains fully operational thanks to hinted handoff

* distributed/redundant/consistent hashing: I don't have to tell riak how or
where to distribute the data, as I damn well shouldn't

* _completely_ decentralized: there is no such thing as a master or a slave
or an active node or anything like that, NO.  It's just a node, like any

* multi-backend: each bucket can use a different backed, and Riak supports
quite an array of backends!  does anyone else offer this?

* multiple client interfaces: native Erlang, protocol buffers, and most
importantly, HTTP.  HTTP should be required for _any_ app these days

* extremely flexible map-reduce: Membase will have some form of map-reduce
once "CouchBase" is delivered, but that's vaporware ATM AFAICT

* key filtering

* riak-search: a distributed indexing engine that uses the core technologies
found in riak

* riak-core: the core set of technologies responsible for all the Dynamo
goodness found in riak-kv and riak-search.  the app I built uses riak-core
as well

* luwak: a large-object store built on top of riak -- sure, you can't delete
any data from it yet but I have a fork with some proof of concept code that
proves it can be done, even by a simp like me

So what are the high-points for Membase?  What does it hit from the above
and what does it miss?  What does it provide that Riak doesn't?

Please, if you guys think I'm hijacking this thread then tell me and I'll
start another.  I figur since the OP asked about memcached that it's fair

1: http://dustin.github.com/2010/06/29/memcached-vbuckets.html

2: http://vimeo.com/13667174

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110216/3acf416d/attachment.html>

More information about the riak-users mailing list