In-Memory Performance

Eric Moritz eric at
Tue Aug 2 21:19:59 EDT 2011

    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 Basho
folks can address the timetable and stability of the leveldb backend
better than I can.

If it ends up being close to as fast as the memory backend and you get
persistence it may be your best bet to get what you need from Riak.
The downside is it is a bleeding edge feature.


On Tue, Aug 2, 2011 at 8:50 PM, Matt Savona <matt.savona at> wrote:
> 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 numbers once I run my test again.
> - Matt
> On Tue, Aug 2, 2011 at 8:32 PM, Eric Moritz <eric at> wrote:
>> 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 <matt.savona at> wrote:
>>> Hi Eric,
>>> I this test, R=1 (the default).
>>> Thanks!
>>> - Matt
>>> On Tue, Aug 2, 2011 at 4:35 PM, Eric Moritz <eric at> 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.
>>>> On Tue, Aug 2, 2011 at 11:22 AM, Matt Savona <matt.savona at> wrote:
>>>>> 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-heavy environment. I want to avoid hitting disk for reads as much
>>>>> as possible; our entire content set is much larger than could ever be
>>>>> stored in RAM, but preferably hot/active objects will remain resident
>>>>> in memory until various conditions may force them to be evicted. While
>>>>> the content set is quite large, the number of active keys represent a
>>>>> very small portion of the data which could easily fit in RAM.
>>>>> I've been running the same test against Riak given various
>>>>> combinations of backends and access protocols (HTTP vs. PB).
>>>>> My numbers can be seen in this screenshot:
>>>>> It is quite evident (and perhaps obvious) that Protocol Buffer
>>>>> performance is noticeably better than HTTP in most cases.
>>>>> What is confusing to me is the performance of purely in-memory
>>>>> backends. Notably, GB Trees and LRU Cache (and even Innostore), at
>>>>> best took 14s to retrieve 5000 32K objects. The exact same test
>>>>> against Membase took just 6s.
>>>>> Perhaps I'm not comparing apples to apples (Riak in-memory versus
>>>>> Membase). Do my tests look reasonable and do the numbers look roughly
>>>>> in-line with expectations? Is there any way to squeeze more juice out
>>>>> of Riak? A purely in-memory/non-persistent backend will not suffice
>>>>> for our ultimate needs, but for testing purposes I'm just trying to
>>>>> see if I can get read performance more in line with what we're seeing
>>>>> with Membase. We love everything about it, but we haven't yet hit the
>>>>> performance we were hoping for.
>>>>> Thanks in advance!
>>>>> - Matt
>>>>> _______________________________________________
>>>>> riak-users mailing list
>>>>> riak-users at

More information about the riak-users mailing list