In-Memory Performance

Les Mikesell lesmikesell at gmail.com
Wed Aug 3 16:54:35 EDT 2011


On 8/2/2011 10:31 PM, Ryan Zezeski wrote:
> Matt,
>
> I've said it a couple of times on the ML recently but I think it's worth
> saying again.  Riak is not a cache.  Riak's core competency is being a
> _highly available_ data store.  The highly available part is primarily
> accomplished via replicas, consistent hashing, and fallback/hinted
> handoff.  Even when using an in-memory backend you must pay the toll of
> using replicas.  If you really wanted to push Riak to it's limits as a
> cache then perhaps a separate bucket with N=1 would be something to try,
> but you'll still have overhead to pay in regards to coordination (yes,
> it's only 1 vnode but a coordinator will still be used) and possible
> vnode contention if you have a key that is often accessed (all reads to
> the same key will be performed in sequential order on the same vnode).
>
> It is this fundamental decision made by Riak that almost guarantees you
> will probably not touch the performance of membase without some
> contortions.  I'm not saying you couldn't do it, and I'd be happy to be
> proved wrong :).  I just think it's using Riak for something it was
> never designed for.  It sounds like you need a cache, so why not use one?

Are you confusing membase with memcache?  The former is a persistent, 
replicated store, or at least that is the claim; the latter a cache.
http://www.couchbase.org/wiki/display/membase/Membase+Architecture

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the riak-users mailing list