Implement update_counter #21

Open
opened 2013-09-09 12:42:01 +00:00 by brigadier · 2 comments
brigadier commented 2013-09-09 12:42:01 +00:00 (Migrated from github.com)

I wonder how hard it would be to change hanoidb to impleent something like mnesia's dirty_update_counter? Like, locate record, if found - treat value as int, increment it and write the result in the same place, if not found - create new record, everything in one atomic and probably fast operation? Would that be possible at all with architecture of this kv storage?

I wonder how hard it would be to change hanoidb to impleent something like mnesia's dirty_update_counter? Like, locate record, if found - treat value as int, increment it and write the result in the same place, if not found - create new record, everything in one atomic and probably fast operation? Would that be possible at all with architecture of this kv storage?
krestenkrab commented 2013-09-10 07:02:15 +00:00 (Migrated from github.com)

There are some interesting possibilities with CRDT-based counters, especially if you want fast updates, and can live with slightly slower reads. In this case, we could write update deltas ("increment by X"), which would be very fast; and have the merge operation accumulate counter updates. A read would then have to go through all log(N) levels and add up the counter value. So yes, it would indeed be possible.

There are some interesting possibilities with CRDT-based counters, especially if you want fast updates, and can live with slightly slower reads. In this case, we could write update deltas ("increment by X"), which would be very fast; and have the merge operation accumulate counter updates. A read would then have to go through all log(N) levels and add up the counter value. So yes, it would indeed be possible.
brigadier commented 2013-09-10 11:50:15 +00:00 (Migrated from github.com)

Will deltas work with key expire time and space compaction? I think in this case we will have to update timestamps of all updates in the stack anyway.

Will deltas work with key expire time and space compaction? I think in this case we will have to update timestamps of all updates in the stack anyway.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: greg/hanoidb#21
No description provided.