Replicated data types

Abstract

Geographically distributed systems often rely on replicated eventually consistent data stores to achieve availability and performance. To resolve conflicting updates at different replicas, researchers and practitioners have proposed specialized consistency protocols, called replicated data types, that implement objects such as registers, counters, sets or lists. Reasoning about replicated data types has however not been on par with comparable work on abstract data types and concurrent data types, lacking specifications, correctness proofs, and optimality results.To fill in this gap, we propose a framework for specifying replicated data types using relations over events and verifying their implementations using replication-aware simulations. We apply it to 7 existing implementations of 4 data types with nontrivial conflictresolution strategies and optimizations (last-writer-wins register, counter, multi-value register and observed-remove set). We also present a novel technique for obtaining lower bounds on the worstcase space overhead of data type implementations and use it to prove optimality of 4 implementations. Finally, we show how to specify consistency of replicated stores with multiple objects axiomatically, in analogy to prior work on weak memory models. Overall, our work provides foundational reasoning tools to support research on replicated eventually consistent stores.

On the complexity of checking transactional consistency

“…Cerone et al [14] give the first formalization of the criteria we consider in this paper, using the specification methodology of Burckhardt et al [12]. This formalization uses two auxiliary relations, a visibility relation which represents the fact that a transaction "observes" the effects of another transaction and a commit order, also called arbitration order, like in our case.…”

“…Previous work [11,12,14] has formalized such consistency models using two auxiliary relations: a visibility relation defining for each transaction the set of transactions it observes, and a commit order defining the order in which transactions are committed to the "global" memory. An execution satisfying some consistency model is defined as the existence of a visibility relation and a commit order obeying certain axioms.…”

CLOTHO: directed test generation for weakly consistent database systems

“…Following the literature on weak consistency and isolation semantics [Burckhardt et al 2014] we can specify constraints on vis and ar relations which identify when system states are consistent with a particular database's consistency guarantees. Table 1 presents some well-known instances of such guarantees and their specifications, where the predicate st simply relates effects created by queries from the same transaction instance.…”

Conflict-Free Replicated Data Types CRDTs

“…al. [21] 1 , we consider the value defined as a function of the set of updates O known at a given replica, the happens-before relation, ≺, established among updates and, for some data types, of the total order, <, defined among updates.…”

“…al. [21], a CRDT can be specified by relying on: (i) the full history of updates executed; (ii) the happens-before relation among updates; and (iii) an arbitration relation among updates (when necessary). A query can be specified as a function that uses this information and the value of parameters to compute the result.…”