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

Abstract

Transactional Causal Consistency (TCC) extends causal consistency, the strongest consistency model compatible with availability, with interactive read-write transactions, and is therefore particularly appealing for geo-replicated platforms. This paper presents Wren, the first TCC system that at the same time i) implements nonblocking read operations, thereby achieving low latency, and ii) allows an application to efficiently scale out within a replication site by sharding. Wren introduces new protocols for transaction execution, dependency tracking and stabilization. The transaction protocol supports nonblocking reads by providing a transaction with a snapshot that is the union of a fresh causal snapshot S installed by every partition in the local data center and a client-side cache for writes that are not yet included in S. The dependency tracking and stabilization protocols require only two scalar timestamps, resulting in efficient resource utilization and providing scalability in terms of replication sites. In return for these benefits, Wren slightly increases the visibility latency of updates. We evaluate Wren on an AWS deployment using up to 5 replication sites and 16 partitions per site. We show that Wren delivers up to 1.4x higher throughput and up to 3.6x lower latency when compared to the state-of-the-art design. The choice of an older snapshot increases local update visibility latency by a few milliseconds. The use of only two timestamps to track causality increases remote update visibility latency by less than 15%.

Distributed Transactional Systems Cannot Be Fast

“…Recall that COPS-SNOW does not ensure the W property, i.e., it does not support multi-object write transactions. N + V + W. This design is implemented by Wren [54]. In this system, the servers periodically exchange information about the minimum timestamp among those of complete transactions.…”

“…However, causally consistent read-only transactions still suffer from latency overheads. In fact, state-of-the-art causally consistent storage systems either do not support fast read-only transactions [3,25,42,54] (i.e., they do not exhibit all three desirable properties) or they are of restricted functionality by not providing multi-object write transactions [40]. Contributions.…”

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

“…We use workloads with 95:5 and 50:50 r:w ratios that correspond to the update-heavy (A) and read-heavy (B) YCSB workloads [29]. These are standard workloads also used to benchmark other TCC systems [3]- [5], [25]. Transactions generate the three workloads by executing 19 reads and 1 write (95:5), and 10 reads and 10 writes (50:50).…”

“…As we shall see shortly, the commit protocol of PaRiS allows concurrent updates on the same key, both within a DC and in different DCs. This is typically the case in TCC systems to avoid costly validation protocols for update transactions [4], [25]. In case multiple versions of a key are assigned the same timestamp, PaRiS totally orders versions by a concatenation of timestamp, transaction id and source data center id, in this order.…”

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

“…Moreover, most of the proposed causal consistency schemes do not take full advantage of partial geo‐replication, such as the approaches mentioned in the References 7‐9, each DC stores the complete data object written by the clients, which forces sites to manage not only the metadata associated with the local storage items, but also the metadata associated with the remote storage items. This undoubtedly increase the computation and communication overhead of the system, especially in the case of a relatively large number of DCs and partitions.…”