[Paper Review] Coordination Avoidance in Database Systems (Extended Version)

Peter Bailis, Alan Fekete+4 more|arXiv (Cornell University)|Feb 10, 2014

Distributed systems and fault tolerance78 references3 citations

TL;DR

This paper introduces invariant confluence ($\mathcal{I}$-confluence), a formal framework that determines when database operations can execute coordination-free while preserving application-level invariants. By analyzing integrity constraints like foreign keys and check constraints, the authors show that many common operations are $\mathcal{I}$-confluent, enabling up to a 25-fold performance improvement over serializable execution in TPC-C New-Order workloads without sacrificing correctness.

ABSTRACT

Minimizing coordination, or blocking communication between concurrently executing operations, is key to maximizing scalability, availability, and high performance in database systems. However, uninhibited coordination-free execution can compromise application correctness, or consistency. When is coordination necessary for correctness? The classic use of serializable transactions is sufficient to maintain correctness but is not necessary for all applications, sacrificing potential scalability. In this paper, we develop a formal framework, invariant confluence, that determines whether an application requires coordination for correct execution. By operating on application-level invariants over database states (e.g., integrity constraints), invariant confluence analysis provides a necessary and sufficient condition for safe, coordination-free execution. When programmers specify their application invariants, this analysis allows databases to coordinate only when anomalies that might violate invariants are possible. We analyze the invariant confluence of common invariants and operations from real-world database systems (i.e., integrity constraints) and applications and show that many are invariant confluent and therefore achievable without coordination. We apply these results to a proof-of-concept coordination-avoiding database prototype and demonstrate sizable performance gains compared to serializable execution, notably a 25-fold improvement over prior TPC-C New-Order performance on a 200 server cluster.

Motivation & Objective

• To address the scalability and availability limitations of traditional serializable transactions, which require excessive coordination.
• To determine when coordination is strictly necessary for application-level consistency, rather than relying on conservative isolation levels.
• To formalize a condition—$\mathcal{I}$-confluence—that is both necessary and sufficient for safe, coordination-free execution.
• To analyze real-world database invariants and operations to identify which can be executed without coordination.
• To demonstrate the practical performance benefits of coordination avoidance in a prototype system.

Proposed method

• Define invariant confluence ($\mathcal{I}$-confluence) as a formal condition ensuring that concurrent execution of operations preserves application invariants.
• Model database operations and invariants as state transitions over a database state space, analyzing whether concurrent executions can be merged into a valid state.
• Apply $\mathcal{I}$-confluence analysis to common integrity constraints: foreign keys, unique constraints, check constraints, and primary keys.
• Implement a coordination-avoiding database prototype that uses $\mathcal{I}$-confluence to dynamically decide when coordination is required.
• Use the analysis to guide the design of coordination-free algorithms, such as for RAMP transactions and cascading deletes.
• Benchmark the prototype against serializable execution using TPC-C New-Order and OLTPBench workloads to measure performance gains.

Experimental results

Research questions

• RQ1 When is coordination strictly necessary to maintain application-level consistency?
• RQ2 Can we formally determine whether a set of operations can be safely executed without coordination while preserving invariants?
• RQ3 Which common database constraints (e.g., foreign keys, unique constraints) are $\mathcal{I}$-confluent and thus safe to execute coordination-free?
• RQ4 To what extent can coordination avoidance improve performance in real-world OLTP workloads?
• RQ5 Can $\mathcal{I}$-confluence be used as a design principle for building scalable, high-performance database systems?

Key findings

• Many common database invariants, including foreign key constraints, unique value generation, and check constraints, are $\mathcal{I}$-confluent and thus safe for coordination-free execution.
• Primary key constraints are not $\mathcal{I}$-confluent in general, requiring coordination to prevent conflicts.
• The coordination-avoiding prototype achieved a 25-fold performance improvement over serializable execution on the TPC-C New-Order benchmark in a 200-server cluster.
• The $\mathcal{I}$-confluence analysis correctly identified that insertion and cascading deletes under foreign key constraints are coordination-free, enabling efficient distributed algorithms.
• The framework enables databases to coordinate only when necessary, significantly reducing coordination overhead compared to serializable isolation.
• The results demonstrate that coordination avoidance is not only theoretically sound but also practically viable and highly performant in real-world workloads.