Main-Memory Databases 1 / 25

Transcription

1 1 / 25

2 Motivation Hardware trends Huge main memory capacity with complex access characteristics (Caches, NUMA) Many-core CPUs SIMD support in CPUs New CPU features (HTM) Also: Graphic cards, FPGAs, low latency networking,... Database system trends Entire database fits into main memory New types of database systems New algorithms, new data structures The End of an Architectural Era. (It s Time for a Complete Rewrite). 2 / 25

3 Recap: Database Workloads Analytics Long-running Access large parts of the database Often use scans Read-only Example: Average order value per year and product group? Transaction processing Short running (Multiple) point queries + simple control flow Insert/Update/Delete/Read data Example: Increment account x by 10, decrement account y by 10 Universal DBMS used for both (but not concurrently). 3 / 25

4 OLTP Universal DBMS were optimized for 1970 s hardware Small fraction of DB in memory buffer Hide and avoid disk access at any cost Today Even enterprises can store entire DB in memory Transaction are often one-shot Transactions execute in a few ms or even µs 4 / 25

5 OLTP (2) Main sources of overhead ARIES-style logging Locking (2PL) Latching Buffer Management Useful work can be as low as 1 60 th of instructions1. Modern systems avoid this overhead (see slide 9). 1 Harizopoulos et al. OLTP Through the Looking Glass, and What We Found There 5 / 25

6 Physical Data Layout in Main Memory Lightweight: Buffer Manager removed No need for segments No need for slotted pages Store data in simple arrays. But: Row-wise or column-wise? EmpId Tuples First Joe Mary Bob Jane Last Salery Doe Jones Black Jones Column Store Row Store Logical Table EmpId First Last 10 Joe Doe 20 Mary Jones 32 Bob Black 25 Jane Jones Salery Joe Doe Mary Jane Jones / 25

7 Physical Data Layout in Main Memory (2) Row Store: Beneficial when accessing many attributes For OLTP Column Store: Excellent cache utilization Sometimes individually sorted Compression potential Vectorized processing For OLAP Hybrid Row/Column Stores possible 7 / 25

8 New Systems (Examples) OLTP-only: VoltDB/H-Store Microsoft Hekaton OLAP-only: Vectorwise MonetDB DB2 BLU Hybrid OLTP and OLAP: SAP HANA HyPer 8 / 25

9 New Systems: OLTP (Examples) Challenge: Avoid overhead Guarantee ACID Approaches: Buffer Management: Removed Logging H-Store/VoltDB: Log shipping to other nodes Hekaton: Lightweight logging (no index structures) Locking: H-Store/VoltDB: Serial execution (on private partitions) Hekaton: Optimistic MVCC Latching H-Store/VoltDB: Not necessary Hekaton: Latch-free data structures 9 / 25

10 New Systems: Hekaton Integrated in SQL Server Code Generation Only access path: Index (Hash or B(w)-Tree) Latch-Free Indexes MVCC Hash index on Name Header Links Payload Begin End Pointer Name City Amount Record format Ordered index on City John London 100 J 15 inf Jane Paris Tx75 John London Old B-tree L Tx75 Inf John London New 30 Tx75 Larry 100 Rome 170 Old Tx75 inf Larry Rome New 10 / 25

11 New Systems: OLAP Vectorwise: Vectorized Processing HyPer: Query Compilation (cf. Chapter Code Generation) 11 / 25

12 New Systems: Hybrid OLTP and OLAP Traditionally: Mixing OLTP and OLAP leads to performance decline ETL architecture 2 systems, stale data New Systems SAP HANA Split DB into read-optimized main and update-friendly delta OLAP queries read main, OLTP transactions read delta and main Periodically merge main and delta HyPer: Virtual memory snapshots 12 / 25

13 HyPer: Virtual Memory Snapshots forked OLAP-Snapshot OLTP Data OLTP Tx A B E F C D G H 13 / 25

14 HyPer: Virtual Memory Snapshots fork forked OLAP-Snapshot OLTP Data OLAP Queries OLTP Tx A B E F C D G H 13 / 25

15 HyPer: Virtual Memory Snapshots forked OLAP-Snapshot OLTP Tx OLTP Data OLAP Queries read C A B E F C D G H 13 / 25

16 HyPer: Virtual Memory Snapshots forked OLAP-Snapshot OLTP Data OLAP Queries OLTP Tx update C to C* A B E F C* D G H C D copy-on-write 13 / 25

17 HyPer: Virtual Memory Snapshots forked OLAP-Snapshot OLTP Data OLAP Queries OLTP Tx A B E F C* D G H C D read C read H 13 / 25

