Re: In-Memory Performance

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 coul

Re: In-Memory Performance

On Thu, Aug 4, 2011 at 11:13 AM, Les Mikesell 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 t

Re: In-Memory Performance

On 8/4/2011 9:57 AM, Matt Savona wrote: With Eric's suggestion, I re-ran my test using R=1, and the read performance got much better. Those results can be seen here: http://img59.imageshack.us/img59/2629/riakperformance2.png If you compare Riak using the LRU cache backend and Membase, it Membase

Re: In-Memory Performance

On 8/4/2011 9:23 AM, Ryan Zezeski wrote: 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

Re: In-Memory Performance

With Eric's suggestion, I re-ran my test using R=1, and the read performance got much better. Those results can be seen here: http://img59.imageshack.us/img59/2629/riakperformance2.png If you compare Riak using the LRU cache backend and Membase, it Membase is still roughly twice as fast for this p

Re: In-Memory Performance

On Wed, Aug 3, 2011 at 4:54 PM, Les Mikesell wrote: > > 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

Re: In-Memory Performance

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, consis

Re: In-Memory Performance

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.

Re: In-Memory Performance

You may also want to try the leveldb backend that is in Riak's master branch. It is faster than Innodb but doesn't store all the keys in memory like bitcask does. I am not sure how stable or mature that backend is so if you need a solution yesterday using leveldb may be off the table. The

Re: In-Memory Performance

Oh wow. You're right...thank you /very/ much for catching that. I don't know what gave me the impression that the default was R=1 (could have sworn I read it somewhere). Can't wait to try this out when I get into the office tomorrow hopefully it speeds things up a bit. I'll post some revised numbe

Re: In-Memory Performance

Unless you changed R for the bucket, the default that ships with Riak is 2. It's actually "n_val / 2 + 1" also known as the quorum . n_val is 3 by default resulting in R=2. Eric. On Tue, Aug 2, 2011 at 8:11 PM, Matt Savona wrote: > Hi Eric, > >

Re: In-Memory Performance

Hi Eric, I this test, R=1 (the default). Thanks! - Matt On Tue, Aug 2, 2011 at 4:35 PM, Eric Moritz wrote: > When you were doing the reads, did you set the r-value to 1?  This > will speed up reads in a read heavy app because only one node has to > be in agreement about the object. > > Eric. >

Re: In-Memory Performance

When you were doing the reads, did you set the r-value to 1? This will speed up reads in a read heavy app because only one node has to be in agreement about the object. Eric. On Tue, Aug 2, 2011 at 11:22 AM, Matt Savona wrote: > Hi all, > > My colleagues and I are evaluating Riak as a persisten

In-Memory Performance

Hi all, My colleagues and I are evaluating Riak as a persistent, replicated K-V store. I have a fairly simple (and not so scientific) test that reads and writes 5000 objects that are 32K in size. I am particularly interested in squeezing every last bit of performance out of Riak in a very read-he