Is Riak suitable for s small-record write-intensive billion-records application?
guido.medina at temetra.com
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 speaking...fast !!!, 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 temetra.com> wrote:
>> Riak is all about high availability, if eventually consistent data is not a
> 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