Extending Eventually Consistent Cloud Databases for Enforcing Numeric Invariants

Abstract

Abstract-Geo-replicated databases often operate under the principle of eventual consistency to offer high-availability with low latency on a simple key/value store abstraction. Recently, some have adopted commutative data types to provide seamless reconciliation for special purpose data types, such as counters. Despite this, the inability to enforce numeric invariants across all replicas still remains a key shortcoming of relying on the limited guarantees of eventual consistency storage.We present a new replicated data type, called bounded counter, which adds support for numeric invariants to eventually consistent geo-replicated databases. We describe how this can be implemented on top of existing cloud stores without modifying them, using Riak as an example. Our approach adapts ideas from escrow transactions to devise a solution that is decentralized, fault-tolerant and fast. Our evaluation shows much lower latency and better scalability than the traditional approach of using strong consistency to enforce numeric invariants, thus alleviating the tension between consistency and availability.

Conflict-Free Replicated Data Types CRDTs

“…Other invariants, such as numeric invariants that usually are enforced with global coordination, can be enforced in a conflict free manner by using escrow techniques [54] that split the available resources by the different replicas. The Bounded Counter CRDT [11] defines a counter that never goes negative, by encapsulating an implementation of escrow techniques that runs under the same system model of CRDTs. The Bounded Counter assigns to each replica a number of allowed decrements under the condition that the sum of all allowed decrements do not exceed the value of the counter.…”

Impact of Adaptive Consistency on Distributed SDN Applications: An Empirical Study

“…A corner case of the exceeded limit values for isolated PN-Counter state-updates is related to the issue of conflicting over-reservations, previously discussed in [14]. Balegas et al [37], [38] solve this issue by implementing an escrow-based bounded counter CRDT, so to guarantee that a value of a counter never exceeds some limit value.…”

Borrowing an Identity for a Distributed Counter

“…We start by discussing the underlying system model we assume when designing this new variant of CRDTs. We then present the Borrow-Counter design and finally present a brief discussion on the relationship of our design with that of a recent proposal [4].…”

“…While the proposed design is new, we note that there is a relevant particularity with Bounded Counters, a CRDT counter introduced in [4]. In Bounded Counters, a design based on escrow is employed, which enables replicas, holding a copy of a counter, to synchronize outside the critical path of user operations in order to exchange fractions of the counter among them.…”