High-Performance ACID Via Modular Concurrency Control
Total Page：16
File Type：pdf, Size：1020Kb
High-Performance ACID via Modular Concurrency Control Chao Xie1, Chunzhi Su1, Cody Littley1, Lorenzo Alvisi1, Manos Kapritsos2 and Yang Wang3 1The University of Texas at Austin 2Microsoft Research 3The Ohio State University Abstract: This paper describes the design, implementation, adopts the familiar abstraction offered by the ACID paradigm and evaluation of Callas, a distributed database system that and sets its sight on finding a more efficient way to implement offers to unmodified, transactional ACID applications the op- that abstraction. portunity to achieve a level of performance that can currently The key observation that motivates the architecture of only be reached by rewriting all or part of the application in a Callas is simple. While ease of programming requests that BASE/NoSQL style. The key to combining performance and ACID properties hold uniformly across all transactions, when ease of programming is to decouple the ACID abstraction— it comes to the mechanisms used to enforce these properties, which Callas offers identically for all transactions—from the uniformity can actually hinder performance: a concurrency mechanism used to support it. MCC, the new Modular ap- control mechanism that must work correctly for all possible proach to Concurrency Control at the core of Callas, makes pairs of transactions will necessarily have to make conserva- it possible to partition transactions in groups with the guar- tive assumptions, passing up opportunities for optimization. antee that, as long as the concurrency control mechanism Callas then decouples the concerns of abstraction and within each group upholds a given isolation property, that implementation: it offers ACID guarantees uniformly to all property will also hold among transactions in different groups. transactions, but uses a novel technique, modular concur- Because of their limited and specialized scope, these group- rency control (MCC), to customize the mechanism through specific mechanisms can be customized for concurrency with which these guarantees are provided. unprecedented aggressiveness. In our MySQL Cluster-based MCC makes it possible to think modularly about the en- prototype, Callas yields an 8.2x throughput gain for TPC-C forcement of any given isolation property I. It enables Callas with no programming effort. to partition transactions in separate groups, and it ensures that as long as I holds within each group, it will also hold among transactions in different groups. Separating concerns 1 Introduction frees Callas to use within each group concurrency control mechanisms optimized for that group’s transactions. Thus, This paper describes the design, implementation, and eval- Callas can find opportunities for increased concurrency where uation of Callas, a distributed database system that aims to a generic mechanism might have to settle for a conservative unlock the performance potential of the ACID transactional execution. paradigm, without sacrificing its generality and simplicity. To maximize the impact of MCC on scalability, Callas Performance is not traditionally one of ACID’s strong heuristically focuses on identifying the best grouping for suits: after all, the BASE/NoSQL movement [10, 17, 23, 26] those transactions whose high conflict rate bottlenecks the was born out of frustration with the limited scalability of application and can therefore most benefit from an aggres- traditional ACID solutions, only to become itself a source of sive concurrency control mechanism, leaving the rest in a frustration once the challenges of programming applications single, large group. Such performance-critical transactions in this new paradigm began to sink in. are typically few [33], which results in two advantages for Callas aims to move beyond the ACID/BASE dilemma. Callas. Rather than trying to draw performance from weakening the First, it permits the systematic study of the performance abstraction offered to the programmer, Callas unequivocally benefits of grouping—though we find that even a simple greedy heuristic can yield substantial returns. Second, it enables concurrency control mechanisms that, Permission to make digital or hard copies of all or part of this work for personal or because of their limited and specialized scope, can seek oppor- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation tunities for concurrency with unprecedented aggressiveness. on the first page. Copyrights for components of this work owned by others than ACM For example, Callas’ in-group mechanism uses two novel run- must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a time techniques that, by refining the static analysis approach fee. Request permissions from [email protected]. used by transaction chopping [29], create new chances for SOSP’15, October 4–7, 2015, Monterey, CA. Copyright c 2015 ACM 978-1-4503-3834-9/15/10. $15.00. concurrency. http://dx.doi.org/10.1145/2815400.2815430 Even existing mechanisms designed to boost concurrency, however, can benefit from a more limited scope. In particular, // transfer balance // sum balance (infrequent) begin transaction we find that also traditional transaction chopping, which re- begin transaction bal dest = bal dest + val return bal orig + bal dest bal orig = bal orig − val lies on the absence of certain dependency cycles among all commit transactions, becomes much more incisive when the lack of commit circular dependency must apply only to the small number of Fig. 1: A simple banking application. transactions within a group. In summary, we make the following contributions: plicity, when it comes to enforcing isolation this choice can • We propose MCC, a new, modular approach to concur- become an obstacle to performance and scalability. Whether rency control. By decoupling abstraction from mechanism, using locking or optimistic concurrency control (OCC), cur- MCC retains the simplicity of a uniform ACID API; by rent ACID databases rely on one-size-fits-all—and thus fun- separating concerns, it lets each module customize its in- damentally conservative—mechanisms to ensure isolation. ternal concurrency control mechanism to achieve greater For example, when a transaction accesses an object (e.g., concurrency without sacrificing safety. a database row), a lock-based mechanism must acquire a • We introduce Runtime Pipelining, a technique that lever- lock that is held until the end of the transaction, preventing ages execution-time information to aggressively weaken all other transactions from observing intermediate states of within a group the conservative requirements of the current that transaction. Perhaps surprisingly, given their name, OCC theory of safe transaction chopping [29] and gain, as a re- mechanisms are, in their own way, equally conservative. Al- sult, unprecedented opportunities for concurrency. The key though they allow transactions to speculatively execute in to the effectiveness of Runtime Pipelining is the flexibility parallel without acquiring locks, they do not refine the crite- offered by MCC, which makes this technique applicable ria for determining contention, but simply delay the check: if within small groups of well-suited transactions. contention is detected at commit time, they force all but one of the contending transactions to rollback. • We present the design, implementation and evaluation of By treating all transactions equally, one-size-fits-all mech- Callas, a prototype implementation of MCC within a mod- anisms cannot take advantage of workload-specific optimiza- ified MySQL Cluster distributed database. Our evaluation tions. Isolation is uniformly enforced to prevent all other of Callas suggests that MCC can deliver significant per- transactions from observing intermediate states. In some cir- formance gains to unmodified ACID applications. For ex- cumstances, however, such precautions are excessive: it is ample, we find that, for TPC-C, Callas achieves an 8.2x quite common to find transactions that can safely expose speedup over MySQL Cluster without requiring any pro- some of their intermediate states to some other transactions. gramming effort. Consider, for example, how a lock-based mechanism The rest of the paper is organized as follows. After Sec- would handle the simple banking application that uses the two tion 2 discusses why an undifferentiated concurrency control transactions defined in Figure 1: transfer balance deducts mechanism is undesirable, Section 3 introduces MCC and some amount from the bal orig account and adds it to specifies the correctness conditions that any valid instanti- bal dest; sum balance computes the total assets across the ation of MCC must meet. Section 4 and Section 5 present two accounts. the mechanisms Callas uses to ensure isolation across groups When these transactions can execute concurrently, uni- and within each group, respectively. The implementation of formly enforcing isolation requires transfer balance to keep Callas is the topic of Section 6, while Section 7 presents the the lock on bal dest until the transaction commits, to prevent results of our experimental evaluation. Section 8 discusses sum balance from computing the wrong total by observing related work, and Section 9 concludes the paper. the intermediate state where bal dest has been credited but bal orig not yet charged. Keeping the locks for so long, how-