Contention-Aware Lock Scheduling for Transactional Databases
•
0 likes•132 views
Lock managers are among the most well-studied components in concurrency control and transactional systems. However, one question seems to have been generally overlooked: “when there are multiple lock requests on the same object, which one(s) should be granted first?” Nearly all existing systems rely on a FIFO (first in, first out) strategy to decide which transaction(s) to grant the lock to. However, in this paper, we show that the choice of lock scheduling has significant ramifications on the overall performance of a transactional system. Despite the large body of research on job scheduling outside the database context, lock scheduling presents subtle but challenging requirements that render existing results on scheduling inapt for a transactional database. By carefully studying this prob- lem, we present the concept of contention-aware scheduling, show the hardness of the problem, and propose novel lock scheduling algorithms (LDSF and bLDSF), which guarantee a constant factor approximation of the best scheduling. We conduct extensive experiments using a popular database on both TPC-C and a microbenchmark. Compared to FIFO— the default scheduler in most database systems—our bLDSF algorithm yields up to 300x speedup in overall transaction latency. On the other hand, our LDSF algorithm, which is simpler and achieves comparable performance to bLDSF, has already been adopted by open-source community, and chosen as default scheduling strategy in MySQL 8.0.3
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Contention-Aware Lock Scheduling for Transactional Databases
- 1. CONTENTION-AWARE LOCK SCHEDULING FOR TRANSACTIONAL DATABASES NIMA GHAEDSHARAFI - 960091762 1
- 2. LOCK MANAGERS ARE ONE OF THE MOST WELL-STUDIED! 2
- 3. BUT ONE QUESTION GOT LESS ATTENTION! 3
- 4. WHAT WOULD HAPPENED IF MULTIPLE TRANSACTIONS REQUEST AN OBJET? MOST MAJOR DATABASES USE FIFO STRATEGY! BUT WHY? 4
- 5. CONTENTION AWARE ALGORITHM COULD HELP UP TO 300X SPEEDUP IN OVERALL TRANSACTION LATENCY 5
- 6. CAN REALTIME DATABASE ALGORITHMS BE USED? 6
- 7. CAN REALTIME DATABASE ALGORITHMS BE USED? SORRY, NO! 7
- 8. CAN REALTIME DATABASE ALGORITHMS BE USED? SORRY, NO! WHY? 8
- 9. CAN REALTIME DATABASE ALGORITHMS BE USED? SORRY, NO! WHY? GOALS ARE DIFFERENT! 9
- 10. LOCK SCHEDULING IS UNIQUELY CHALLENGING! 10
- 15. HOW TO BE AWARE OF CONTENTION? WE NEED INSIGHT! 15
- 16. DEPENDENCY GRAPH GIVES US INSIGHT 16
- 18. AN EDGE-LABELED GRAPH DENOTED BY G = (V,E,L) 18
- 19. AN EDGE-LABELED GRAPH DENOTED BY G = (V,E,L) V IS UNION OF TRANSACTIONS AND OBJECTS 19
- 20. AN EDGE-LABELED GRAPH DENOTED BY G = (V,E,L) V IS UNION OF TRANSACTIONS AND OBJECTS E IS UNION OF TxO and OxT 20
- 21. WHEN DO WE HAVE AN EDGE? 21
- 22. (O, T) MEANS T HOLDS THE LOCK WHEN DO WE HAVE AN EDGE? 22
- 23. (O, T) MEANS T HOLDS THE LOCK (T, O) MEANS T IS WAITING FOR A LOCK WHEN DO WE HAVE AN EDGE? 23
- 25. LABELS ARE S FOR SHARED LOCK X FOR EXCLUSIVE LOCK 25
- 26. WHAT DOES EACH LABEL MEAN? 26
- 27. WHAT DOES EACH LABEL MEAN? L(O, T) = S MEANS T HOLDS A SHARED LOCK 27
- 28. WHAT DOES EACH LABEL MEAN? L(O, T) = S MEANS T HOLDS A SHARED LOCK L(T, O) = S MEANS T IS WAITING FOR A SHARED LOCK 28
- 29. WHAT DOES EACH LABEL MEAN? L(O, T) = S MEANS T HOLDS A SHARED LOCK L(T, O) = S MEANS T IS WAITING FOR A SHARED LOCK L(O, T) = S MEANS T HOLDS AN EXCLUSIVE LOCK 29
- 30. WHAT DOES EACH LABEL MEAN? L(O, T) = S MEANS T HOLDS A SHARED LOCK L(T, O) = S MEANS T IS WAITING FOR A SHARED LOCK L(O, T) = S MEANS T HOLDS AN EXCLUSIVE LOCK L(T, O) = X MEANS T IS WAITING FOR AN EXCLUSIVE LOCK 30
- 31. DEPENDENCY GRAPH IS A DAG ON NO DEADLOCK LET’S ASSUME DEADLOCKS ARE RARE AND ARE HANDLED BY AN EXTERNAL PROCESS. 31
- 33. SIMPLY, IT DECIDES TO GRANT LOCK TO WHICH TRANSACTION 33
- 34. WHEN DOES IT DECIDE? 34
- 35. WHEN DOES IT DECIDE? WITHOUT NO DOUBT, WHEN A TRANSACTION REQUESTS A LOCK! 35
- 36. WHEN DOES IT DECIDE? WITHOUT NO DOUBT, WHEN A TRANSACTION REQUESTS A LOCK! IT SHOULD ALSO GRANT LOCK TO A TRANSACTION WHEN A LOCK IS RELEASED! 36
- 37. WHAT’S A LOCK SCHEDULER GOALS? 37
- 38. WHAT’S A LOCK SCHEDULER GOALS?ITS ONLY GOAL IS MINIMIZING THE LATENCY! 38
- 40. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! 40
- 41. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! (BECAUSE OF ITS DECISIONS!) 41
- 42. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! (BECAUSE OF ITS DECISIONS!) AREQ AREL 42
- 43. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! (BECAUSE OF ITS DECISIONS!) AREQ AREL ON EACH REQUEST 43
- 44. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! (BECAUSE OF ITS DECISIONS!) AREQ AREL ON EACH REQUEST ON EACH RELEASE 44
- 45. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! (BECAUSE OF ITS DECISIONS!) AREQ AREL ON EACH REQUEST ON EACH RELEASE SIMPLE 45
- 46. TO MINIMIZE THE LATENCY IT NEEDS TWO FUNCTIONS! (BECAUSE OF ITS DECISIONS!) AREQ AREL ON EACH REQUEST ON EACH RELEASE SIMPLE NP-HARD! 46
- 47. WHY AREL IS NP-HARD? 47
- 48. WHY AREL IS NP-HARD? IT’S NATURAL! 48
- 49. WHY AREL IS NP-HARD? IT’S NATURAL! BECAUSE THE DEPENDENCY GRAPH IS NOT A TREE! 49
- 50. WHY AREL IS NP-HARD? IT’S NATURAL! BECAUSE THE DEPENDENCY GRAPH IS NOT A TREE! TREE? 50
- 51. WHY AREL IS NP-HARD? IT’S NATURAL! BECAUSE THE DEPENDENCY GRAPH IS NOT A TREE! TREE? WHILE SHARED LOCK EXISTS, GRAPH IS A DAG! 51
- 52. CAPTURING CONTENTION WE DEFINE CONTENTION-AWARE SCHEDULING AS ANY ALGORITHM THAT PRIORITIZES TRANSACTIONS BASED ON THEIR IMPACT ON THE OVERALL CONTENTION OF THE SYSTEM 52
- 54. CONTENTION CRITERION NUMBER OF LOCKS HELD 54
- 55. CONTENTION CRITERION NUMBER OF LOCKS HELD MOST LOCKS FIRST (MLF) 55
- 56. CONTENTION CRITERION NUMBER OF LOCKS HELD NUMBER OF LOCKS THAT BLOCK OTHER TRANSACTIONS MOST LOCKS FIRST (MLF) 56
- 57. CONTENTION CRITERION NUMBER OF LOCKS HELD NUMBER OF LOCKS THAT BLOCK OTHER TRANSACTIONS MOST LOCKS FIRST (MLF) MOST BLOCKING LOCKS FIRST (MBLF) 57
- 58. CONTENTION CRITERION NUMBER OF LOCKS HELD NUMBER OF LOCKS THAT BLOCK OTHER TRANSACTIONS DEPTH OF THE DEPENDENCY SUBGRAPH MOST LOCKS FIRST (MLF) MOST BLOCKING LOCKS FIRST (MBLF) 58
- 59. CONTENTION CRITERION NUMBER OF LOCKS HELD NUMBER OF LOCKS THAT BLOCK OTHER TRANSACTIONS DEPTH OF THE DEPENDENCY SUBGRAPH MOST LOCKS FIRST (MLF) MOST BLOCKING LOCKS FIRST (MBLF) DEEPEST DEPENDENCY FIRST (DDF) 59
- 60. LARGEST DEPENDENCY SET FIRST PROVIDES FORMAL GUARANTEES ON THE EXPECTED MEAN LATENCY. 60
- 61. WHAT TRANSACTION IS DEPENDENT? CONSIDER TWO TRANSACTIONS T1 AND T2 IN THE SYSTEM. IF THERE IS A PATH FROM T1TO T2 IN THE DEPENDENCY GRAPH, WE SAY THAT T1 IS DEPENDENT ON T2 61
- 62. LARGEST DEPENDENCY SET FIRST ALGORITHM 62
- 63. IF THE ONLY LOCKING MODE IS EXCLUSIVE, LARGEST DEPENDENCY SET FIRST ALGORITHM WOULD BE OPTIMAL! 63
- 65. LDSF IMPLEMENTATION ISSUE IT NEEDS SIZE OF THE DEPENDENCY SET! 65
- 67. LET’S TAKE A LOOK AT CALCULATION 67
- 68. LET’S TAKE A LOOK AT CALCULATION SEARCHING DOWN THE REVERSE EDGES IN THE DEPENDENCY GRAPH! 68
- 69. LET’S TAKE A LOOK AT CALCULATION SEARCHING DOWN THE REVERSE EDGES IN THE DEPENDENCY GRAPH! WHEN? 69
- 70. LET’S TAKE A LOOK AT CALCULATION SEARCHING DOWN THE REVERSE EDGES IN THE DEPENDENCY GRAPH! WHEN? WHENEVER A SCHEDULING DECISION IS TO BE MADE 70
- 71. LET’S TAKE A LOOK AT CALCULATION SEARCHING DOWN THE REVERSE EDGES IN THE DEPENDENCY GRAPH! WHEN? WHENEVER A SCHEDULING DECISION IS TO BE MADE 😒 71
- 72. LET’S TAKE A LOOK AT CALCULATION SEARCHING DOWN THE REVERSE EDGES IN THE DEPENDENCY GRAPH! WHEN? WHENEVER A SCHEDULING DECISION IS TO BE MADE 😒 IN THE WORSE CASE, SIZING OF A SINGLE TRANSACTION TAKES O(|E|+|V|) TIME. 72
- 73. LET’S TAKE A LOOK AT CALCULATION SEARCHING DOWN THE REVERSE EDGES IN THE DEPENDENCY GRAPH! WHEN? WHENEVER A SCHEDULING DECISION IS TO BE MADE 😒 IN THE WORSE CASE, SIZING OF A SINGLE TRANSACTION TAKES O(|E|+|V|) TIME. IT’S DAMN SLOW! 73
- 74. OK, STORING SHOULD TACKLE! 74
- 75. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM 75
- 76. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM HOW MUCH ROOM DO YOU NEED? 🤔 76
- 77. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM HOW MUCH ROOM DO YOU NEED? 🤔 STORING THE DEPENDENCY SET REQUIRES O(V) SPACE 77
- 78. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM HOW MUCH ROOM DO YOU NEED? 🤔 STORING THE DEPENDENCY SET REQUIRES O(V) SPACE HMM, SOUNDS FEASIBLE! 78
- 79. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM HOW MUCH ROOM DO YOU NEED? 🤔 UPDATE? WHEN SHOULD BE DONE? STORING THE DEPENDENCY SET REQUIRES O(V) SPACE HMM, SOUNDS FEASIBLE! 79
- 80. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM EACH TIME ANY TRANSACTION IS BLOCKED OR A LOCK IS GRANTED HOW MUCH ROOM DO YOU NEED? 🤔 UPDATE? WHEN SHOULD BE DONE? STORING THE DEPENDENCY SET REQUIRES O(V) SPACE HMM, SOUNDS FEASIBLE! 80
- 81. OK, STORING SHOULD TACKLE! STORING THE DEPENDENCY SETS FOR ALL TRANSACTIONS AND UPDATING THEM EACH TIME ANY TRANSACTION IS BLOCKED OR A LOCK IS GRANTED HOW MUCH ROOM DO YOU NEED? 🤔 UPDATE? WHEN SHOULD BE DONE? NO WAY 😞 STORING THE DEPENDENCY SET REQUIRES O(V) SPACE HMM, SOUNDS FEASIBLE! 81
- 84. CALCULATE OR STORE? APPROXIMATE!DESPITE USING APPROXIMATIONS IN THE IMPLEMENTATION, LDFS REMAIN QUITE EFFECTIVE IN PRACTICE 84
- 85. ON THE BATTLEFIELD THE LDSF ALGORITHM IS IMPLEMENTED INTO MYSQL VERSION 8+ 85
- 86. IN A NUTSHELL 86
- 87. IN A NUTSHELL BY RESOLVING CONTENTION MUCH MORE EFFECTIVELY THAN FIFO AND VATS, LDSF IMPROVES THROUGHPUT BY UP TO 6.5X (BY 4.5X ON AVERAGE) OVER FIFO, AND BY UP TO 2X (1.5X ON AVERAGE) OVER VATS 87
- 88. IN A NUTSHELL BY RESOLVING CONTENTION MUCH MORE EFFECTIVELY THAN FIFO AND VATS, LDSF IMPROVES THROUGHPUT BY UP TO 6.5X (BY 4.5X ON AVERAGE) OVER FIFO, AND BY UP TO 2X (1.5X ON AVERAGE) OVER VATS LDSF CAN REDUCE MEAN TRANSACTION LATENCIES BY UP TO 300X AND 80X (30X AND 3.5X, ON AVERAGE) COMPARED TO FIFO AND VATS, RESPECTIVELY. IT ALSO REDUCES THE 99TH PERCENTILE LATENCY BY UP TO 190X AND 16X, COMPARED TO FIFO AND VATS, RESPECTIVELY 88
- 89. IN A NUTSHELL BY RESOLVING CONTENTION MUCH MORE EFFECTIVELY THAN FIFO AND VATS, LDSF IMPROVES THROUGHPUT BY UP TO 6.5X (BY 4.5X ON AVERAGE) OVER FIFO, AND BY UP TO 2X (1.5X ON AVERAGE) OVER VATS LDSF CAN REDUCE MEAN TRANSACTION LATENCIES BY UP TO 300X AND 80X (30X AND 3.5X, ON AVERAGE) COMPARED TO FIFO AND VATS, RESPECTIVELY. IT ALSO REDUCES THE 99TH PERCENTILE LATENCY BY UP TO 190X AND 16X, COMPARED TO FIFO AND VATS, RESPECTIVELY LDSF OUTPERFORMS VARIOUS HEURISTICS BY 2.5X IN TERMS OF THROUGHPUT, AND BY UP TO 100X (8X ON AVG.) IN TERMS OF TRANSACTION LATENCY. 89
- 90. IN A NUTSHELL BY RESOLVING CONTENTION MUCH MORE EFFECTIVELY THAN FIFO AND VATS, LDSF IMPROVES THROUGHPUT BY UP TO 6.5X (BY 4.5X ON AVERAGE) OVER FIFO, AND BY UP TO 2X (1.5X ON AVERAGE) OVER VATS LDSF CAN REDUCE MEAN TRANSACTION LATENCIES BY UP TO 300X AND 80X (30X AND 3.5X, ON AVERAGE) COMPARED TO FIFO AND VATS, RESPECTIVELY. IT ALSO REDUCES THE 99TH PERCENTILE LATENCY BY UP TO 190X AND 16X, COMPARED TO FIFO AND VATS, RESPECTIVELY LDSF OUTPERFORMS VARIOUS HEURISTICS BY 2.5X IN TERMS OF THROUGHPUT, AND BY UP TO 100X (8X ON AVG.) IN TERMS OF TRANSACTION LATENCY. THE ALGORITHMS REDUCE QUEUE LENGTH BY REDUCING CONTENTION, AND THUS INCUR MUCH LESS OVERHEAD THAN FIFO. HOWEVER, THEIR OVERHEAD IS LARGER THAN VATS 90