If we have no siblings (last write wins), can we use timestamps to guarantee causality?
________________________________ From: Reid Draper [[email protected]] Sent: Thursday, December 13, 2012 7:40 AM To: Vergara, Jeaneth Aguilar Cc: [email protected]; Shah, Nikhil M Subject: Re: Monotonic Read Consistency On Dec 12, 2012, at 6:39 PM, "Vergara, Jeaneth Aguilar" <[email protected]<mailto:[email protected]>> wrote: Monotonic read consistency means if a process has seen a particular value for the object, any subsequent accesses will never return any previous values. (quoted from http://www.allthingsdistributed.com/2007/12/eventually_consistent.html). Aside from the aforementioned bug [1], requesting reads with PR=quorum will achieve this. Let me rephrase the guarantee this gives you: Any actor A will always read values causally equal or greater than previous reads by the same actor. Yes, the cache is local to each actor. The actor can read something that it did not write. When it tries to read that object again, it needs to ensure that it either gives back the previously read version because it's more current or return the new one (because it's the latest value). If the Riak server returns an older value (maybe due to a partition failure and it gave back an older value), then we can catch that scenario. If the last modified timestamp is consistent across all replicas, then maybe we can just use that value instead of setting up our own vector clock. Can you please confirm it's the same in all replicas (or it's the same value for all consistent replicas)? What I mean is for A/B/C/D/E, assuming there's no partition, they'll all have the same value of Dec. 12, 2012 2:20 PM once that update is propagated to all replicas. The timestamp is tied to a particular 'version' of an object. The same timestamp will always be returned when any replica returns the same version. In all but some extreme cases (ie. spanner), timestamps are not suitable for guaranteeing causality though. ________________________________ From: Reid Draper [[email protected]<mailto:[email protected]>] Sent: Wednesday, December 12, 2012 2:45 PM To: Vergara, Jeaneth Aguilar Cc: [email protected]<mailto:[email protected]>; Shah, Nikhil M Subject: Re: Monotonic Read Consistency On Dec 12, 2012, at 4:01 PM, "Vergara, Jeaneth Aguilar" <[email protected]<mailto:[email protected]>> wrote: Thanks Reid, we have that implementation for Read Your Writes already. We'd like to implement Monotonic Read Consistency as well. For Monotonic Read Consistency, we were hoping to do Vector Clock comparison but we don't know how to convert the byte[] into different client's timestamps. Can you go into more explanation of exactly what you mean by 'Monotonic Read Consistency'? Vectors clocks in Riak are meant to be opaque. It's not impossible to use/decode them, but it's not trivial (particularly outside of Erlang). We've not run into a use-case (afaik) where someone _needed_ to decode them. Here's a work around we've thought of for now to implement Monotonic Read Consistency: 1. We'll just add another field in our object to track which client wrote it and a version number (so sort of implementing our own vector clock) 2. Then we'll just do last write wins (no siblings) 3. We'll cache our writes and reads where is this cache? is it local to each actor? If so, sounds like you've just implemented read-your-writes 4. If we do a read and it has a vector clock less than what's in our cache, we'll use the one in our cache 5. If we do a read and it has a vector clock greater than what's in our cache, we'll update our cache and use that latest version If you know of a way how a client can interpret the vector clock returned by Riak API, then we don't have to implement our own poor man's vector clock. Also, what's the timestamp returned as part of the Riak API? Is that the timestamp when the response was created? Or is that the timestamp of the record inside each instance of Riak DB where that data came from -- is that timestamp consistent across all replicas? The last-modified timestamp should be when the write for that version of the value was recorded. ________________________________ From: Reid Draper [[email protected]<mailto:[email protected]>] Sent: Wednesday, December 12, 2012 11:21 AM To: Vergara, Jeaneth Aguilar Cc: [email protected]<mailto:[email protected]> Subject: Re: Monotonic Read Consistency If your writes and reads are written with PR+PW > N (note PR/PW and not R/W), then you should get read-your-writes consistency. There is unfortunately a bug with PR/PW [1] that means this is not a 100% guarantee at the moment. I'm hoping for it to be fixed by Riak 1.4, if not earlier. I don't have JavaDoc handy, but setting PR and PW should be the same as setting any other per-request parameter. For an N value of 3 (the default), I'd likely recommend setting PR and PW to 2. You can get around the aforementioned bug by setting PR=PW=N, which will lower your availability, but gaurantee read-your-writes consistency. Note that read-your-writes is slightly different than just monotonic read consistency, but I'm guessing it's closer to what you had in mind. [1] https://github.com/basho/riak_kv/issues/388 Reid On Dec 5, 2012, at 11:13 PM, "Vergara, Jeaneth Aguilar" <[email protected]<mailto:[email protected]>> wrote: Hi there, We're trying to implement monotonic read consistency at the client side using Riak's Java client. We're kind of stumped on how to do vector clock comparison so we can ensure that we're always getting the latest version. Any tips would be appreciated. Thanks, Jing _______________________________________________ riak-users mailing list [email protected]<mailto:[email protected]> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
