couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: distributed counters
Date Wed, 29 Jan 2014 14:31:32 GMT
I started futzing around with a crdt-like counter a while back. Will dust it off when I get
a chance.  

On Wednesday, 29 January 2014 at 13:48, Benoit Chesneau wrote:

> Hi all,
> I wonder if someone already thought to implement distributed counters using
> couchdb? Or more exactly counters that follow these requirements:
> - works over data replicated between different machine
> - beeing updated with the last value even if the machine became offline.
> - if a counter is {in/de}cremented on a replication the counter value on
> the network should be updated with this increment on the next replication
> -
> I saw different solutions but I am none of them are really convincing:
> 1. At the application, have a script taking a doc value and incrementing it
> then saving the doc with the new value. It doesn't really work with many
> machines. A lot of concurrent updates can happen and it is a good way to
> introduce a race condition.
> 2. Update the counter on one place, only when the machine is online.
> 3. Take one document maintaining a counter state.
> ie we could have a tree maintaining decrement/increments so we could find
> the conflicts
> Only this doc would be updated and replicated. But we have still a possible
> race condition
> 4. Put all the increments as standalone docs. And associate them to a
> counter id. All the documents would be retrieved using a views:
> emit(counterid, val)
> And reduce them. I am seeing one problem with that: the value of the
> counter is different on each machines. I am actually not sure it's a
> problem.
> 5. making a combination of 3 and 4. A instant T a concensus document is
> created with will collect the counter value on X machines using this
> concensus doc will create an update tree or an LWW-Set or smth like it if
> we follow the CRDT. once this doc has been created on each machines choosen
> it is replicated.
> I am not exactly sure about the details needed for 5 right now...
> Anyway any feedback is welcome, let me know.
> - benoit 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message