last_write_wins

Guido Medina guido.medina at temetra.com
Thu Jan 30 05:58:14 EST 2014


Hi,

Now I'm curious too, according to 
http://docs.basho.com/riak/latest/ops/advanced/configs/configuration-files/ 
the default value for Erlang property last_write_wins is false, now, if 
95% of the buckets/keys have no siblings (or conflict resolution), does 
that mean that for such buckets last_write_wins is set to true, I'm 
wondering what's the effect (if any) if allow_multi on a bucket is false.

In other words; I could assume that:

  * If allow_multi is true then last_write_wins will be ignored 'cause
    vclock is needed for conflict resolution?
  * if allow_multi is false then last_write_wins is true?

Correct me if I'm wrong,

Again, we have a very similar scenarios, where we create/modify keys and 
we are certain we have the latest version so for us last_write_wins...

Regards,

Guido.

On 30/01/14 10:46, Russell Brown wrote:
>
> On 30 Jan 2014, at 10:37, Edgar Veiga <edgarmveiga at gmail.com 
> <mailto:edgarmveiga at gmail.com>> wrote:
>
>> Also,
>>
>> Using last_write_wins = true, do I need to always send the vclock 
>> while on a PUT request? In the official documention it says that riak 
>> will look only at the timestamp of the requests.
>
> Ok, from what you've said it sounds like you are always wanting to 
> replace what is at a key with the new information you are putting. If 
> that is the case, then you have the perfect use case for LWW=true. And 
> indeed, you do not need to pass a vclock with your put request. And it 
> sounds like there is no need for you to fetch-before-put since that is 
> only to get context /resolve siblings. Curious about your use case if 
> you can share more.
>
> Cheers
>
> Russell
>
>
>>
>> Best regards,
>>
>>
>> On 29 January 2014 10:29, Edgar Veiga <edgarmveiga at gmail.com 
>> <mailto:edgarmveiga at gmail.com>> wrote:
>>
>>     Hi Russel,
>>
>>     No, it doesn't depend. It's always a new value.
>>
>>     Best regards
>>
>>
>>     On 29 January 2014 10:10, Russell Brown <russell.brown at me.com
>>     <mailto:russell.brown at me.com>> wrote:
>>
>>
>>         On 29 Jan 2014, at 09:57, Edgar Veiga <edgarmveiga at gmail.com
>>         <mailto:edgarmveiga at gmail.com>> wrote:
>>
>>>         tl;dr
>>>
>>>         If I guarantee that the same key is only written with a 5
>>>         second interval, is last_write_wins=true profitable?
>>
>>         It depends. Does the value you write depend in anyway on the
>>         value you read, or is it always that you are just getting a
>>         totally new value that replaces what is in Riak (regardless
>>         what is in Riak)?
>>
>>>
>>>
>>>         On 27 January 2014 23:25, Edgar Veiga <edgarmveiga at gmail.com
>>>         <mailto:edgarmveiga at gmail.com>> wrote:
>>>
>>>             Hi there everyone!
>>>
>>>             I would like to know, if my current application is a
>>>             good use case to set last_write_wins to true.
>>>
>>>             Basically I have a cluster of node.js workers reading
>>>             and writing to riak. Each node.js worker is responsible
>>>             for a set of keys, so I can guarantee some kind of non
>>>             distributed cache...
>>>             The real deal here is that the writing operation is not
>>>             run evertime an object is changed but each 5 seconds in
>>>             a "batch insertion/update" style. This brings the
>>>             guarantee that the same object cannot be write to riak
>>>             at the same time, not event at the same seconds, there's
>>>             always a 5 second window between each insertion/update.
>>>
>>>             That said, is it profitable to me if I set
>>>             last_write_wins to true? I've been facing some massive
>>>             writting delays under high loads and it would be nice if
>>>             I have some kind of way to tune riak.
>>>
>>>             Thanks a lot and keep up the good work!
>>>
>>>
>>>         _______________________________________________
>>>         riak-users mailing list
>>>         riak-users at lists.basho.com <mailto:riak-users at lists.basho.com>
>>>         http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>>
>
>
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20140130/66efc493/attachment.html>


More information about the riak-users mailing list