Causal consistency and latency optimality

Abstract

Causal consistency is an attractive consistency model for replicated data stores. It is provably the strongest model that tolerates partitions, it avoids the long latencies associated with strong consistency, and, especially when using read-only transactions, it prevents many of the anomalies of weaker consistency models. Recent work has shown that causal consistency allows "latency-optimal" read-only transactions, that are nonblocking, single-version and singleround in terms of communication. On the surface, this latency optimality is very appealing, as the vast majority of applications are assumed to have read-dominated workloads.In this paper, we show that such "latency-optimal" readonly transactions induce an extra overhead on writes; the extra overhead is so high that performance is actually jeopardized, even in read-dominated workloads. We show this result from a practical and a theoretical angle.First, we present a protocol that implements "almost latency-optimal" ROTs but does not impose on the writes any of the overhead of latency-optimal protocols. In this protocol, ROTs are nonblocking, one version and can be configured to use either two or one and a half rounds of client-server communication. We experimentally show that this protocol not only provides better throughput, as expected, but also surprisingly better latencies for all but the lowest loads and most read-heavy workloads.Then, we prove that the extra overhead imposed on writes by latency-optimal read-only transactions is inherent, i.e., it is not an artifact of the design we consider, and cannot be avoided by any implementation of latency-optimal readonly transactions. We show in particular that this overhead grows linearly with the number of clients.

Implementation of Cluster-wide Logical Clock and Causal Consistency in MongoDB

“…The MongoDB engineering team considered assigning a scalar value of the Hybrid logical clock to each value returned from any server node. A similar approach to dependency tracking was discussed in the [2] but with scalar physical clocks and in [16], but with vector hybrid logical clocks.…”

“…In research papers clock synchronization often means gossiping [19], [23], or heartbeats [17], [16]. However, due to the low latency requirements we need an even faster way to synchronize cluster time on all data nodes participating in an operation.…”

Distributed Transactional Systems Cannot Be Fast

“…We next present the definition of fast read-only transactions. Definition 4 expresses the exact same properties as in the original definition which was introduced in [40] and used in [22,30,58]. Definition 4 (Fast read-only transaction).…”

“…Hence, improving the performance of distributed read-only transactions has become a key requirement for modern such systems and a much investigated research topic [19,39,40]. To this end, the notion of fast read-only transactions has been introduced in [40] and studied in subsequent papers [22,30,58]. A fast read-only transaction satisfies the following three desirable properties [40]: it completes in one round of communication (one-round), it does not rely on blocking mechanisms (nonblocking), and each server communicates to the client only one value for each object that it stores locally and is being read (one-value).…”

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.…”