Epoch-based commit and replication in distributed OLTP databases

Lu, Yi; Yu, Xiangyao; Cao, Lei; Madden, Samuel

doi:10.14778/3446095.3446098

Cited by 31 publications

(20 citation statements)

References 74 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The effects of all these features are two-fold. On the up side, throughput increases substantially -by four times (4x) as per the experiments conducted in [10]. On the down side, a transaction's results cannot be released until the epoch end when all its writes have become durable.…”

Section: Introductionmentioning

confidence: 90%

“…A recent practical proposal is epoch-based commit [10]. Based on the widely-held notion that node failures are getting less frequent with modern hardware, it views that 2PC need not be executed at the end of every distributed transaction.…”

Section: Introductionmentioning

confidence: 99%

“…Such a trade-off requires the means to choose appropriate epoch length. These requirements were left as future work in the original paper [10] and are being fully addressed here.…”

Section: Introductionmentioning

confidence: 99%

“…The protocol of [10] proposes that all transactions executed during an epoch be aborted in case of a node failure. This assumes that each node has directly or indirectly accessed the failed node at sometime during the epoch and therefore all transactions it executed accessed some data now lost due to failure.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

A Performance Study of Epoch-based Commit Protocols in Distributed OLTP Databases

Waudby

Ezhilchelvan

Mitrani

et al. 2022

2022 41st International Symposium on Reliable Distributed Systems (SRDS)

View full text Add to dashboard Cite

Distributed OLTP systems execute the highoverhead, two-phase commit (2PC) protocol at the end of every distributed transaction. Epoch-based commit proposes that 2PC be executed only once for all transactions processed within a time interval called an epoch. Increasing epoch duration allows more transactions to be processed before the common 2PC. It thus reduces 2PC overhead per transaction, increases throughput but also increases average transaction latency. Therefore, required is the ability to choose the right epoch size that offers the desired trade-off between throughput and latency. To this end, we develop two analytical models to estimate throughput and average latency in terms of epoch size taking into account load and failure conditions. Simulations affirm their accuracy and effectiveness. We then present epoch-based multi-commit which, unlike epochbased commit, seeks to avoid all transactions being aborted when failures occur, and also performs identically when failures do not occur. Our performance study identifies workload factors that make it more effective in preventing transaction aborts and concludes that the analytical models can be equally useful in predicting its performance as well.

show abstract

Section: Introductionmentioning

confidence: 90%

Section: Introductionmentioning

confidence: 99%

“…Such a trade-off requires the means to choose appropriate epoch length. These requirements were left as future work in the original paper [10] and are being fully addressed here.…”

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

A Performance Study of Epoch-based Commit Protocols in Distributed OLTP Databases

Waudby

Ezhilchelvan

Mitrani

et al. 2022

2022 41st International Symposium on Reliable Distributed Systems (SRDS)

View full text Add to dashboard Cite

show abstract

“…For example, some mandate determinism [30,41,57,68], and are limited to noninteractive transactions that require the read/write sets of all transactions to be known prior to execution [58]. Others adopt epoch-based designs to amortize the cost of commit across several transactions [16,42,43]. Contrary to those, Zeus enhances programmability and supports fully-general transactions that need not wait the end of epochs to commit.…”

Section: Related Workmentioning

confidence: 99%

Zeus

Katsarakis

Tan

et al. 2021

Proceedings of the Sixteenth European Conference on Computer Systems

View full text Add to dashboard Cite

State-of-the-art distributed in-memory datastores (FaRM, FaSST, DrTM) provide strongly-consistent distributed transactions with high performance and availability. Transactions in those systems are fully general; they can atomically manipulate any set of objects in the store, regardless of their location. To achieve this, these systems use complex distributed transactional protocols. Meanwhile, many workloads have a high degree of locality. For such workloads, distributed transactions are an overkill as most operations only access objects located on the same server -if sharded appropriately.In this paper, we show that for these workloads, a singlenode transactional protocol combined with dynamic object re-sharding and asynchronously pipelined replication can provide the same level of generality with better performance, simpler protocols, and lower developer effort. We present Zeus, an in-memory distributed datastore that provides general transactions by acquiring all objects involved in the transaction to the same server and executing a single-node transaction on them. Zeus is fault-tolerant and stronglyconsistent. At the heart of Zeus is a reliable dynamic object sharding protocol that can move 250K objects per second per server, allowing Zeus to process millions of transactions per second and outperform more traditional distributed transactions on a wide range of workloads that exhibit locality.

show abstract