Intelligent Transaction Scheduling via Conflict Prediction in OLTP DBMS

TL;DR

Transaction conflicts are a major bottleneck in main-memory OLTP systems. The authors propose a history-based, statistical scheduling framework that represents each transaction by a compact set of references and groups transactions to minimize conflicts, effectively decoupling scheduling from the core concurrency control mechanism. Empirical results across TPC-C, SmallBank, and TATP show significant abort-rate reductions and throughput gains, with Canonical scheduling approaching partitioned baseline performance for both OCC and 2PL. The approach offers a low-overhead, deployable enhancement to existing DBMS architectures, supporting robust performance improvements under high contention and varying workloads.

Abstract

Current architectures for main-memory online transaction processing (OLTP) database management systems (DBMS) typically use random scheduling to assign transactions to threads. This approach achieves uniform load across threads but it ignores the likelihood of conflicts between transactions. If the DBMS could estimate the potential for transaction conflict and then intelligently schedule transactions to avoid conflicts, then the system could improve its performance. Such estimation of transaction conflict, however, is non-trivial for several reasons. First, conflicts occur under complex conditions that are far removed in time from the scheduling decision. Second, transactions must be represented in a compact and efficient manner to allow for fast conflict detection. Third, given some evidence of potential conflict, the DBMS must schedule transactions in such a way that minimizes this conflict. In this paper, we systematically explore the design decisions for solving these problems. We then empirically measure the performance impact of different representations on standard OLTP benchmarks. Our results show that intelligent scheduling using a history increases throughput by $\sim$40\% on 20-core machine.

Figures (16)

• Figure 1: Throughput of Randomized Scheduling -- On a main-memory dbms the experiment measures the throughput of optimistic concurrency control (OCC) and two-phase locking (2PL) in an unthrottled system running TPC-C with a fixed number of warehouses and threads (one thread reserved for workload generation). Transactions are scheduled randomly into different threads.
• Figure 2: Abort Rate of Randomized Scheduling -- The abort rate running unthrottled on TPC-C with a fixed number of warehouses. As more threads are added to the system, the abort rate increases, because transaction are added randomly to the thread queues, without regard to potential conflicts.
• Figure 3: A SQL Update Statement from the TPC-C benchmark -- The variables $1, $2, and $3 are instantiated at execution time.
• Figure 4: Functional System Architecture -- The Transaction component represents an incoming transaction. The History component represents the historical model of aborted transactions. The State component represents the mapping of transaction references to queues. The Schedule component chooses the queue to place the incoming transaction. The Queues component represents the set of run queues. The DB component is a main-memory database system. The dotted lines separate conventional components from the new system.
• Figure 5: OCC Throughput of Literal and Canonical -- The throughput performance of TPC-C over OCC comparing Literal with Canonical using Count/Max/Single. Graph (a) shows Canonical can decrease the abort rate from 45% to 6%. Accordingly, as shown in Graph (b) the throughput of Canonical is close to Hard Partition and is $\sim$30% higher to Original OCC when the number of threads is 20.