Hi Elias, Answers inline below:
On 20 Jan 2014, at 19:31, Elias Levy <[email protected]> wrote: > > On Sun, Jan 19, 2014 at 9:00 AM, <[email protected]> wrote: > From: Luc Perkins <[email protected]> > * Reduced sibling creation, inspired by the dotted versions vectors research > from Preguiça, Baquero, et al[1] > > [1] http://arxiv.org/abs/1011.5808 > > A quick skim over the paper seems to indicate that version vectors with > per-server entries cannot track causality among concurrent updates > coordinated by the same replica node. > > Isn't version vectors with per server entries what Riak was using previous to > this change? If so, did this lack of causality tracking apply to previous > versions? Short answer: yes-ish. 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. In the usual case this isn’t a problem. You may generate a couple of extra sibling values. In the pathological case it can lead to “sibling explosion”. In very rare cases such explosions create very large objects that can impact node, and even cluster performance. So DVV style causality tracking is very much a bug fix. We’ve also added other forms of sibling count an large object protection in Riak 2.0, which are configurable limits in the riak.conf. Cheers Russell > > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
