Main-Memory Database Management Systems

Transcription

1 Main-Memory Database Management Systems David Broneske Otto-von-Guericke University Magdeburg Summer Term 2018

2 Credits Parts of this lecture are based on content by Jens Teubner from TU Dortmund and Sebastian Breß from TU Berlin and Sebastian Dorok. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

3 We will talk about Computer and Database Systems Architecture Cache Awareness Processing Models Storage Models David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

4 Computer and Database Systems Architecture The Past and the Present David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

5 The Past Data taken from [Hennessy and Patterson, 1996] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

6 The Past - Database Systems Main-memory capacity is limited to several megabytes Only a small fraction of the database fits in main memory David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

7 The Past - Database Systems Main-memory capacity is limited to several megabytes Only a small fraction of the database fits in main memory And disk storage is huge, Traditional database systems use disk as primary storage David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

8 The Past - Database Systems Main-memory capacity is limited to several megabytes Only a small fraction of the database fits in main memory And disk storage is huge, Traditional database systems use disk as primary storage But disk latency is high Parallel query processing to hide disk latencies Choose proper buffer replacement strategy to reduce I/O Architectural properties inherited from system R, the first real relational DBMS From the 1970 s... David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

9 Database System Applications/ Users Query Database Management System Query parser/ optimizer Query plan Execution engine Resource requests Resource manager Page commands Buffer manager Read/ write pages Storage manager Database David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

