[ANN] Riak 2.0pre1
russell.brown at me.com
Mon Jan 20 15:14:58 EST 2014
Answers inline below:
On 20 Jan 2014, at 19:31, Elias Levy <fearsome.lucidity at gmail.com> wrote:
> On Sun, Jan 19, 2014 at 9:00 AM, <riak-users-request at lists.basho.com> wrote:
> From: Luc Perkins <lperkins at basho.com>
> * Reduced sibling creation, inspired by the dotted versions vectors research from Preguiça, Baquero, et al
>  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.
> riak-users mailing list
> riak-users at lists.basho.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the riak-users