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
