lesmikesell at gmail.com
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? http://wiki.basho.com/REST-API.html (seach for sibling)
> On Tue, Feb 15, 2011 at 14:57, Dan Reverri<dan at basho.com> 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:
>> Daniel Reverri
>> Developer Advocate
>> Basho Technologies, Inc.
>> dan at basho.com
>> On Tue, Feb 15, 2011 at 10:11 AM, Les Mikesell<lesmikesell at gmail.com>
>>> 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 gmail.com
>>> riak-users mailing list
>>> riak-users at lists.basho.com
>> riak-users mailing list
>> riak-users at lists.basho.com
More information about the riak-users