last_write_wins

Russell Brown russell.brown at me.com
Thu Jan 30 07:49:47 EST 2014


On 30 Jan 2014, at 10:58, Guido Medina <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> 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> 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> wrote:
>>> 
>>> On 29 Jan 2014, at 09:57, Edgar Veiga <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> 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
>>>> 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
> 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/c949c4f5/attachment.html>


More information about the riak-users mailing list