Is Riak suitable for s small-record write-intensive billion-records application?

Guido Medina guido.medina at
Fri Oct 19 09:02:27 EDT 2012

It depends, if you have siblings enabled at the bucket, then you need to 
resolve the conflicts using the object vclock, if you are not using 
siblings, last write wins, either way, I haven't got any good results by 
delegating that tasks to Riak, with siblings, eventually I ran Riak out 
in speed of the writes making Riak fail (Due to LevelDB write speed?). 
And with last write wins then I don't think you would want unexpected 
results, and hence my recommendation: We use two things to resolve such 
issues; in-memory cache + locking mechanism.

If you are concerned about locking mechanism speed, you can use MapMaker 
from Guava framework ((at least in Java) which provides a concurrency 
level making your application concurrently !!!, and for 
cache, you could use either Guava or EHCache, now, what I don't have, is 
a distributed locking mechanism (one of this days I will built a 
distributed re-entrant locking mechanism base on REST for the sake of it)

For the last quote, the locking mechanism if well designed will always 
take care of that.



On 19/10/12 13:42, Les Mikesell wrote:
> On Fri, Oct 19, 2012 at 6:57 AM, Guido Medina <guido.medina at> wrote:
>> Riak is all about high availability, if eventually consistent data is not a
>> problem
> What is the 'eventually consistent' result of simultaneous inserts of
> different values for a new key at different nodes?   Does partitioning
> affect this case?
>> OR, you can cover those aspects of the CAP concept with an in-memory
>> caching system and a sort of a locking mechanism to emulate the core atomic
>> action of your application (put-if-absent) then I would say, you are in the
>> right place,
> What happens if the partitioning that riak is so concerned about
> happens between the inserter and the lock - or the nodes providing
> redundancy for the lock?
>> All this said, it is at your hands and tools to have an in-memory cache and
>> locking mechanism.
> If you have more than one writer, doesn't this need to be just as
> distributed and robust as riak?

More information about the riak-users mailing list