counter crdt in riak

David Byron dbyron at
Wed Oct 21 01:48:18 EDT 2015

On 10/20/15 9:26 PM, xiaclo at wrote:
> This gives a little more detail about each of the CRDT types:

Thanks much.  That link is very helpful.

> Your assumptions are correct.  Within Riak, an actor is a vnode, and
> counters behave as G-Counters.
> Keep in mind that Riak counters store both an increment and decrement
> for each actor, which allows decrements and negative counters as well
> while preserving the accuracy of G-Counters.

I'd read in 
that riak's counters were PN...which I think is what you're 
saying...except the part about them behaving as G-Counters.

Sorry if I'm a little slow on the uptake here, and thanks again for your 


> Hope this helps,
> Jason
> ________________________________________________________________________
> From: David Byron <dbyron at <mailto:dbyron at>>
> Date: Wed Oct 21 2015 15:03:04 GMT+1100 (AUS Eastern Summer Time)
> To: riak-users at <riak-users at
> <mailto:riak-users at>>
> Subject: counter crdt in riak
> Apologies if this is basic question, or one that's already been
> answered.  I've done a fair amount of digging (e.g.
>, but
>   I'm still confused about the documentation regarding conflict
> resolution  for riak's crdt counter.  Specifically this:
>   (using the blame view to get a line number reference in markdown),
> which  says:
> "Counters | Each actor keeps an independent count for increments and
> decrements; upon merge, the pairwise maximum of the counts for each
> actor will win (e.g. if one count for an actor holds 172 and the other
> holds 173, 173 will win upon merge)"
> This makes it sound to me like an increment from one of the actors gets
>   dropped.  Fingers crossed this isn't actually what happens.
> I think this is saying the same thing that the cdrt paper (section 3.1.2
>   State-based increment-only Counter (G-Counter) of
> says -- that increments that happen during a partition eventually
> resolve correctly.  I could use a more step-by-step illustration though
>   -- pairwise maximum of the counts for each actor is a little dense.
> Apologies for ugly formatting, but an example like this would make more
>   sense to me.
> - actor a increments counter
>     a {a: 1}                   b {}
> - actor b increments counter
>     a {a: 1}                   b {b: 1}
> - a merges b's info
>     a {a: 1, b: 1}             b {b: 1}
> - b merges a's info
>     a:{a: 1, b: 1}             b {a: 1, b: 1}
> so eventually this all resolves such that a and b both increment the
> counter by 2, right?  Is this how riak's crdt counter works?  If so I'll
>   breathe a sigh of relief and make a pull request against the docs if
> you  like.
> Thanks much for your help.
> -DB

More information about the riak-users mailing list