Improving High Contention OLTP Performance via Transaction Scheduling Guna Prasaad, Alvin Cheung, Dan Suciu University of Washington {guna, akcheung, suciu}@cs.washington.edu ABSTRACT Validation-based protocols [5, 26] are known to be well- Research in transaction processing has made significant suited for workloads with low data contention or conflicts, i.e., progress in improving the performance of multi-core in- when data items are being accessed by transactions concur- memory transactional systems. However, the focus has mainly rently, with at least one access being a write. Since conflicting been on low-contention workloads. Modern transactional accesses are rare, it is unlikely that the value of a data item systems perform poorly on workloads with transactions ac- is updated by another transaction during its execution, and cessing a few highly contended data items. We observe that hence validation mostly succeeds. On the other hand, for most transactional workloads, including those with high workloads where data contention is high, locking-based con- contention, can be divided into clusters of data conflict-free currency control protocols are generally preferred as they transactions and a small set of residuals. pessimistically block other transactions that require access In this paper, we introduce a new concurrency control to the same data item instead of incurring the overhead of protocol called Strife that leverages the above observation. repeatedly aborting and restarting the transaction like in Strife executes transactions in batches, where each batch is OCC. When the workload is known to be partitionable, parti- partitioned into clusters of conflict-free transactions and a tioned concurrency control [12] is preferred as it eliminates small set of residual transactions. The conflict-free clusters the lock acquisition and release overhead for individual data are executed in parallel without any concurrency control, fol- items by replacing it with a single partition lock. lowed by executing the residual cluster either serially or with Recent empirical studies [30] have revealed that even 2PL- concurrency control. We present a low-overhead algorithm based protocols incur a heavy overhead in processing highly that partitions a batch of transactions into clusters that do contended workloads due to lock thrashing (for ordered lock not have cross-cluster conflicts and a small residual cluster. acquisition), high abort rates (for no-wait and wait-die proto- We evaluate Strife against the opportunistic concurrency cols) or expensive deadlock-detection. Our main proposal in control protocl and several variants of two-phase locking, this paper is to eliminate concurrency control-induced over- where the latter is known to perform better than other con- heads by intelligently scheduling these highly-contended currency protocols under high contention, and show that transactions on cores such that the execution is serializable Strife can improve transactional throughput by up to 2×. even without any concurrency control. In this paper, we propose a new transaction processing 1 INTRODUCTION scheme called Strife that exploits data contention to im- prove performance in multi-core OLTP systems under high Online Transaction Processing (OLTP) Systems rely on the contention. The key insight behind Strife is to recognize concurrency control protocol to ensure serializability of arXiv:1810.01997v1 [cs.DB] 3 Oct 2018 that most transactional workloads, even those with high data transactions executed concurrently. When two transactions contention, can be partitioned into two portions: multiple executing in parallel try to access the same data item (e.g., a clusters of transactions, where there are no data conflicts be- tuple, index entry, table, etc.), concurrency control protocol tween any two clusters; and some residuals – those that have coordinates their accesses such that the final result is still se- data conflicts with atleast two other transactions belonging rializable. Different protocols achieve this in different ways. to different clusters. Locking-based protocols such as two-phase locking (2PL), As an example (to be elaborated in Section 2), a workload associate a lock with each data item and a transaction must that consists of TPC-C new order transactions can be divided acquire all locks (either in shared or exclusive mode) for into two portions: each set of transactions that orders from data items it accesses before releasing any. Validation-based the same warehouse constitutes a cluster, while those that protocols such as optimistic concurrency control(OCC) [14], order from multiple warehouses constitute the residuals. optimistically execute a transaction with potentially stale or dirty (i.e. uncommitted) data and validate for serializability before commit. Since transactions in different clusters access disjoint sets initial seed clusters, we then allocate the remaining trans- of data items, they can be executed in parallel by assign- actions into the clusters. The resulting clusters are merged ing each cluster to a different core; each core can execute based on their sizes, and any leftover transactions are col- a given cluster without any concurrency control, and all of lected as the residuals. The final clusters are then stored in the executed transactions are guaranteed to commit (unless a worklist, with the cores executing them in parallel before explicitly aborted). The residuals, on the other hand, can proceeding to execute the residuals afterwards. Our proto- be executed serially either on a single core, again without type implementation has shown that the Strife protocol any concurrency control, or across multiple cores with con- can improve transaction throughput by up to 2×, as com- currency control applied. Our protocol aims to capture the pared to traditional protocols such as two-phase locking for “best of both worlds”: partition the workload to identify as high-contention workloads. many clusters as possible as they can be executed without In summary, we make the following contributions: the overhead of running any concurrency control protocols, • We propose a novel execution scheme for high contention and minimize the number of residual transactions. workloads that is based on partitioning a batch of trans- The idea of transaction partitioning is similar to parti- actions into many conflict-free and a residual cluster. We tioned databases [12], where data items are split across dif- use this clustering towards executing most transactions in ferent machines or cores to avoid simultaneous access of the batch without any form of concurrency control except the same data items from multiple transactions. However, a few in the residual cluster. data partitioning needs to be done statically prior to exe- • We design a new algorithm for transaction partitioning cuting any transactions, and migrating data across different based on their access patterns. Our algorithm uses a combi- machines during transaction execution is expensive. Strife nation of sampling techniques and parallel data structures instead partitions transactions rather than data, and treats to ensure effiency. each batch of transaction as an opportunity to repartition, • We have implemented a prototype of the Strife concur- based on the access patterns that are inherent in the batch. rency control protocol, and evaluated using two popular Furthermore, since data access is a property that can transaction benchmarks: TPC-C [3] and YCSB [2]. The ex- change over different workloads, Strife is inspired by de- periments show that Strife can substantially improve terministic database systems [25] and executes transactions the performance of transactional systems under high- in batches. More precisely, Strife collects transactions into contention by partitioning the workloads into clusters batches; partitions the transactions into conflict-free clus- and residuals. ters and residuals; and executes them as described above. The rest of this paper is organized as follows: We first The same process repeats with a new batch of transactions, provide an overview of Strife in Section 2. Then in Section 3 where they are partitioned before execution. we discuss our partitioning algorithm in detail. We present Implementing Strife raises a number of challenges. Clearly, our evaluation of Strife in Section 4, followed by discussion a naive partitioning that classifies all transactions as resid- of related work in Section 6. uals would fulfill the description above, although doing so will simply reduce to standard concurrency control-based execution and not incur any performance benefit. On the other hand, if the residual clusters are forced to be small, 2 OVERVIEW then number of conflict-free clusters produced might be In Strife, transactions are scheduled on cores based on their lesser. As such, we identify the following desiderata for our data-access pattern. Strife collects and executes transac- partitioning algorithm: tions in batches, and assumes that read-write set of a transac- • Minimize the number of residuals. tion can be obtained statically. In scenarios where that is not • Maximize the number and size of conflict-free clusters. possible, one can use a two-stage execution strategy similar • Minimize the amount of time required to partition the to deterministic databases [25]: first dynamically obtaining transactions; time spent on partitioning takes away perfor- the complete read-write set using a reconnaissance query, mance gain from executing without