| dc.description.abstract | Modern database systems that support ACID transactions, and applications built around
these databases, may choose to sacrifice transaction durability for performance when they
deem it necessary. While this approach may yield good performance, it has three major
downsides. Firstly, users are often not provided information about when and if the issued
transactions become durable. Secondly, users cannot know if durable and non-durable
transactions see each other’s effects. Finally, this approach pushes durability handling
outside the scope of the transactional model, making it difficult for applications to reason
about correctness and data consistency.
To address these issues, we present the idea of “Eventual Durability” (ED) to provide a
principled way for applications to manage transaction durability trade-offs. The ED model
extends the traditional transaction model by decoupling a transaction’s commit point from
its durability point – therefore, allowing applications to control which transactions should
be acknowledged at commit point and which ones at their durability point. Furthermore,
we redefine serialisability and recoverability under ED to allow applications to ascertain
if fast transactions became durable and how they might have interacted with safe ones.
With ED, users and applications can know what to expect to lose when there is a failure
– thus, bringing back managing durability inside the transaction model.
We implement the ED model in PostgreSQL and evaluate it to understand the model’s
effect on transaction latency, abort rates and throughput. We show that ED Postgres
achieves significant latency improvements even while ensuring the guarantees provided by
the model. Since a transaction’s resources are released earlier in ED Postgres, we expected
to see lower abort rates and higher throughput. Consequently, we observed that ED
Postgres provides an average of 91.25% – 93% reduction in abort rates under a contentious
workload and an average of 75% increase in throughput compared to baseline Postgres.
We also run the TPC-C benchmark against ED Postgres and discuss the findings. Lastly,
we discuss how ED Postgres can be used in realistic settings to obtain latency benefits,
throughput improvements, reduced abort rates, and fresher reads. | en |
