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.med...@temetra.com
<mailto: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
<mailto: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
<mailto: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
<mailto:russell.br...@me.com>> wrote:
On 29 Jan 2014, at 09:57, Edgar Veiga
<edgarmve...@gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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
