Eventual Durability of ACID Transactions in Database Systems

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

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.