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

Abstract

Geo-replicated data platforms are at the backbone of several large-scale online services. Transactional Causal Consistency (TCC) is an attractive consistency level for building such platforms. TCC avoids many anomalies of eventual consistency, eschews the synchronization costs of strong consistency, and supports interactive read-write transactions. Partial replication is another attractive design choice for building geo-replicated platforms, as it increases the storage capacity and reduces update propagation costs.This paper presents PaRiS, the first TCC system that supports partial replication and implements non-blocking parallel read operations, whose latency is paramount for the performance of read-intensive applications. PaRiS relies on a novel protocol to track dependencies, called Universal Stable Time (UST). By means of a lightweight background gossip process, UST identifies a snapshot of the data that has been installed by every DC in the system. Hence, transactions can consistently read from such a snapshot on any server in any replication site without having to block. Moreover, PaRiS requires only one timestamp to track dependencies and define transactional snapshots, thereby achieving resource efficiency and scalability.We evaluate PaRiS on a large-scale AWS deployment composed of up to 10 replication sites. We show that PaRiS scales well with the number of DCs and partitions, while being able to handle larger data-sets than existing solutions that assume full replication. We also demonstrate a performance gain of non-blocking reads vs. a blocking alternative (up to 1.47x higher throughput with 5.91x lower latency for read-dominated workloads and up to 1.46x higher throughput with 20.56x lower latency for writeheavy 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).…”

“…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). Some of the above protocols [31,60] use hybrid clocks instead of real time [35] to improve performance with large clock skews; this technique can also be integrated into UNISTORE.…”

Adjoin: A causal consistency model based on the adjacency list in a distributed system

“…However, in the partially replicated system, each DC stores only a subset of the full data, which can effectively reduce the system storage and communication overhead but designing the causal consistency model is more challenging than with full geo-replication. 6 As shown in Figure 2B, each DC stores only partial copies of A, B, C, and D. It is necessary not only to consider how current users of the local DC can have fast access to the remaining nodes' data in a specified location, but also to design a way to synchronize updates between DCs in different subsets. Assume that the copies of A and B are stored in DC 1 and DC 2 , and the copies of C are stored in DC 2 and DC 3 .…”

“…It reduces update visibility latency, but the computation and storage overhead associated with the metadata management hampers throughput. To reduce the metadata storage cost, in the scenario that supports partial geo‐replication, PaRis 6 proposed a solution to track causal consistency with two scalar timestamps, one timestamp is used to track the dependencies of local items, and the other is used to track the dependencies of remote items. However, due to the selection principle of these two timestamps, it increases the update visibility latency.…”

All in One: Design, Verification, and Implementation of SNOW-optimal Read Atomic Transactions

“…Read atomicity (RA) [10]-either all or none of a transaction's updates are visible to another transaction's readsmagnificently bridges the gap between C and A in a distributed setting by providing the strongest data consistency that is achievable with high availability (the HAT semantics [9]). Many industrial and academic distributed databases have therefore integrated read atomic transactions as important building blocks [4,10,21,48,53,75]. To cite a few examples, RAMP-TAO [21] has recently layered RA on Facebook's TAO data store [18] to provide atomically visible and highly available transactions.…”