Hybrid Indexes Huanchen Zhang David G. Andersen, Andrew Pavlo, - - PowerPoint PPT Presentation

Reducing the Storage Overhead of Main-Memory OLTP Databases with

Hybrid Indexes

Huanchen Zhang

David G. Andersen, Andrew Pavlo, Michael Kaminsky, Lin Ma, Rui Shen

PARALLEL DATA LABORATORY

Carnegie Mellon University

2

3

4

Part I Initial Exploration

• f Hybrid Indexes

[SIGMOD’16]

5

You are running out of memory

6

You are running out of memory

6

Buy more

?

You are running out of memory

6

2M 4M 6M 8M 10M 20K 60K

Transactions Executed Throughput TPC-C on

• Store

7

Memory (GB)

Disk tuples In-memory tuples Indexes

4 8 Memory Limit = 5GB

8

The better way: Use memory more efficiently

9

Indexes are LARGE

Benchmark % space for index

TPC-C Voter Articles

58% 55% 34%

Hybrid Index

34% 41% 18%

10

Our Contributions [SIGMOD’16] The hybrid index architecture The Dual-Stage Transformation Applied to 4 index structures

• B+tree
• Masstree

11

• Skip List
• Adaptive Radix Tree (ART)

Performance Space

30 – 70%

2M 4M 6M 8M 10M 20K 60K

Transactions Executed Throughput (txn/s) Did we solve this problem?

TPC-C on

• Store

Stay tuned

12

How do hybrid indexes achieve memory savings ?

13

Static

dynamic stage static stage

Hybrid Index: a dual-stage architecture

14

dynamic stage static stage write merge

Inserts are batched in the dynamic stage

15

dynamic stage static stage

Reads search the stages in order

16

dynamic stage static stage read

A Bloom filter improves read performance

17

dynamic stage static stage read write merge Memory-efficient Skew-aware

18

~ ~ ~ ~ ~ ~ ~ ~

dynamic stage static stage merge

The Dual-Stage Transformation

19

dynamic stage static stage merge

The Dual-Stage Transformation

19

Compaction Reduction Compression

The Dynamic-to-Static Rules

20

Compaction Reduction Compression

The Dynamic-to-Static Rules

20

2 4 4 1 2 a b 6 8 10 3 4 c d 5 5 e f 5 6 g h 7 8 i j 9 10 k l 11 12 m n 21

2 4 4 1 2 a b 6 8 10 3 c 4 d 5 5 e f 5 g 6 h 7 i 8 j 9 k 10 l 11 m 12 n

Compaction: minimize # of memory blocks

21

1 2 3 a b c 4 5 6 d h 7 8 9 i j k 10 11 12 l m n e f g 3 6 9 21

Compaction: minimize # of memory blocks

1 2 3 a b c 4 5 6 d h 7 8 9 i j k 10 11 12 l m n e f g 3 6 9

Reduction: minimize structural overhead

22

1 2 3 a b c 4 5 6 d h 7 8 9 i j k 10 11 12 l m n e f g 3 6 9 22

Reduction: minimize structural overhead

2 4 4 1 2 a b 6 8 10 3 4 c d 5 5 e f 5 6 g h 7 8 i j 9 10 k l 11 12 m n 1 2 3 a b c 4 5 6 d h 7 8 9 i j k 10 11 12 l m n e f g 3 6 9 22

Reduction: minimize structural overhead

dynamic stage static stage merge

The merge routine is a blocking process

23

dynamic stage static stage merge

23

?

The merge routine is a blocking process

Size %

2M 4M 6M 8M 10M 20K 60K

Transactions Executed Throughput (txn/s) Did we solve this problem?

TPC-C on

• Store

B+tree

24

2M 4M 6M 8M 10M 20K 60K

Transactions Executed Throughput (txn/s)

60K 20K

Yes, we improved the DBMS’s capacity!

TPC-C on

• Store

B+tree Hybrid

24

Transactions Executed Throughput (txn/s)

20K 60K 20K 60K

Memory (GB)

2M 4M 6M 8M 10M

TPC-C on

• Store

4 4 8 8

B+tree Hybrid B+tree Hybrid Disk tuples In-memory tuples Indexes

25

Transactions Executed Throughput (txn/s)

20K 60K 20K 60K

Memory (GB)

2M 4M 6M 8M 10M

TPC-C on

• Store

4 4 8 8

B+tree Hybrid B+tree Hybrid Disk tuples In-memory tuples Indexes

25

Transactions Executed Throughput (txn/s)

20K 60K 20K 60K

Memory (GB)

2M 4M 6M 8M 10M

TPC-C on

• Store

4 4 8 8

B+tree Hybrid B+tree Hybrid Disk tuples In-memory tuples Indexes

25

Transactions Executed Throughput (txn/s)

20K 60K 20K 60K

Memory (GB)

2M 4M 6M 8M 10M

TPC-C on

• Store

4 4 8 8

B+tree Hybrid B+tree Hybrid Disk tuples In-memory tuples Indexes

25

Transactions Executed Throughput (txn/s)

20K 60K 20K 60K

Memory (GB)

2M 4M 6M 8M 10M

