Index Concurrency Control Index Concurrency Control 1 / 129 Index Concurrency Control Administrivia • Assignment 3 is due on Oct 19th @ 11:59pm • Exercise Sheeet 3 is due on Oct 19th @ 11:59pm (no late days allowed) 2 / 129 Recap Recap 3 / 129 Recap Index Data Structures • List of Data Structures: Hash Tables, B+Trees, Radix Trees • Most DBMSs automatically create an index to enforce integrity constraints. • B+Trees are the way to go for indexing data. 4 / 129 Recap Observation • We assumed that all the data structures that we have discussed so far are single-threaded. • But we need to allow multiple threads to safely access our data structures to take advantage of additional CPU cores and hide disk I/O stalls. 5 / 129 Recap Concurrency Control • A concurrency control protocol is the method that the DBMS uses to ensure "correct" results for concurrent operations on a shared object. • A protocol’s correctness criteria can vary: I Logical Correctness: Am I reading the data that I am supposed to read? I Physical Correctness: Is the internal representation of the object sound? 6 / 129 Recap Today’s Agenda • Latches Overview • Hash Table Latching • B+Tree Latching • Leaf Node Scans • Delayed Parent Updates (Blink-Tree) 7 / 129 Latches Overview Latches Overview 8 / 129 Latches Overview Locks vs. Latches • Locks I Protects the database’s logical contents from other txns. I Held for the duration of the transaction. I Need to be able to rollback changes. • Latches I Protects the critical sections of the DBMS’s internal physical data structures from other threads. I Held for the duration of the operation. I Do not need to be able to rollback changes. 9 / 129 Latches Overview Locks vs. Latches Locks Latches Separate. User transactions Threads Protect. Database Contents In-Memory Data Structures During. Entire Transactions Critical Sections Modes. Shared, Exclusive, Update, Intention Read, Write (a.k.a., Shared, Exclusive) Deadlock Detection & Resolution Avoidance . by. Waits-for, Timeout, Aborts Coding Discipline Kept in. Lock Manager Protected Data Structure Reference 10 / 129 Latches Overview Latch Modes • Read Mode I Multiple threads can read the same object at the same time. I A thread can acquire the read latch if another thread has it in read mode. • Write Mode I Only one thread can access the object. I A thread cannot acquire a write latch if another thread holds the latch in any mode. Read Write Read X X Write X X 11 / 129 Latches Overview Latch Implementations • Blocking OS Mutex • Test-and-Set Spin Latch • Reader-Writer Latch 12 / 129 Latches Overview Latch Implementations • Approach 1: Blocking OS Mutex I Simple to use I Non-scalable (about 25 ns per lock/unlock invocation) I Example: std::mutex std::mutexm; m.lock(); // Do something special... m.unlock(); 13 / 129 Latches Overview Latch Implementations • Approach 2: Test-and-Set Spin Latch (TAS) I Very efficient (single instruction to latch/unlatch) I Non-scalable, not cache friendly I Example: std::atomic<T> I Unlike OS mutex, spin latches do not suspend thread execution I Atomic operations are faster if contention between threads is sufficiently low std::atomic_flag latch; // atomic of boolean type (lock-free) while(latch.test_and_set(...)) { // Retry? Yield? Abort? } 14 / 129 Latches Overview Latch Implementations • Approach 3: Reader-Writer Latch I Allows for concurrent readers I Must manage read/write queues to avoid starvation I Can be implemented on top of spinlocks 15 / 129 Latches Overview Latch Implementations • Approach 3: Reader-Writer Latch I Allows for concurrent readers I Must manage read/write queues to avoid starvation I Can be implemented on top of spinlocks 16 / 129 Hash Table Latching Hash Table Latching 17 / 129 Hash Table Latching Hash Table Latching • Easy to support concurrent access due to the limited ways in which threads access the data structure. I All threads move in the same direction and only access a single page/slot at a time. I Deadlocks are not possible. • To resize the table, take a global latch on the entire table (i.e., in the header page). 18 / 129 Hash Table Latching Hash Table Latching • Approach 1: Page Latches I Each page has its own reader-write latch that protects its entire contents. I Threads acquire either a read or write latch before they access a page. • Approach 2: Slot Latches I Each slot has its own latch. I Can use a single mode latch to reduce meta-data and computational overhead. 19 / 129 Hash Table Latching Hash Table - Page Laches 20 / 129 Hash Table Latching Hash Table - Page Laches 21 / 129 Hash Table Latching Hash Table - Page Laches 22 / 129 Hash Table Latching Hash Table - Page Laches 23 / 129 Hash Table Latching Hash Table - Page Laches 24 / 129 Hash Table Latching Hash Table - Page Laches 25 / 129 Hash Table Latching Hash Table - Page Laches 26 / 129 Hash Table Latching Hash Table - Page Laches 27 / 129 Hash Table Latching Hash Table - Page Laches 28 / 129 Hash Table Latching Hash Table - Slot Laches 29 / 129 Hash Table Latching Hash Table - Slot Laches 30 / 129 Hash Table Latching Hash Table - Slot Laches 31 / 129 Hash Table Latching Hash Table - Slot Laches 32 / 129 Hash Table Latching Hash Table - Slot Laches 33 / 129 Hash Table Latching Hash Table - Slot Laches 34 / 129 Hash Table Latching Hash Table - Slot Laches 35 / 129 Hash Table Latching Hash Table - Slot Laches 36 / 129 B+Tree Concurrency Control B+Tree Concurrency Control 37 / 129 B+Tree Concurrency Control B+Tree Concurrency Control • We want to allow multiple threads to read and update a B+Tree at the same time. • We need to handle two types of problems: I Threads trying to modify the contents of a node at the same time. I One thread traversing the tree while another thread splits/merges nodes. 38 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 39 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 40 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 41 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 42 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 43 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 44 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 45 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 46 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 47 / 129 B+Tree Concurrency Control B+Tree Concurrency Control: Example 48 / 129 B+Tree Concurrency Control Latch Crabbing/Coupling • Protocol to allow multiple threads to access/modify B+Tree at the same time. • Basic Idea: I Get latch for parent. I Get latch for child I Release latch for parent if “safe”. • A safe node is one that will not split or merge when updated. I Not full (on insertion) I More than half-full (on deletion) 49 / 129 B+Tree Concurrency Control Latch Crabbing/Coupling • Find: Start at root and go down; repeatedly, I Acquire R latch on child I Then unlatch parent • Insert/Delete: Start at root and go down, obtaining W latches as needed. Once child is latched, check if it is safe: I If child is safe, release all latches on ancestors. 50 / 129 B+Tree Concurrency Control Example 1 - Find 38 51 / 129 B+Tree Concurrency Control Example 1 - Find 38 52 / 129 B+Tree Concurrency Control Example 1 - Find 38 53 / 129 B+Tree Concurrency Control Example 1 - Find 38 54 / 129 B+Tree Concurrency Control Example 1 - Find 38 55 / 129 B+Tree Concurrency Control Example 1 - Find 38 56 / 129 B+Tree Concurrency Control Example 1 - Find 38 57 / 129 B+Tree Concurrency Control Example 1 - Find 38 58 / 129 B+Tree Concurrency Control Example 2 - Delete 38 59 / 129 B+Tree Concurrency Control Example 2 - Delete 38 60 / 129 B+Tree Concurrency Control Example 2 - Delete 38 61 / 129 B+Tree Concurrency Control Example 2 - Delete 38 62 / 129 B+Tree Concurrency Control Example 2 - Delete 38 63 / 129 B+Tree Concurrency Control Example 2 - Delete 38 64 / 129 B+Tree Concurrency Control Example 2 - Delete 38 65 / 129 B+Tree Concurrency Control Example 2 - Delete 38 66 / 129 B+Tree Concurrency Control Example 2 - Delete 38 67 / 129 B+Tree Concurrency Control Example 3 - Insert 45 68 / 129 B+Tree Concurrency Control Example 3 - Insert 45 69 / 129 B+Tree Concurrency Control Example 3 - Insert 45 70 / 129 B+Tree Concurrency Control Example 3 - Insert 45 71 / 129 B+Tree Concurrency Control Example 3 - Insert 45 72 / 129 B+Tree Concurrency Control Example 3 - Insert 45 73 / 129 B+Tree Concurrency Control Example 4 - Insert 25 74 / 129 B+Tree Concurrency Control Example 4 - Insert 25 75 / 129 B+Tree Concurrency Control Example 4 - Insert 25 76 / 129 B+Tree Concurrency Control Example 4 - Insert 25 77 / 129 B+Tree Concurrency Control Example 4 - Insert 25 78 / 129 B+Tree Concurrency Control Example 4 - Insert 25 79 / 129 B+Tree Concurrency Control Observation • What was the first step that all the update examples did on+ theB Tree? • Taking a write latch on the root every time becomes a bottleneck with higher concurrency. • Can we do better? 80 / 129 B+Tree Concurrency Control Better Latching Algorithm • Assume that the leaf node is safe. • Use read latches and crabbing to reach it, and then verify that it is safe. • If leaf is not safe, then do previous algorithm using write latches. • Reference 81 / 129 B+Tree Concurrency Control Example 2 - Delete 38 82 / 129 B+Tree Concurrency Control Example 2 - Delete 38 83 / 129 B+Tree Concurrency Control Example 2 - Delete 38 84 / 129 B+Tree Concurrency Control Example 2 - Delete 38 85 / 129 B+Tree Concurrency Control Example 2 - Delete 38 86 / 129 B+Tree Concurrency Control Example 4 - Insert 25 87 / 129 B+Tree Concurrency Control Example 4 - Insert 25 88 / 129 B+Tree Concurrency Control Example 4 - Insert 25 89 / 129 B+Tree Concurrency Control Example 4 - Insert 25 90 / 129 B+Tree Concurrency Control Better Latching Algorithm • Find: Same as before.