18 In-Memory Index Structures In-memory hash indexes Simple and fast Growing is very expensive Do not support range queries Search Trees BSTs are cache unfriendly B-Trees better (even though designed for disk) Radix-Trees ( Tries ) Support range queries Height is independent from number of entries 14 / 25

19 Radix Trees Properties: Height depends on key length, not number of entries No rebalancing All insertion orders yield same tree Keys are stored in the tree implicitely Search: Node is array of size 2 s s bits (often 8) are used as an index into the array s is a trade-off between lookup-performance and memory consuption Radix Tree Adaptive Radix Tree 15 / 25

20 Adaptive Radix Trees Four node types: Node4: 4 keys and 4 pointers at corresponding positions: key child pointer a b c d Node16: Like Node4, but with 16 keys. SIMD searchable. Node48: Full 256 keys (index offset), point to up to 48 values: child index child pointer b a c d Node256: Regular trie node, i.e. array of size 256 Additionally: Header with node type, number of entries 16 / 25

21 Exploiting HTM for OLTP Intel s Haswell introduced HTM (via cache coherency protocol) Allows to group instructions to transactions Can help to implement DB transactions, but Do not guarantee ACID by themselves Limited in size/time 100% 100% abort probability 75% 50% 25% abort probability 75% 50% 25% 0% 0 8KB 16KB 24KB 32KB transaction size 0% 10K 100K 1M 10M transaction duration in cycles (log scale) Use HTM transactions as building blocks for DB transactions 17 / 25

22 Exploiting HTM for OLTP (2) Goals: As fine-grained as 2PL, but faster As fast as serial execution, but more flexible atomic-elide-lock (lock) { account[from]-=amount; account[to]+=amount; } 18 / 25

23 Implementing DB transactions with HTM Use TSO + HTM for latching: database transaction conflict detection: read/write sets via timestamps elided lock: serial execution timestamp conflict HTM conflict HTM conflict request a new timestamp, record safe timestamp HTM transaction conflict detection: read/write sets in hardware elided lock: latch single tuple access verify/update tuple timestamps HTM transaction release timestamp, update safe timestamp... conflict detection: read/write sets in hardware elided lock: latch single tuple access verify/update tuple timestamps... Relation and index structure layout must avoid conflicts 19 / 25

24 NUMA-Aware Data Processing NUMA architectures: Nehalem EX DRAM DRAM 25.6GB/s Sandy Bridge EP DRAM DRAM 51.2GB/s socket 0 8 cores 24MB L3 socket 1 8 cores 24MB L3 12.8GB/s (bidirectional) socket 0 8 cores 20MB L3 16.0GB/s (bidirectional) socket 1 8 cores 20MB L3 socket 3 socket 2 8 cores 24MB L3 8 cores 24MB L3 socket 3 socket 2 8 cores 20MB L3 8 cores 20MB L3 DRAM DRAM DRAM DRAM Local access cheap Remote access expensive 20 / 25

25 NUMA-Aware Data Processing: Hash Join Phase 1: process T morsel-wise and store NUMA-locally Phase 2: scan NUMA-local storage area and insert pointers into HT scan next morsel Storage area of red core HT(T) global Hash Table Storage area of green core σ...(t) σ...(t) σ...(t) morsel T Insert the pointer into HT Storage area of blue core scan Storage area of blue core Storage area of green core Storage area of red core HT(T) HT(S) next morsel σ...(r) σ...(r) σ...(r) morsel R 21 / 25

26 Compaction OLTP & OLAP share the same physical data model Fast modifications vs scan performance Row store vs column store Modifications require snapshot maintenance Use more memory Congest memory bus Stall transactions 22 / 25

27 Compaction: Hot/Cold Clustering ideal reality compacted Compression is applied asynchronously to cold part: Dictionary encoding Run-length encoding Other schemes possible Compact snapshots through a mix of regular and huge pages Keeps page table small Clustered updates No huge pages need to be replicated 23 / 25

28 Compaction: Hot/Cold Clustering Cooling - Hot & cold items mixed - Uncompressed - Small memory pages Frozen - Cold & compressed data - Huge memory pages - Rarely accessed by OLTP - Immutable: Deleted and updated items are marked "invalid" and copied to Hot Column Hot - Working Set (hot data) - Uncompressed - Small memory pages Small memory page Cold - Cold data items only - Not compressed yet "Invalid frozen items" data structure Huge memory page 24 / 25

29 Compaction: Hot/Cold Clustering How to detect temperature without causing overhead? 1. Software: LRU lists, counters 2. Hardware: mprotect 3. Hardware: dirty and young flags / 25