On 30 Jan 2014, at 10:58, Guido Medina <guido.med...@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 <edgarmve...@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 <edgarmve...@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.br...@me.com> wrote: >>> >>> On 29 Jan 2014, at 09:57, Edgar Veiga <edgarmve...@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 <edgarmve...@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@lists.basho.com >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >>> >> >> >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