10 Overhead Breakdown of RDBMS Shore Picture taken from [Harizopoulos et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

11 The Present - Computer Architecture Data taken from [Hennessy and Patterson, 2012] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

12 The Present - Database Systems Server machines have up to thousands of gigabyte of main memory available Use main memory as primary storage for the database and remove disk access as main performance bottleneck David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

13 The Present - Database Systems Server machines have up to thousands of gigabyte of main memory available Use main memory as primary storage for the database and remove disk access as main performance bottleneck But the architecture of traditional DBMSs is designed for disk-oriented database systems 30 years of Moore s law have antiquated the disk-oriented relational architecture for OLTP applications. [Stonebraker et al., 2007] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

14 Disk-based vs. Main-Memory DBMS David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

15 Disk-based vs. Main-Memory DBMS Having the database in main memory allows us to remove buffer manager and paging Remove level of indirection Results in better performance David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

16 Overhead Breakdown of RDBMS Shore: Payment TXN of TPC-C Benchmark Picture taken from [Harizopoulos et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

17 Disk-based vs. Main-Memory DBMS Disk bottleneck is removed as database is kept in main memory Access to main memory becomes new bottleneck David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

18 The New Bottleneck: Memory Access 100,000 normalized performance 10,000 1, Processor 10 1 DRAM Memory year Data taken from [Hennessy and Patterson, 2012] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

19 The New Bottleneck: Memory Access There is an increasing gap between CPU and memory speeds. Also called the memory wall. CPUs spend much of their time waiting for memory. How can we break the memory wall and better utilize the CPU? David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

20 Memory Hierarchy CPU L1 Cache L2 Cache main memory. disk capacity bytes kilobytes megabytes gigabytes latency < 1 ns 1 ns < 10 ns ns Caches resemble the buffer manager but are controlled by hardware Be aware of the caches! David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

21 Cache Awareness David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

22 A Motivating Example (Memory Access) Task: sum up all entries in a two-dimensional array. Alternative 1: Alternative 2: for (r = 0; r < rows; r++) for (c = 0; c < cols; c++) sum += src[r * cols + c]; for (c = 0; c < cols; c++) for (r = 0; r < rows; r++) sum += src[r * cols + c]; Both alternatives touch the same data, but in different order. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

23 A Motivating Example (Memory Access) total execution time cols 100s s 20s 10s 5s 2s 1s rows s 50s 20s 10s 5s 2s 1s 10 9 David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

24 Principle of Locality Caches take advantage of the principle of locality. The hot set of data often fits into caches. 90 % execution time spent in 10 % of the code. Spatial Locality: Related data is often spatially close. Code often contains loops. Temporal Locality: Programs tend to re-use data frequently. Code may call a function repeatedly, even if it is not spatially close. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

25 CPU Cache Internals To guarantee speed, the overhead of caching must be kept reasonable. Organize cache in cache lines. Only load/evict full cache lines. Typical cache line size: 64 bytes cache line line size The organization in cache lines is consistent with the principle of... locality. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

26 CPU Cache Internals To guarantee speed, the overhead of caching must be kept reasonable. Organize cache in cache lines. Only load/evict full cache lines. Typical cache line size: 64 bytes cache line line size The organization in cache lines is consistent with the principle of (spatial) locality. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

27 Memory Access On every memory access, the CPU checks if the respective cache line is already cached. Cache Hit: Read data directly from the cache. No need to access lower-level memory. Cache Miss: Read full cache line from lower-level memory. Evict some cached block and replace it by the newly read cache line. CPU stalls until data becomes available. 1 1 Modern CPUs support out-of-order execution and several in-flight cache misses. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

28 Example: AMD Opteron Data taken from [Hennessy and Patterson, 2006] Example: AMD Opteron, 2.8 GHz, PC3200 DDR SDRAM L1 cache: separate data and instruction caches, each 64 kb, 64 B cache lines L2 cache: shared cache, 1 MB, 64 B cache lines L1 hit latency: 2 cycles ( 1 ns) L2 hit latency: 7 cycles ( 3.5 ns) L2 miss latency: cycles ( 60 ns) David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

29 Block Placement: Fully Associative Cache In a fully associative cache, a block can be loaded into any cache line Offers freedom to block replacement strategy. Does not scale to large caches 4 MB cache, line size: 64 B: ,536 cache lines. Used, e.g., for small TLB caches. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

30 Block Placement: Direct-Mapped Cache In a direct-mapped cache, a block has only one place it can appear in the cache Much simpler to implement. Easier to make fast. Increases the chance of conflicts. place block 12 in cache line 4 (4 = 12 mod 8) David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

31 Block Placement: Set-Associative Cache A compromise are set-associative caches. Group cache lines into sets. Each memory block maps to one set. Block can be placed anywhere within a set. Most processor caches today are set-associative place block 12 anywhere in set 0 (0 = 12 mod 4) David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

32 Effect of Cache Parameters cache misses (millions) direct-mapped 2-way associative 4-way associative 8-way associative Data taken from [Drepper, 2007] kb 1 MB 2 MB 4 MB 8 MB 16 MB cache size David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

33 Block Replacement When bringing in new cache lines, an existing entry has to be evicted: Least Recently Used (LRU) Evict cache line whose last access is longest ago. Least likely to be needed any time soon. First In First Out (FIFO) Behaves often similar like LRU. But easier to implement. Random Pick a random cache line to evict. Very simple to implement in hardware. Replacement has to be decided in hardware and fast. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

34 What Happens on a Write? To implement memory writes, CPU makers have two options: Write Through Data is directly written to lower-level memory (and to the cache). Writes will stall the CPU. 2 Greatly simplifies data coherency. Write Back Data is only written into the cache. A dirty flag marks modified cache lines (Uses a status field.) May reduce traffic to lower-level memory. Need to write on eviction of dirty cache lines. Modern processors usually implement write back. 2 Write buffers can be used to overcome this problem. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

35 Putting it all together To compensate for slow memory, systems use caches. Typically multiple levels of caching (memory hierarchy). Caches are organized into cache lines. Set associativity: A memory block can only go into a small number of cache lines (most caches are set-associative). Systems will benefit from locality of data and code. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

36 Performance (SPECint 2000) misses per 1000 instructions L1 Instruction Cache L2 Cache (shared) gzip vpr gcc mcf crafty parser eon perlbmk gap vortex bzip2 twolf avg benchmark program David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

37 Performance (SPECint 2000) 20. misses per 1000 instructions L1 Instruction Cache L2 Cache (shared) gzip vpr gcc mcf crafty parser eon perlbmk gap vortex bzip2 twolf avg benchmark program TPC-C David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

38 Why do DBSs show such poor cache behavior? Poor code locality: Polymorphic functions (E.g., resolve attribute types for each processed tuple individually.) TYPE tuplegetnthattribute(n) String tuplegetnthattribute(n) Int tuplegetnthattribute(n) Float tuplegetnthattribute(n)... Double tuplegetnthattribute(n) String Code... Int Code... Float Code... Double Code... Volcano iterator model (pipelining) Each tuple is passed through a query plan composed of many operators. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

39 Why do DBSs show such poor cache behavior? Poor data locality: Database systems are designed to navigate through large data volumes quickly. Navigating an index tree, e.g., by design means to randomly visit any of the (many) child nodes. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

40 Processing Models Or how to improve the instruction cache effectiveness? David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

41 Processing Models There are basically two alternative processing models that are used in modern DBMSs: Tuple-at-a-time volcano model [Graefe, 1990] Operator requests next tuple, processes it, and passes it to the next operator Operator-at-a-time bulk processing [Manegold et al., 2009] Operator consumes its input and materializes its output David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

42 Tuple-At-A-Time Processing Result Most systems implement the Volcano iterator model: Operators request tuples from their input using next (). Data is processed tuple at a time. Each operator keeps its own state. Operator 1 next () tuple Operator 2 next () tuple Operator 3 next () tuple Database David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

43 Tuple-At-A-Time Processing - Consequences Pipeline-parallelism Data processing can start although data does not fully reside in main memory Small intermediate results David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

44 Tuple-At-A-Time Processing - Consequences Pipeline-parallelism Data processing can start although data does not fully reside in main memory Small intermediate results All operators in a plan run tightly interleaved. Their combined instruction footprint may be large. Instruction cache misses. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

45 Tuple-At-A-Time Processing - Consequences Pipeline-parallelism Data processing can start although data does not fully reside in main memory Small intermediate results All operators in a plan run tightly interleaved. Their combined instruction footprint may be large. Instruction cache misses. Operators constantly call each other s functionality. Large function call overhead. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

46 Tuple-At-A-Time Processing - Consequences Pipeline-parallelism Data processing can start although data does not fully reside in main memory Small intermediate results All operators in a plan run tightly interleaved. Their combined instruction footprint may be large. Instruction cache misses. Operators constantly call each other s functionality. Large function call overhead. The combined state may be too large to fit into caches. E.g., hash tables, cursors, partial aggregates. Data cache misses. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

47 Example: TPC-H Query Q1 on MySQL SELECT l_returnflag, l_linestatus, SUM (l_quantity) AS sum_qty, SUM(l_extendedprice) AS sum_base_price, SUM(l_extendedprice*(1-l_discount)) AS sum_disc_price, SUM(l_extendedprice*(1-l_discount)*(1+l_tax)) AS sum_charge, AVG(l_quantity) AS avg_qty, AVG(l_extendedprice) AS avg_price, AVG(l_discount) AS avg_disc, COUNT(*) AS count_order FROM lineitem WHERE l_shipdate <= DATE GROUP BY l_returnflag, l_linestatus Scan query with arithmetics and a bit of aggregation. Source: MonetDB/X100: Hyper-Pipelining Query Execution. [Boncz et al., 2005] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

48 time [sec] calls instr./call IPC function name M ut fold ulint pair M 27K 0.71 ut fold binary M memcpy M Item sum sum::update field 3.0 6M row search for mysql M Item sum avg::update field M rec get bit field M row sel store mysql rec M rec get nth field M 0.69 ha print info M end update M field conv M Field float::val real M Item field::val M row sel field store in mysql M buf frame align M Item func mul::val M pthread mutex unlock M hash get nth cell M mutex test and set M rec get 1byte offs flag M rec 1 get field start offs M rec get nth field extern bit M Item func minus::val M Item func plus::val

49 Observations Only single tuple processed in each call; millions of calls. Only 10 % of the time spent on actual query task. Low instructions-per-cycle (IPC) ratio. 3 Depends on underlying hardware David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

50 Observations Only single tuple processed in each call; millions of calls. Only 10 % of the time spent on actual query task. Low instructions-per-cycle (IPC) ratio. Much time spent on field access (e.g., rec get nth field ()). Polymorphic operators Single-tuple functions hard to optimize (by compiler). Low instructions-per-cycle ratio. Vector instructions (SIMD) hardly applicable. Function call overhead (e.g., Item func plus::val ()). 38 instr. 0.8 instr. = 48 cycles vs. 3 instr. for load/add/store assembly 3 cycle 3 Depends on underlying hardware David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

51 Operator-At-A-Time Processing Result Operators consume and produce full tables. Each (sub-)result is fully materialized (in memory). No pipelining (rather a sequence of statements). Each operator runs exactly once. Operator 1 tuples Operator 2 tuples Operator 3 tuples Database David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

52 Operator-At-A-Time Processing Function call overhead is now replaced by extremely tight loops. Example: batval_int_add ( ). if (vv!= int_nil) { for (; bp < bq; bp++, bnp++) { REGISTER int bv = *bp; if (bv!= int_nil) { bv = (int) OP(bv,+,vv); } *bnp = bv; } } else {... }. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

53 Operator-At-A-Time Consequences Parallelism: Inter-operator and intra-operator David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

54 Operator-At-A-Time Consequences Parallelism: Inter-operator and intra-operator Function call overhead is now replaced by extremely tight loops that conveniently fit into instruction caches, can be optimized effectively by modern compilers loop unrolling vectorization (use of SIMD instructions) can leverage modern CPU features (hardware prefetching). David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

55 Operator-At-A-Time Consequences Parallelism: Inter-operator and intra-operator Function call overhead is now replaced by extremely tight loops that conveniently fit into instruction caches, can be optimized effectively by modern compilers loop unrolling vectorization (use of SIMD instructions) can leverage modern CPU features (hardware prefetching). Function calls are now out of the critical code path. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

56 Operator-At-A-Time Consequences Parallelism: Inter-operator and intra-operator Function call overhead is now replaced by extremely tight loops that conveniently fit into instruction caches, can be optimized effectively by modern compilers loop unrolling vectorization (use of SIMD instructions) can leverage modern CPU features (hardware prefetching). Function calls are now out of the critical code path. No per-tuple field extraction or type resolution. Operator specialization, e.g., for every possible type. Implemented using macro expansion. Possible due to column-based storage. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

57 result bandwidth size time [ms] [MB/s] MIL statement 5.9M s0 := select (l_shipdate, ).mark (); 5.9M s1 := join (s0, l_returnag); 5.9M s2 := join (s0, l_linestatus); 5.9M s3 := join (s0, l_extprice); 5.9M s4 := join (s0, l_discount); 5.9M s5 := join (s0, l_tax); 5.9M s6 := join (s0, l_quantity); 5.9M s7 := group (s1); 5.9M s8 := group (s7, s2); s9 := unique (s8.mirror ()); 5.9M r0 := [+](1.0, s5); 5.9M r1 := [-](1.0, s4); 5.9M r2 := [*](s3, r1); 5.9M r3 := [*](s12, r0); r4 := {sum}(r3, s8, s9); r5 := {sum}(r2, s8, s9); r6 := {sum}(s3, s8, s9); r7 := {sum}(s4, s8, s9); r8 := {sum}(s6, s8, s9); r9 := {count}(s7, s8, s9); 3, Source: MonetDB/X100: Hyper-Pipelining Query Execution.

58 Tuple-At-A-Time vs. Operator-At-A-Time The operator-at-a-time model is a two-edged sword: Cache-efficient with respect to code and operator state. Tight loops, optimizable code. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

59 Tuple-At-A-Time vs. Operator-At-A-Time The operator-at-a-time model is a two-edged sword: Cache-efficient with respect to code and operator state. Tight loops, optimizable code. Data won t fully fit into cache. Repeated scans will fetch data from memory over and over. Strategy falls apart when intermediate results no longer fit into main memory. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

60 Tuple-At-A-Time vs. Operator-At-A-Time The operator-at-a-time model is a two-edged sword: Cache-efficient with respect to code and operator state. Tight loops, optimizable code. Data won t fully fit into cache. Repeated scans will fetch data from memory over and over. Strategy falls apart when intermediate results no longer fit into main memory. Can we aim for the middle ground between the two extremes? tuple-at-a-time operator-at-a-time vectorized execution David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

61 Vectorized Execution Model Idea: but: Use Volcano-style iteration, for each next () call return a large number of tuples a so called vector Result Operator 1 next () vector Operator 2 next () vector Operator 3 next () vector Database David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

62 Vectorized Execution Model Idea: but: Use Volcano-style iteration, for each next () call return a large number of tuples a so called vector Choose vector size large enough to compensate for iteration overhead (function calls, instruction cache misses,... ), but small enough to not thrash data caches. Result Operator 1 next () vector Operator 2 next () vector Operator 3 next () vector Database David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

63 88 Chapter 5: Vectorized execution model Vector Size Instruction Cache Effectiveness Instructions executed 50G 20G 10G 5G 2G 1G 500M 200M 100M Q1 Q1 Q K 8K 64K 1M Vector size (tuples) Instruction-cache misses 100M 10M 1M 100K 10K Source: [Zukowski, 2009] Q1 Q1 Q1 1K K 8K 64K 1M Vector size (tuples) Figure 5.2: Impact of the vector size on the number of instructions and L1 instruction-cache misses (Athlon64) Vectorized execution quickly compensates for iteration overhead Processing unit size 1000 tuples should conveniently fit into caches. Comparing to the tuple-at-a-time and column-at-a-time models, the vectorized model provides a granularity of operation that falls between these two extremes. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

64 Comparison of Execution Models execution model tuple operator vector instr. cache utilization poor extremely good very good function calls many extremely few very few attribute access complex direct direct most time spent on interpretation processing processing CPU utilization poor good very good compiler optimizations limited applicable applicable materialization overhead very cheap expensive cheap scalability good limited good Source [Zukowski, 2009] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

65 Storage Models Or how to improve the data cache effectiveness? David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

66 Data Storage Approaches There are basically two alternative storage models that are used in modern relational DBMSs: Row-stores Column-stores David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

67 Row-stores a.k.a. row-wise storage or n-ary storage model, NSM: a 1 b 1 c 1 d 1 a 2 b 2 c 2 d 2 a 3 b 3 c 3 d 3 a 4 b 4 c 4 d 4 a 1 b 1 c 1 c 1 d 1 a 2 b 2 c 2 d 2 d 2 a 3 b 3 c 3 d 3 page 0 a 4 b 4 c 4 c 4 d 4 page 1 David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

68 Column-stores a.k.a. column-wise storage or decomposition storage model, DSM: a 1 b 1 c 1 d 1 a 2 b 2 c 2 d 2 a 3 b 3 c 3 d 3 a 4 b 4 c 4 d 4 a 1 a 2 a 3 a 3 a 4 page 0 b 1 b 2 b 3 b 3 b 4 page 1 David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

69 The effect on query processing Consider, e.g., a selection query: SELECT COUNT(*) FROM lineitem WHERE l_shipdate = " " This query typically involves a full table scan. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

70 A full table scan in a row-store In a row-store, all rows of a table are stored sequentially on a database page. tuple David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

71 A full table scan in a row-store In a row-store, all rows of a table are stored sequentially on a database page. l_shipdate tuple David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

72 A full table scan in a row-store In a row-store, all rows of a table are stored sequentially on a database page. l_shipdate tuple cache block boundaries With every access to a l_shipdate field, we load a large amount of irrelevant information into the cache. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

73 A full table scan on a column-store In a column-store, all values of one column are stored sequentially on a database page. l_shipdate(s) tuple David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

74 A full table scan on a column-store In a column-store, all values of one column are stored sequentially on a database page. l_shipdate(s) tuple cache block boundaries All data loaded into caches by a l_shipdate scan is now actually relevant for the query. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

75 Column-store advantages All data loaded into caches by a l_shipdate scan is now actually relevant for the query. Less data has to be fetched from memory. Amortize cost for fetch over more tuples. If we re really lucky, the full (l_shipdate) data might now even fit into caches. The same arguments hold, by the way, also for disk-based systems. Additional benefit: Data compression might work better. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

76 Data Compression - Motivation Reduce size of data David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

77 Data Compression - Motivation Reduce size of data Reduced costs for storage as we need less storage space to store the same amount of data More data can be stored using the same amount of storage space Better utilization of memory bandwidth David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

78 Data Compression - Requirements David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

79 Data Compression - Requirements Lossless compression otherwise we generate data errors David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

80 Data Compression - Requirements Lossless compression otherwise we generate data errors Lightweight (de-)compression otherwise (de-)compression overhead would outweigh our possible performance potentials David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

81 Data Compression - Requirements Lossless compression otherwise we generate data errors Lightweight (de-)compression otherwise (de-)compression overhead would outweigh our possible performance potentials Enable processing of compressed values no additional overhead for decompression David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

82 Classification of compression techniques General idea: Replace data by representation that needs less bits than original data David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

83 Classification of compression techniques General idea: Replace data by representation that needs less bits than original data Granularity: Attribute values, tuples, tables, pages Index structures David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

84 Classification of compression techniques General idea: Replace data by representation that needs less bits than original data Granularity: Attribute values, tuples, tables, pages Index structures Code length: Fixed code length: All values are encoded with same number of bits Variable code length: Number of bits differs (e.g., correlate number of used bits with value frequency; Huffman Encoding) David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

85 Dictionary Encoding Use a dictionary that contains data values and their surrogates Surrogate can be derived from values dictionary position Applicable to row- and column-oriented data layouts David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

86 Bit Packing Surrogate values do not have to be multiples of one byte Example: 16 distinct values can be effectively stored using 4 bit per surrogate 2 values per byte Processing of compressed values is not straight forward David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

87 Run Length Encoding Reduce size of sequences of same value Store the value and an indicator about the sequence length Applicable to column-oriented data layouts Sorting can further improve compression effectiveness David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

88 Common Value Suppression A common value is scattered across a column (e.g., null) Use a data structure that indicates whether a common value is stored at a given row index or not Yes: Common value is stored here No: Lookup value in the dictionary (using prefix sum) Applicable to column-oriented data layouts David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

89 Bit-Vector Encoding Suitable for columns that have low number of distinct values Use bit string for every column value that indicates whether the value is present at a given row index or not Length of bit string equals number of tuples Used in Bitmap-Indexes David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

90 Delta Coding Store difference to precedent value instead of the original value Applicable to column-oriented data layouts Sorting can further improve compression effectiveness David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

91 Frequency Compression Idea: Exploit data skew Principle: More frequent values are encoded using fewer bits Less frequent values are encoded using more bits Use prefix codes (e.g., Huffman Encoding) David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

92 Frequency Compression - Column Store Keep track where encoded values start and end Use fixed code length for a partition rather than unique code for every value (i.e., Huffman Encoding) Picture taken from [Raman et al., 2013] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

93 Frequency Compression - Row Store Apply frequency compression on each column and perform additional delta coding Introduces overhead for reading nth column value (2 ns per column value) Picture taken from [Raman and Swart, 2006] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

94 Frequency Partitioning Developed for IBM s BLINK project [Raman et al., 2008] Similar to frequency compression of tuples in a row-oriented data layout But, partitioning tuples regarding column values Overhead is reduced as within one partition code length is fixed David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

95 Frequency Partitioning: Principle Picture taken from [Raman et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

96 Data Compression - Summary General idea: Replace data by representation that needs less bits than original data Discussed approaches: Fixed code length: Dictionary Encoding, RLE, Common Value Suppression Variable code length: Delta Coding, Frequency Compression, Frequency Partitioning Improvements: bit packing, partitioning Benefits for main-memory DBMSs: Reduced storage requirements Better memory bandwidth utilization David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

97 Compression in Action In-memory size in MiB Compression # Table Column MonetDB SAP HANA Ratio in % 1 readid 4, , refid 4, , insert offset 4, base 1, base call quality 4, HG id , position , base grch37 9 id mapping quality reads 11 overall 19, , David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

98 Compression in Action In-memory size in MiB Compression # Table Column MonetDB SAP HANA Ratio in % 1 readid 4, , refid 4, , insert offset 4, base 1, base call quality 4, HG id , position , base grch37 9 id mapping quality reads 11 overall 19, , David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

99 Compression in Action In-memory size in MiB Compression # Table Column MonetDB SAP HANA Ratio in % 1 readid 4, , refid 4, , insert offset 4, base 1, base call quality 4, HG id , position , base grch37 9 id mapping quality reads 11 overall 19, , David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

100 Column-store trade-offs Tuple recombination can cause considerable cost. Need to perform many joins. Workload-dependent trade-off. Source: [Copeland and Khoshafian, 1985] 275 David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

101 An example: Binary Association Tables in MonetDB MonetDB makes this explicit in its data model. All tables in MonetDB have two columns ( head and tail ). NAME AGE SEX John 34 m Angelina 31 f Scott 35 m Nancy 33 f David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

102 An example: Binary Association Tables in MonetDB MonetDB makes this explicit in its data model. All tables in MonetDB have two columns ( head and tail ). oid NAME AGE SEX o 1 John 34 m o 2 Angelina 31 f o 3 Scott 35 m o 4 Nancy 33 f oid o 1 o 2 o 3 o 4 NAME John Angelina Scott Nancy oid AGE o 1 34 o 2 31 o 3 35 o 4 33 oid SEX o 1 m o 2 f o 3 m f o 4 Each column yields one binary association table (BAT). Object identifiers (oids) identify matching entries (BUNs). David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

103 An example: Binary Association Tables in MonetDB MonetDB makes this explicit in its data model. All tables in MonetDB have two columns ( head and tail ). oid NAME AGE SEX o 1 John 34 m o 2 Angelina 31 f o 3 Scott 35 m o 4 Nancy 33 f oid o 1 o 2 o 3 o 4 NAME John Angelina Scott Nancy oid AGE o 1 34 o 2 31 o 3 35 o 4 33 oid SEX o 1 m o 2 f o 3 m f o 4 Each column yields one binary association table (BAT). Object identifiers (oids) identify matching entries (BUNs). Often, oids can be implemented as virtual oids (voids). Not explicitly materialized in memory. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

104 Materialization Strategies Recall: In a column-oriented data layout each column is stored separately Consider, e.g., a selection query: SELECT l_shipdate, l_linenumber FROM lineitem WHERE l_shipdate < " " AND l_linenumber < "10000" Query accesses and returns values of two columns Materialization (tuple reconstruction) during query processing necessary David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

105 Early Materialization Reconstruct tuples as soon as possible Picture taken from [Abadi et al., 2007] SPC... Scan, Predicate, Construct David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

106 Late Materialization Postpone tuple reconstruction to the latest possible time Picture taken from [Abadi et al., 2007] DS... Data Sources David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

107 Advantages of Early and Late Materialization Early Materialization (EM): Reduces access cost if one column has to be accessed multiple times during query processing [Abadi et al., 2007] Late Materialization (LM): Reduces amount of tuples to reconstruct LM allows processing of columns as long as possible Processing of compressed data LM improves cache effectiveness [Abadi et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

108 Example: Invisible Join [Abadi et al., 2008] SELECT c.nation, s.nation, d.year, sum(lo.revenue) as revenue FROM customer AS c, lineorder AS lo, supplier AS s, dwdate AS d WHERE lo.custkey = c.custkey AND lo.suppkey = s.suppkey AND lo.orderdate = d.datekey AND c.region = ASIA AND s.region = ASIA AND d.year >= 1992 AND d.year <= 1997 GROUP BY c.nation, s.nation, d.year ORDER BY d.year asc, revenue desc; David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

109 Example: Invisible Join [Abadi et al., 2008] SELECT c.nation, s.nation, d.year, sum(lo.revenue) as revenue FROM customer AS c, lineorder AS lo, supplier AS s, dwdate AS d WHERE lo.custkey = c.custkey AND lo.suppkey = s.suppkey AND lo.orderdate = d.datekey AND c.region = ASIA AND s.region = ASIA AND d.year >= 1992 AND d.year <= 1997 GROUP BY c.nation, s.nation, d.year ORDER BY d.year asc, revenue desc; David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

110 Example: Invisible Join - Hash [Abadi et al., 2008] Picture taken from [Abadi et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

111 Example: Invisible Join [Abadi et al., 2008] SELECT c.nation, s.nation, d.year, sum(lo.revenue) as revenue FROM customer AS c, lineorder AS lo, supplier AS s, dwdate AS d WHERE lo.custkey = c.custkey AND lo.suppkey = s.suppkey AND lo.orderdate = d.datekey AND c.region = ASIA AND s.region = ASIA AND d.year >= 1992 AND d.year <= 1997 GROUP BY c.nation, s.nation, d.year ORDER BY d.year asc, revenue desc; David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

112 Example: Invisible Join - Probe [Abadi et al., 2008] Picture taken from [Abadi et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

113 Example: Invisible Join [Abadi et al., 2008] SELECT c.nation, s.nation, d.year, sum(lo.revenue) as revenue FROM customer AS c, lineorder AS lo, supplier AS s, dwdate AS d WHERE lo.custkey = c.custkey AND lo.suppkey = s.suppkey AND lo.orderdate = d.datekey AND c.region = ASIA AND s.region = ASIA AND d.year >= 1992 AND d.year <= 1997 GROUP BY c.nation, s.nation, d.year ORDER BY d.year asc, revenue desc; David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

114 Example: Invisible Join - Materialize [Abadi et al., 2008] Picture taken from [Abadi et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

115 Star-Schema-Benchmark Performance T=tuple-at-a-time processing, t=block processing I=invisible join enabled, i=disabled C=compression enabled, c=disabled L=late materialization enabled, l=disabled Figure taken from [Abadi et al., 2008] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

116 Conclusion Row-stores store complete tuples sequentially on a database page Column-stores store all values of one column sequentially on a database page Depending on the workload column-stores or row-stores are more advantageous Tuple reconstruction is overhead in column-stores Analytical workloads that process few columns at a time benefit from column-stores One data storage approach is not optimal to serve all possible workloads David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

117 Take home messages Modern hardware offers performance improvements for DB applications disk vs. main-memory access speed Rethinking the architecture of DBMSs to adapt them on changes in hardware pays off single- vs. multi-threaded OLTP engines New DBMS architectures mean that we have to solve old problems again durability and availability optimize for different things cache effectiveness David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

118 Invitation Your are invited to join our research on main-memory databases and databases on new hardware, e.g., in form of: Thesis Jobs.html Scientific Team Project: Modern Database Technologies Requirements: Motivation (Programming skills) David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

119 References I Abadi, D. J., Madden, S., and Hachem, N. (2008). Column-stores vs. row-stores: how different are they really? In SIGMOD, pages Abadi, D. J., Myers, D. S., DeWitt, D. J., and Madden, S. (2007). Materialization Strategies in a Column-Oriented DBMS. In ICDE, pages Boncz, P. A., Zukowski, M., and Nes, N. (2005). Monetdb/x100: Hyper-pipelining query execution. In CIDR, pages Copeland, G. P. and Khoshafian, S. N. (1985). A decomposition storage model. In SIGMOD, pages Drepper, U. (2007). What Every Programmer Should Know About Memory. Graefe, G. (1990). Encapsulation of Parallelism in the Volcano Query Processing System. In SIGMOD, pages David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

120 References II Harizopoulos, S., Abadi, D. J., Madden, S., and Stonebraker, M. (2008). OLTP through the looking glass, and what we found there. In SIGMOD, pages Hennessy, J. L. and Patterson, D. A. (1996). Computer Architecture: A Quantitative Approach. Morgan Kaufmann, 2 edition. Hennessy, J. L. and Patterson, D. A. (2006). Computer Architecture: A Quantitative Approach. Morgan Kaufmann, 4 edition. Hennessy, J. L. and Patterson, D. A. (2012). Computer Architecture - A Quantitative Approach. Morgan Kaufmann, 5 edition. Manegold, S., Kersten, M. L., and Boncz, P. (2009). Database Architecture Evolution: Mammals flourished long before Dinosaurs became extinct. PVLDB, 2(2): Raman, V., Attaluri, G., Barber, R., Chainani, N., Kalmuk, D., KulandaiSamy, V., Leenstra, J., Lightstone, S., Liu, S., Lohman, G. M., Malkemus, T., Mueller, R., Pandis, I., Schiefer, B., Sharpe, D., Sidle, R., Storm, A., and Zhang, L. (2013). DB2 with BLU Acceleration: So Much More Than Just a Column Store. PVLDB, 6(11): David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

121 References III Raman, V. and Swart, G. (2006). How to Wring a Table Dry: Entropy Compression of Relations and Querying of Compressed Relations. In VLDB, pages Raman, V., Swart, G., Qiao, L., Reiss, F., Dialani, V., Kossmann, D., Narang, I., and Sidle, R. (2008). Constant-Time Query Processing. In ICDE, pages Stonebraker, M., Madden, S., Abadi, D. J., Harizopoulos, S., Hachem, N., and Helland, P. (2007). The end of an architectural era: (it s time for a complete rewrite). In VLDB, pages Zukowski, M. (2009). Balancing Vectorized Query Execution with Bandwidth-Optimized Storage. PhD thesis, CWI Amsterdam. David Broneske Main-Memory Database Management Systems Last Change: April 20, /82

122 Web Resources [1] [2] [3] [4] [5] [6] [7] David Broneske Main-Memory Database Management Systems Last Change: April 20, /82