Minimizing Commit Latency of Transactions in Geo-Replicated Data Stores

Nawab, Faisal; Arora, Vaibhav; Agrawal, Divyakant; Abbadi, Amr El

doi:10.1145/2723372.2723729

Cited by 38 publications

(22 citation statements)

References 42 publications

(37 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Transaction systems are well-known to have issues w.r.t. latency to complete transactions [20]. RAMP-Faster would address this issue without compromising on the consistency.…”

Section: The Ramp-faster Designmentioning

confidence: 99%

Exploring Design Alternatives for RAMP Transactions Through Statistical Model Checking

Liu

Ölveczky

Ganhotra³

et al. 2017

Formal Methods and Software Engineering

View full text Add to dashboard Cite

Abstract. In this paper we explore and extend the design space of the recent RAMP (Read Atomic Multi-Partition) transaction system for large-scale partitioned data stores. Arriving at a mature distributed system design through implementation and experimental validation is a labor-intensive task, so that only a limited number of design alternatives can be explored in practice. The developers of RAMP did implement and validate three design alternatives for RAMP, and sketched three additional designs. This work addresses two questions: (1) How can the design space of a distributed transaction system such as RAMP be explored with modest effort, so that substantial knowledge about design alternatives can be gained before designs are implemented? and (2) How realistic and informative are the results of such design explorations? We answer the first question by: (i) formally modeling eight RAMP-like designs (five by the RAMP developers and three of our own) in Maude as probabilistic rewrite theories, and (ii) using statistical model checking of those models to analyze key performance metrics such as throughput, average latency, and degrees of strong consistency and read atomicity. We answer the second question by showing that our quantitative analyses: (i) are consistent with the experimental results obtained by the RAMP developers for their implemented designs; (ii) confirm the conjectures made by the RAMP developers for their other three unimplemented designs; and (iii) uncover some promising new designs that seem attractive for some applications.

show abstract

“…Transaction systems are well-known to have issues w.r.t. latency to complete transactions [20]. RAMP-Faster would address this issue without compromising on the consistency.…”

Section: The Ramp-faster Designmentioning

confidence: 99%

Exploring Design Alternatives for RAMP Transactions Through Statistical Model Checking

Liu

Ölveczky

Ganhotra³

et al. 2017

Formal Methods and Software Engineering

View full text Add to dashboard Cite

show abstract

“…There has been a steady stream of papers in recent years on systems to support transactions over geo-distributed storage, using classical ACID semantics [Baker et al 2011;Corbett et al 2013], weaker isolation for better performance [Li et al 2012;Sovran et al 2011], and optimized geo-distributed commit protocols [Kraska et al 2013;Nawab et al 2013Nawab et al , 2015. Unlike Geo, they do not provide an actor model with user-defined operations, nor do they separate geo-distribution from durability.…”

Section: Related Workmentioning

confidence: 99%

Geo-distribution of actor-based services

Bernstein

Burckhardt

Bykov

et al. 2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Many service applications use actors as a programming model for the middle tier, to simplify synchronization, fault-tolerance, and scalability. However, efficient operation of such actors in multiple, geographically distant datacenters is challenging, due to the very high communication latency. Caching and replication are essential to hide latency and exploit locality; but it is not a priori clear how to combine these techniques with the actor programming model.We present Geo, an open-source geo-distributed actor system that improves performance by caching actor states in one or more datacenters, yet guarantees the existence of a single latest version by virtue of a distributed cache coherence protocol. Geo's programming model supports both volatile and persistent actors, and supports updates with a choice of linearizable and eventual consistency. Our evaluation on several workloads shows substantial performance benefits, and confirms the advantage of supporting both replicated and single-instance coherence protocols as configuration choices. For example, replication can provide fast, always-available reads and updates globally, while batching of linearizable storage accesses at a single location can boost the throughput of an order processing workload by 7x.

show abstract

“…Helios [10] commits a distributed transaction if no conflict involving the transaction is detected across datacenters. Helios considers both failure-free and network-failure executions.…”

Section: Low-latency Commit Protocols With Weak Semanticsmentioning

confidence: 99%

“…To illustrate the nature of the problem, consider a distributed database system that ensures the serializability of transactions by tracking their concurrency conflicts across datacenters (nodes) as in Helios [10]. In short, each datacenter D votes to abort every transaction tx that causes a conflict at D. Transaction tx is committed if no datacenter detects any conflict involving tx.…”

Section: Introductionmentioning

confidence: 99%

“…To orchestrate the termination of tx, coordination is necessary among datacenters: all have to agree on whether to commit or abort tx, despite failures, and tx cannot be committed if at least one datacenter votes to abort. This coordination is called a distributed commit protocol and its complexity impacts the performance of the entire distributed database system [10].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

How Fast can a Distributed Transaction Commit?

Guerraoui

Wang

2017

Proceedings of the 36th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems

View full text Add to dashboard Cite

The atomic commit problem lies at the heart of distributed database systems. The problem consists for a set of processes (database nodes) to agree on whether to commit or abort a transaction (agreement property). The commit decision can only be taken if all processes are initially willing to commit the transaction, and this decision must be taken if all processes are willing to commit and there is no failure (validity property). An atomic commit protocol is said to be non-blocking if every correct process (a database node that does not fail) eventually reaches a decision (commit or abort) even if there are failures elsewhere in the distributed database system (termination property).Surprisingly, despite the importance of the atomic commit problem, little is known about its complexity. In this paper, we present, for the first time, a systematic study on the time and message complexity of the problem. We measure complexity in the executions that are considered the most frequent in practice, i.e., failure-free, with all processes willing to commit. In other words, we measure how fast a transaction can commit. Through our systematic study, we close many open questions like the complexity of synchronous non-blocking atomic commit. We also present optimal protocols which may be of independent interest. In particular, we present an effective protocol which solves what we call indulgent atomic commit that tolerates practical distributed database systems which are synchronous "most of the time".

show abstract

Minimizing Commit Latency of Transactions in Geo-Replicated Data Stores

Cited by 38 publications

References 42 publications

Exploring Design Alternatives for RAMP Transactions Through Statistical Model Checking

Exploring Design Alternatives for RAMP Transactions Through Statistical Model Checking

Geo-distribution of actor-based services

How Fast can a Distributed Transaction Commit?

Contact Info

Product

Resources

About