Leveraging Lock Contention to Improve Transaction Applications. University of Washington

Transcription

1 Leveraging Lock Contention to Improve Transaction Applications Cong Yan Alvin Cheung University of Washington 1

2 Background Database transactions Airline ticket reservation, banking, online shopping... 2

3 Background Database transactions Airline ticket reservation, banking, online shopping... 3

4 Background Database transactions Time Parallelism under high data contention? atomicity and consistency Concurrency protocols: 4

5 Two-phase Locking Example transaction: online shopping Alice(A) and Cong(C) buying Echo at the same time update(alice.bal) select(cong) update(cong.bal) 5

6 Two-phase Locking Example transaction: online shopping Alice(A) and Cong(C) buying Echo at the same time update(alice.bal) select(cong) update(cong.bal) 6

7 Two-phase Locking Execution time 7

8 Two-phase Locking Execution time 8

9 Two-phase Locking Execution time (Waiting for lock) 9

10 Two-phase Locking Execution time (Waiting for lock) update(alice.bal) 10

11 Two-phase Locking Execution time (Waiting for lock) update(alice.bal) 11

12 Two-phase Locking Execution time (Waiting for lock) update(alice.bal) 12

13 Two-phase Locking Execution time (Waiting for lock) update(alice.bal) 13

14 Two-phase Locking Execution time (Waiting for lock) update(alice.bal) select(cong) 14

15 Two-phase Locking Execution time (Waiting for lock) update(alice.bal) select(cong) update(cong.bal) 15

16 Two-phase Locking Problem: serialization of all transactions Changing the order of queries within transactions shortens lock waiting time Other concurrency control protocols: OCC, MVCC 2PL is more efficient under high data contention(*) *: Staring into the abyss, An Evaluation of Concurrency Control with One-thousand Cores, VLDB-14 16

17 Shortening Lock Waiting Execution time (Waiting for lock) update(alice.bal) select(cong) update(cong.bal) 17

18 Shortening Lock Waiting Execution time (Waiting for lock) select(cong) update(alice.bal) select(cong) update(cong.bal) 18

19 Shortening Lock Waiting Execution time (Waiting for lock) update(alice.bal) select(cong) update(alice.bal) select(cong) update(cong.bal) 19

20 Shortening Lock Waiting Execution time (Waiting for lock) update(alice.bal) select(cong) update(cong.bal) update(alice.bal) select(cong) update(cong.bal) 20

21 Shortening Lock Waiting Execution time (Waiting for lock) update(alice.bal) select(cong) update(cong.bal) update(alice.bal) select(cong) update(cong.bal) 21

22 Shortening Lock Waiting Execution time (Waiting for lock) update(alice.bal) select(cong) update(cong.bal) update(alice.bal) (Waiting for lock) select(cong) update(cong.bal) 22

23 Shortening Lock Waiting Execution time (Waiting for lock) update(alice.bal) select(cong) update(cong.bal) update(alice.bal) (Waiting for lock) select(cong) update(cong.bal) 23

24 Shortening Lock Waiting 2x! More threads... 24

25 Shortening Lock Waiting 2x! # Shorter latency # Higher throughput More threads... 25

26 Manually reordering queries is hard QURO: a query-aware compiler Automatically reorders queries in transactions based on data contention Preserves original program semantics 26

27 QURO Input: C++ transaction code with embedded SQL queries Profile the application Analyze application code Reorder queries Output: C++ code with reordered SQL queries 27

28 QURO Profile the applications Know which queries are likely to access contentious data Calculate the variance of running time for each query 28

29 QURO Analyze application code Reordering preserves program semantics Data dependency among program variables 1. v1 = select( table1 ); 2. v2 = select( table2, v1); 3. update( table1, input); Statement 1 should appear before statement 2 Database constraints (same table, view, foreign key...) 1. v1 = select( table1 ); 2. v2 = select( table2, v1); 3. update( table1, input); Statement 1 should appear before statement 3 29

30 QURO Goal: contentious queries appear as late as possible in transactions Constraint: data dependencies & database constraints 30

31 QURO Goal: contentious queries appear as late as possible in transactions Constraint: data dependencies & database constraints Optimization problem! 31

32 QURO Goal: contentious queries appear as late as possible in transactions Constraint: data dependencies & database constraints Optimization problem! Formalize into ILP Optimizations: reordering long transactions within seconds 32

33 Evaluation Experiment overview: Benchmarks: TPC-C, TPC-E Throughput: original Vs. reordered implementation (by QURO) Increasing data contention smaller data size more threads 33

34 Evaluation Benchmark: TPC-C payment transaction contention changing data size scaling to more threads contention latency: -83% latency: -70% 34

35 Evaluation Benchmark: TPC-E trade update transaction contention changing data size scaling to more threads contention latency: -75% latency: -66% 35

36 Experiments Mix of different transactions TPC-C standard mix: 5 types of transactions 36

37 Experiments More complicated transactions TPC-E trade order and result Each >500 lines of code, >20 queries, complicated logic 37

38 38

39 39

40 Better black friday! 40

41 Conclusion The order of query has large impact on transaction performance. QURO leverages information about query contention, and automatically reorders the queries. Reordered code generated by QURO can improve throughput up to 6.53x, and can be applied to a wide range of applications. We are in the process of releasing code (congy@cs.washington.edu). 41