In-Memory Performance

Les Mikesell lesmikesell at gmail.com
Thu Aug 4 15:04:58 EDT 2011


On 8/4/2011 11:33 AM, Ryan Zezeski wrote:
>

>     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.
>
>
> 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.

A load balancer adds unnecessary overhead and doesn't solve the failover 
issue - you have to build a failover set and arrange for the client to 
always be able to reach it - which sort of kills the concept of 
surviving network partitioning.   The memcache concept of making the 
client smart enough to talk to the 'right' server and fail gracefully if 
it can't works nicely and smart clients scale up nicely, but it is 
inconvenient to have to change the client configs if you add/remove 
nodes.  I think membase handles this internally somehow.  Conceptually I 
think the clients should at least always know a few nodes and 
fail/retry, and it would be nicer if they could obtain the full list 
from those for load balancing without necessarily participating in the 
gossip directly.

> 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.

Right, but that introduces problems for anything that needs atomic 
operations, locking, sequencing, etc.  The common wisdom seems to be to 
add something like redis for those functions - and then you have to make 
it reliable.

> In Riak all nodes can service all requests; which is in spirit
> with it's high availability focus.

Yes, except that since a client only knows one node, the high 
availability isn't inherent, you have to add something else special, and 
manage it separately.  And since riak doesn't have atomic operations, 
you have to add some other service for that, and again build/manage at 
least a pair with replication.  From an operational standpoint, managing 
a few 'special' machines seems to be a requirement that can't be 
avoided.   From a software perspective, though, it would be nice to 
everything in a single client library - that is, something that won't 
break if it can't contact the single configured server and something 
that can perform operations that look like a transaction or sequence 
generation along with storing and retrieving sometimes-consistent data. 
  If atomic operations were an optional feature requiring a specified 
master/slave arrangement on certain nodes that you would have to keep 
mostly-working, you wouldn't lose any existing functionality and you 
could still treat the bulk of the storage nodes as elastic.

-- 
   Les Mikesell
    lesmikesell at gmail.com





More information about the riak-users mailing list