Optimistic Causal Consistency for Geo-Replicated Key-Value Stores

Abstract

Abstract-Causal consistency is an attractive consistency model for geo-replicated data stores because it hits a sweet spot in the ease of programmability vs performance trade-off.In this paper we propose a new approach to causal consistency, which we call Optimistic Causal Consistency (OCC). The optimism of our approach lies in the fact that updates from a remote data center are immediately made visible to clients in the local data center. A client, hence, always reads the freshest version of an item, whose dependencies, however, might have not been installed in the local data center yet. When serving a read request, a server can detect whether it has not received such dependencies yet. This is achieved without inter-server synchronization thanks to cheap dependency meta-data supplied by the client. Upon detecting a missing dependency, the server waits to receive it.This approach contrasts with the design of existing systems, which are prone to expose stale versions of a data items, to ensure that clients only see versions whose dependencies have already been replicated in the local data center.OCC explores a novel trade-off in the landscape of consistency models. Because network partitions are practically rare events, OCC partially trades availability to improve other performance metrics. On the one side, OCC maximizes the freshness of data returned to clients and reduces the communication overhead. On the other side, a server might need to wait before serving a client's request, leading the system to be unavailable in case of a network partition. To overcome this limitation, we propose a recovery mechanism that allows an OCC system to fall back to a pessimistic protocol to recover availability.We implement OCC in a new system, which we call POCC. We compare POCC against a recent (pessimistic) approach to causal consistency using heterogeneous workloads on an Amazon AWS deployment encompassing up to 96 nodes scattered over 3 data centers. We show that POCC is able to maximize the freshness of data returned to client while providing comparable or better performance than its pessimistic counterpart in a wide range of production-like workloads.

UniStore: A fault-tolerant marriage of causal and strong consistency (extended version)

“…Causal consistency implementations. Our subprotocol for causal consistency belongs to a family of highly scalable protocols that avoid using any centralized components or dependency check messages [3,22,[59][60][61]; other alternatives are less scalable [4,8,12,21,31,42,43,47,71]. While we base our causal consistency subprotocol on an existing one, Cure [3], we have extended it in nontrivial ways, by integrating mechanisms for tracking uniformity ( §5.4) and for transaction forwarding ( §5.5).…”

PaRiS: Causally Consistent Transactions with Non-blocking Reads and Partial Replication

“…The vast majority of the systems assume full replication and provide none or restricted transactional capabilities. This class of systems includes COPS [1], Eiger [2], ChainReaction [8], Orbe [7], GentleRain [6], Bolt-on CC [33], Contrarian [10], POCC [9], CausalSpartan [11], COPS-SNOW [14] and Eu-nomiaKV [26]. All these systems implement one-shot readonly transactions, and only Eiger additionally supports oneshot write-only transactions.…”

Wren: Nonblocking Reads in a Partitioned Transactional Causally Consistent Data Store

“…Many CC systems provide weaker semantics than TCC. COPS [15], Orbe [24], GentleRain [20], Chain-Reaction [25], POCC [38] and COPS-SNOW [7] implement read-only transactions. Eiger [21] additionally supports writeonly transactions.…”

“…Eiger [21] additionally supports writeonly transactions. These systems either block a read while waiting for the receipt of remote updates [20], [24], [38], require a large amount of meta-data [7], [15], [21], or rely on a sequencer process per DC [25]. Highly available transactional systems.…”