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
[email protected]
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