TPC-C on

• Store

4 4 8 8

B+tree Hybrid B+tree Hybrid Disk tuples In-memory tuples Indexes

25

Transactions Executed Throughput (txn/s)

20K 60K 20K 60K

Memory (GB)

2M 4M 6M 8M 10M

TPC-C on

• Store

4 4 8 8

B+tree Hybrid B+tree Hybrid Disk tuples In-memory tuples Indexes

25

Take Away:

Larger working set in memory Higher throughput Memory saved by indexes

Part I Recap The hybrid index architecture The Dual-Stage Transformation Applied to 4 index structures GENERAL PRACTICAL USEFUL

26

• B+tree
• Masstree
• Skip List
• Adaptive Radix Tree (ART)

Part II Concurrent hybrid indexes with non- blocking merge

27

dynamic stage static stage write merge

Building Concurrent Hybrid Index?

28

dynamic stage static stage write merge

Building Concurrent Hybrid Index?

28

29

Use concurrent data structures for dynamic-stage

dynamic stage static stage write merge

30

Static-stage is perfectly concurrent by default

dynamic stage static stage write merge

31

Challenge: efficient non-blocking merge algorithm

dynamic stage static stage write merge

Merge Algorithm Requirements Efficient

• Fast
• Bounded temporary memory use

Non-blocking

• All existing items are accessible during merge
• New items can still enter

32

Naïve Solution 1: Coarse-grained Locking

dynamic stage static stage write merge

33

Naïve Solution 1: Coarse-grained Locking

dynamic stage static stage merge write

33

The intermediate stage unblocks write traffic

static stage merge dynamic stage write

34

The intermediate stage unblocks write traffic

static stage merge dynamic stage write Intermediate stage freeze

34

The intermediate stage unblocks write traffic

freeze static stage merge dynamic stage write Intermediate stage

34

static stage merge Intermediate stage

35

How do we unblock reads during merge?

Naïve Solution 2: Full Copy-on-write

static stage merge Intermediate stage

36

Key Observation

Merged-in items in the static-stage will NOT be accessed until the intermediate-stage is deleted

Merge Incrementally!

37

Our Solution: Incremental Copy-on-write with Rapid GC

• ld

new parent

38

• ld

new parent When can we safely reclaim the garbage?

38

Our Solution: Incremental Copy-on-write with Rapid GC

• ld

new parent When can we safely reclaim the garbage?

38

Our Solution: Incremental Copy-on-write with Rapid GC

• ld

new parent When no thread still holds a reference to it!

38

Our Solution: Incremental Copy-on-write with Rapid GC

• ld

new parent When no thread still holds a reference to it!

38

Our Solution: Incremental Copy-on-write with Rapid GC

Thread-local counters

C1 C2 C3 Cn

• ld

new parent When no thread still holds a reference to it! Thread-local counters

Cmax Cmax Cmin GC Condition: Cmin > garbage tag ++Ci = MAX(Ci , Cmax) + 1

38

Our Solution: Incremental Copy-on-write with Rapid GC

C1 C2 C3 Cn

A Quick Recap of the Merge Algorithm The intermediate stage separates writes from the merge process The incremental merge algorithm with rapid GC is non-blocking and space-efficient

39

What we are building now Compact Radix Tree Non-blocking Merge

40

What we are building now Compact Radix Tree Non-blocking Merge

40

What we are building now Compact Radix Tree Non-blocking Merge

40

What we are building now Compact Radix Tree Non-blocking Merge Bwtree

40

What we are building now Compact Radix Tree Non-blocking Merge Skiplist

40

What we are building now Compact Radix Tree Non-blocking Merge Masstree

40

Part III Super-compact static-stage

41

Go “crazy” on space-efficiency

42

Succinct Data Structures

• Z + o(Z), where Z is the information-theoretic lower bound
• Still allow for efficient query operations

rank1(x) = # of 1’s up to position x select1(x) = position of the x-occurrence of 1 100011010000101…

Encoding Radix Tree

43

a $ab $lnr$a $iio$ i$n $$ 100 100010 10001 010 11 10 1000 10000100 100101010 101010 1010

a $ a b $ l n r $ a $ i i

• n

i $ $ $ $

44

Memory Savings with the New Encoding

200 400 600 800 1000

Memory (MB)

ART Our Encoding

84%

50M email keys with average length = 20 bytes

The Takeaway Message

45

Hybrid indexes can save the precious memory resources with minimum performance penalty.

1-844-88-CMUDB Toll-Free Hotline:

44

Back-up Slides

Latency (ms)

50% 99% MAX 10 50 115

Hybrid

10 52 611

B+tree

YCSB-based Microbenchmark Evaluation

Workload: insert, read/update(50/50) Key: email Value: 64-bit unsigned integer (pointer) Single thread 50M entries, 10M queries (Zipf distributed)

B+tree Masstree Skip List ART 4 8

Memory (GB) Hybrid index saves memory

Original Hybrid

30 – 70%

8M 16M

Throughput (txn/s) Hybrid index provides comparable throughput

Original Hybrid Read/Update (50/50)

4M 2M

Insert-only