In-Memory Performance

Ryan Zezeski rzezeski at
Thu Aug 4 12:33:02 EDT 2011

On Thu, Aug 4, 2011 at 11:13 AM, Les Mikesell <lesmikesell at> wrote:
> I can understand a performance difference in reads, considering the quorum
> strategy, but the timing mentioned involved writes.  I don't know the
> membase internals but thought the claim of expanding the cluster by adding
> nodes meant they probably used a distribution strategy similar to riak.
> Another recent message mentioned wanting a 'riak wishlist' somewhere. Some
> of mine would be a membase-like client that knows about multiple nodes for
> auto-failover, and the optional addition of some special master-slave nodes
> that could be used for atomic operations without needing to use a completely
> different client library for them.
Same thing applies for writes in that a coordinator is spun up for each
incoming write, sends async requests, and then waits for W responses.  In
the case of membases's master/slave it can just write to master and at some
point the data will get pushed to slave(s).  This is why I believe the more
apple/apple comparison would be membase w/ 3 replicas and 1:N replication

If you read the links I referenced you'll see that membase does do something
similar with regards to mapping keys to physical servers.

* vbucket ~ partition on ring
* hash fun to vbucket ~ hash fun to partition
* table of vbuckets to node (physical server) ~ ring/preflist of vnodes to
* 1 node to many vbuckets ~ 1 node to many vnodes

However, the fact that membase does a similar indirect mapping of keys to
ownership doesn't necessarily mean it replicates by default.  Like I said,
reading Dustin's post made me feel like replication is something to have to

As for your wish list.  The first one is a form of smart client which would
essentially participate in gossip of the ring in order to determine which
nodes to contact.  Currently we just recommend people put all the Riak nodes
behind a load balancer because any node can service any request.  A smart
client is not out of the question but it's not necessarily as easy as it
seems to get right, or so I've been told by people smarter than me.

I'm not sure I follow you on the second thing.  Riak strives for every node
to be completely equal.  I.e. there is no such thing as a master because
when you introduce special nodes you increase chance for failure.  In Riak
all nodes can service all requests; which is in spirit with it's high
availability focus.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list