redundant writers

Les Mikesell lesmikesell at
Tue Feb 15 15:38:51 EST 2011

In this scenario, the behavior I would want would be to only see one 
copy for each unique key, but to always have one even if one of the 
feeds or writers fails or the cluster is partitioned, then re-joined. 
This sounds good in theory, but what about the details? Is there likely 
to be a big performance hit from the normally-colliding writes?  Will it 
take twice the disk space, the eventually clean up the duplicates? Would 
it be reasonable to do this to riak-search with something like news stories?

On 2/15/2011 2:02 PM, Alexander Sicular wrote:
> What about siblings? (seach for sibling)
> On Tue, Feb 15, 2011 at 14:57, Dan Reverri<dan at>  wrote:
>> Riak maintains a single value per key and provides mechanisms (vector
>> clocks) to detect/resolve conflicting values. In the proposed use case the
>> multiple copies would overwrite each other and Riak, by default, would
>> return a single value for a requested key.
>> Behind the scenes Riak determines the appropriate value per key using vector
>> clocks. More information about vector clocks is available here:
>> Thanks,
>> Dan
>> Daniel Reverri
>> Developer Advocate
>> Basho Technologies, Inc.
>> dan at
>> On Tue, Feb 15, 2011 at 10:11 AM, Les Mikesell<lesmikesell at>
>> wrote:
>>> Is riak suitable as a very reliable store where you have multiple feeds of
>>> streaming data that are at least theoretically identical?  That is, can you
>>> count on writing multiple copies with the same keys at the same time to do
>>> something reasonable regardless of cluster partitioning?  And is this a
>>> common usage scenario?
>>> --
>>>   Les Mikesell
>>>    lesmikesell at
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users at
>> _______________________________________________
>> riak-users mailing list
>> riak-users at

More information about the riak-users mailing list