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