[ANN] Riak 2.0pre1

Russell Brown russell.brown at me.com
Mon Jan 20 15:50:34 EST 2014


On 20 Jan 2014, at 20:35, Elias Levy <fearsome.lucidity at gmail.com> wrote:

> On Mon, Jan 20, 2014 at 12:14 PM, Russell Brown <russell.brown at me.com> wrote:
> Longer answer: Riak gave users the option of client or _vnode_ ids in version vectors. By default Riak uses vnode ids. Riak erred on the side of caution, and would create false concurrency, rather than lose writes. 
> 
> I am curious as to how that was accomplished when using vnode version vectors.  As section 3.2 of the paper mentions, the node with concurrent updates could detect they are concurrent and it could reject the update, but how could you encode the causal history using the version vectors so as to generate a sibling?  That section ends with a statement saying no such version vector could be generated.
> 
> Presumably Riak implemented a version vector that is somewhat different from that described in the paper?

I guess you must be right. Riak’s vnode version vectors, in the case described in 3.2 would generate siblings. The put of `v` with an empty VV would lead to the value `v` and VV {b, 1}, but the put of `w` with no VV would not lead to a VV of {b, 2} and overwriting of {b, 1}=`v`.

What Riak does is this: look at the incoming VV, and increment it (so {b, 1}=`w` for that second client put) read the state on disk ({b, 1}=`v`) realise that these values are concurrent (the incoming value does not dominate the local value), so keep them both, and generate a VV that dominates ({b, 2}=`v`, `w`).

Does that answer your question?

Cheers

Russell

> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20140120/47abc976/attachment.html>


More information about the riak-users mailing list