last_write_wins

Guido Medina guido.medina at temetra.com
Thu Jan 30 09:53:23 EST 2014


Hi Russell,

Thanks for your response, I understand most of it, I know LWW=true and 
allow_multi=true won't make any sense, but look at this scenario:

All of our buckets have allow_multi=false except for the one bucket we 
have for CRDT counters, our application requires certain some level of 
consistency so we have full control of our reads/writes using a fine 
grain locking mechanism combined with in-memory cache so in our case the 
LWW=true is what we would want?, now, we haven't touched this parameter 
so it is at its default value.

I'm assuming it will improve performance for our case, but, if we set 
LWW=true, will it affect the bucket(s) with allow_multi=true, is it safe 
to assume that if allow_multi=true LWW will be ignored? We only modify 
bucket properties using Riak Java client 1.4.x atm.

Also, about safety, LWW=true uses timestamp? and LWW=false uses vclock?, 
future of both?, should we leave it untouched? we don't really want to 
use something that could jeopardise our data consistency requirement 
even if it means better performance.

Hopefully I'm enriching the subject and not hijacking it,

Thanks,

Guido.

On 30/01/14 12:49, Russell Brown wrote:
>
> On 30 Jan 2014, at 10:58, Guido Medina <guido.medina at temetra.com 
> <mailto:guido.medina at temetra.com>> wrote:
>
>> 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?
>>
> They’re independant settings, but allow_mult=true + lww=true makes no 
> sense (in reality, in the code, I’m pretty sure the lww=true will be 
> applied.)
>
> allow_mult=false+lww=false means at each vnode there is a 
> read-before-write, and casually dominated values are dropped, while 
> siblings values are made, but before we write to disk (or return to 
> the user on get) we pick the sibling with the highest timestamp. This 
> means that you get _one_ of the causally concurrent values, the one 
> with the largest timestamp.
>
> allow_mult=false+lww=false means that at the coordinating vnode we 
> just increment whatever vclock the put has (probably none, right?) and 
> write it to disk (no read of the local value first) and down stream at 
> the replicas, the same thing, just store it. I need to check, but on a 
> get, if there are siblings, just pick the highest timestamp.
>
> I really think, for riak, 90% of the time, allow_mult=true is your 
> best choice. John Daily did a truly exhaustive set of blog posts on 
> this 
> http://basho.com/understanding-riaks-configurable-behaviors-part-1/ I 
> highly recommend it. If you data is always overwrite maybe LWW makes 
> sense for you. If it is write once, read ever after LWW is perfect.
>
> Cheers
>
> Russell
>>
>> 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
>>
>> _______________________________________________
>> 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
>

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


More information about the riak-users mailing list