Query Execution

13 Part II

Intro to Database Systems Andy Pavlo

15-445/15-645
Fall 2019 AP Computer Science
Carnegie Mellon University
 2

ADMINISTRIVIA

Homework #3 is due Today @ 11:59pm

Mid-Term Exam is Wed Oct 16th @ 12:00pm

Project #2 is due Sun Oct 20th @ 11:59pm

CMU 15-445/645 (Fall 2019)

 3

QUERY EXECUTION
SELECT R.id, S.cdate
We discussed last class how to FROM R JOIN S
compose operators together to ON R.id = S.id
execute a query plan. WHERE S.value > 100

We assumed that the queries execute

p R.id, S.value

with a single worker (e.g., thread).

⨝ R.id=S.id

We now need to talk about how to

execute with multiple workers…
s value>100

R S
CMU 15-445/645 (Fall 2019)
 4

W H Y C A R E A B O U T PA R A L L E L E X E C U T I O N ?

Increased performance.
→ Throughput
→ Latency

Increased responsiveness and availability.

Potentially lower total cost of ownership (TCO).

CMU 15-445/645 (Fall 2019)

 PA R A L L E L V S . D I S T R I B U T E D

Database is spread out across multiple resources

to improve different aspects of the DBMS.

Appears as a single database instance to the

application.
→ SQL query for a single-resource DBMS should generate
same result on a parallel or distributed DBMS.

CMU 15-445/645 (Fall 2019)

 PA R A L L E L V S . D I S T R I B U T E D

Parallel DBMSs:
→ Resources are physically close to each other.
→ Resources communicate with high-speed interconnect.
→ Communication is assumed to cheap and reliable.

Distributed DBMSs:
→ Resources can be far from each other.
→ Resources communicate using slow(er) interconnect.
→ Communication cost and problems cannot be ignored.

CMU 15-445/645 (Fall 2019)

 7

T O D AY ' S A G E N D A

Process Models
Execution Parallelism
I/O Parallelism

CMU 15-445/645 (Fall 2019)

 8

PROCESS MODEL

A DBMS’s process model defines how the system

is architected to support concurrent requests from
a multi-user application.

A worker is the DBMS component that is

responsible for executing tasks on behalf of the
client and returning the results.

CMU 15-445/645 (Fall 2019)

 9

PROCESS MODELS

Approach #1: Process per DBMS Worker

Approach #2: Process Pool

Approach #3: Thread per DBMS Worker

CMU 15-445/645 (Fall 2019)

 10

PROCESS PER WORKER

Each worker is a separate OS process.

→ Relies on OS scheduler.
→ Use shared-memory for global data structures.
→ A process crash doesn’t take down entire system.
→ Examples: IBM DB2, Postgres, Oracle

Dispatcher Worker
CMU 15-445/645 (Fall 2019)
 11

PROCESS POOL

A worker uses any process that is free in a pool

→ Still relies on OS scheduler and shared memory.
→ Bad for CPU cache locality.
→ Examples: IBM DB2, Postgres (2015)

Dispatcher Worker Pool

CMU 15-445/645 (Fall 2019)
 12

THREAD PER WORKER

Single process with multiple worker threads.

→ DBMS manages its own scheduling.
→ May or may not use a dispatcher thread.
→ Thread crash (may) kill the entire system.
→ Examples: IBM DB2, MSSQL, MySQL, Oracle (2014)

Worker Threads
CMU 15-445/645 (Fall 2019)
 13

PROCESS MODELS

Using a multi-threaded architecture has several

advantages:
→ Less overhead per context switch.
→ Do not have to manage shared memory.

The thread per worker model does not mean that

the DBMS supports intra-query parallelism.

Andy is not aware of any new DBMS from last 10

years that doesn’t use threads unless they are
Postgres forks.
CMU 15-445/645 (Fall 2019)
 14

SCHEDULING

For each query plan, the DBMS decides where,

when, and how to execute it.
→ How many tasks should it use?
→ How many CPU cores should it use?
→ What CPU core should the tasks execute on?
→ Where should a task store its output?

The DBMS always knows more than the OS.

CMU 15-445/645 (Fall 2019)

I N T E R- V S . I N T R A - Q U E R Y PA R A L L E L I S M

Inter-Query: Different queries are executed

concurrently.
→ Increases throughput & reduces latency.

Intra-Query: Execute the operations of a single

query in parallel.
→ Decreases latency for long-running queries.

CMU 15-445/645 (Fall 2019)

 16

I N T E R- Q U E R Y PA R A L L E L I S M

Improve overall performance by allowing multiple

queries to execute simultaneously.

If queries are read-only, then this requires little

coordination between queries.

If multiple queries are updating the database at the

same time, then this is hard to do correctly…

CMU 15-445/645 (Fall 2019)

 17

I N T R A - Q U E R Y PA R A L L E L I S M

Improve the performance of a single query by

executing its operators in parallel.

Think of organization of operators in terms of a

producer/consumer paradigm.

There are parallel algorithms for every relational

operator.
→ Can either have multiple threads access centralized data
structures or use partitioning to divide work up.

CMU 15-445/645 (Fall 2019)

 18

PA R A L L E L G R A C E H A S H J O I N

Use a separate worker to perform the join for each

level of buckets for R and S after partitioning.

R(id,name) HTR HTS

0 S(id,value,cdate)
1
h1 2 h1
⋮ ⋮
max

CMU 15-445/645 (Fall 2019)

 18

PA R A L L E L G R A C E H A S H J O I N

Use a separate worker to perform the join for each

level of buckets for R and S after partitioning.

R(id,name) HTR HTS

1 0 S(id,value,cdate)
2 1
h1 3 2 h1
⋮ ⋮
n max

CMU 15-445/645 (Fall 2019)

 19

I N T R A - Q U E R Y PA R A L L E L I S M

Approach #1: Intra-Operator (Horizontal)

Approach #2: Inter-Operator (Vertical)

Approach #3: Bushy

CMU 15-445/645 (Fall 2019)

 20

I N T R A - O P E R AT O R PA R A L L E L I S M

Approach #1: Intra-Operator (Horizontal)

→ Decompose operators into independent fragments that
perform the same function on different subsets of data.

The DBMS inserts an exchange operator into the

query plan to coalesce results from children
operators.

CMU 15-445/645 (Fall 2019)

 21

I N T R A - O P E R AT O R PA R A L L E L I S M

Exchange

SELECT * FROM A
WHERE A.value > 99 s s s
A1 A2 A3
s value>99 1 2 3

Pages
1 2 3 4 5
CMU 15-445/645 (Fall 2019)
 21

I N T R A - O P E R AT O R PA R A L L E L I S M

Exchange

SELECT * FROM A Fragment

WHERE A.value > 99 s s s
A1 A2 A3
s value>99 1 2 3

Pages
1 2 3 4 5
CMU 15-445/645 (Fall 2019)
 21

I N T R A - O P E R AT O R PA R A L L E L I S M

Next Exchange

SELECT * FROM A
WHERE A.value > 99 s Next s s
A1 A2 A3
s value>99 1 2 3

Pages
1 2 3 4 5
CMU 15-445/645 (Fall 2019)
 21

I N T R A - O P E R AT O R PA R A L L E L I S M

Next Exchange

SELECT * FROM A
WHERE A.value > 99 s Next s s
A1 A2 A3
s value>99 1 2 3

Pages
1 2 3 4 5
CMU 15-445/645 (Fall 2019)
 21

I N T R A - O P E R AT O R PA R A L L E L I S M

Exchange

SELECT * FROM A
WHERE A.value > 99 s s s
A1 A2 A3
s value>99 1 2 3

Pages
1 2 3 4 5
CMU 15-445/645 (Fall 2019)
 21

I N T R A - O P E R AT O R PA R A L L E L I S M

Exchange

SELECT * FROM A
WHERE A.value > 99 s s s
A1 A2 A3
s value>99 1 2 3

Pages
1 2 3 4 5
CMU 15-445/645 (Fall 2019)
 22

E XC H A N G E O P E R AT O R

Exchange Type #1 – Gather

→ Combine the results from multiple workers into a single
output stream.
→ Query plan root must always be a gather exchange.

Exchange Type #2 – Repartition

→ Reorganize multiple input streams across multiple output
streams.

Exchange Type #3 – Distribute

→ Split a single input stream into multiple output streams.
Source: Craig Freedman

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p
⨝
s s A 1 A2 A3
A B 1 2 3

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p
⨝ s s s
s s A 1 A2 A3
A B 1 2 3

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p
⨝ Build HT

s
Build HT

s
Build HT

s
s s A 1 A2 A3
A B 1 2 3

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p Exchange

⨝ Build HT

s
Build HT

s
Build HT

s
s s A 1 A2 A3
A B 1 2 3

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p Exchange

⨝ Build HT

s
Build HT

s
Build HT

s
s s A 1 A2 A3 B1 B2
A B 1 2 3 4 5

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p Exchange Exchange

⨝ Build HT

s
Build HT

s
Build HT

s
Partition

s
Partition

s
s s A 1 A2 A3 B1 B2
A B 1 2 3 4 5

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100
⨝
p Exchange Exchange

⨝ Build HT

s
Build HT

s
Build HT

s
Partition

s
Partition

s
s s A 1 A2 A3 B1 B2
A B 1 2 3 4 5

CMU 15-445/645 (Fall 2019)

 23

I N T R A - O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value Exchange
FROM A JOIN B
ON A.id = B.id 1 2 3 4
WHERE A.value < 99
Probe HT Probe HT Probe HT Probe HT
AND B.value > 100
⨝
p Exchange Exchange

⨝ Build HT

s
Build HT

s
Build HT

s
Partition

s
Partition

s
s s A 1 A2 A3 B1 B2
A B 1 2 3 4 5

CMU 15-445/645 (Fall 2019)

 24

I N T E R- O P E R AT O R PA R A L L E L I S M

Approach #2: Inter-Operator (Vertical)

→ Operations are overlapped in order to pipeline data from
one stage to the next without materialization.

Also called pipelined parallelism.

CMU 15-445/645 (Fall 2019)

 I N T E R- O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id
WHERE A.value < 99
AND B.value > 100

p
⨝
s s 1
⨝
for r1 ∊ outer:
for r2 ∊ inner:

A B
emit(r1⨝r2)

CMU 15-445/645 (Fall 2019)

 I N T E R- O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id

p
WHERE A.value < 99
AND B.value > 100 for r ∊ incoming:
2
emit(pr)
p
⨝
s s 1
⨝
for r1 ∊ outer:
for r2 ∊ inner:

A B
emit(r1⨝r2)

CMU 15-445/645 (Fall 2019)

 I N T E R- O P E R AT O R PA R A L L E L I S M
SELECT A.id, B.value
FROM A JOIN B
ON A.id = B.id

p
WHERE A.value < 99
AND B.value > 100 for r ∊ incoming:
2
emit(pr)
p
⨝
s s 1
⨝
for r1 ∊ outer:
for r2 ∊ inner:

A B
emit(r1⨝r2)

CMU 15-445/645 (Fall 2019)

 26

B U S H Y PA R A L L E L I S M

Approach #3: Bushy Parallelism 3 Exchange 4

→ Extension of inter-operator parallelism
where workers execute multiple operators
from different segments of a query plan at
⨝ ⨝
the same time.
→ Still need exchange operators to combine Exchange Exchange
intermediate results from segments.
⨝ ⨝
SELECT *
FROM A JOIN B JOIN C JOIN D A B C D
1 2

CMU 15-445/645 (Fall 2019)

 27

O B S E R VAT I O N

Using additional processes/threads to execute

queries in parallel won't help if the disk is always
the main bottleneck.
→ Can make things worse if each worker is reading
different segments of disk.

CMU 15-445/645 (Fall 2019)

 28

I / O PA R A L L E L I S M

Split the DBMS installation across multiple storage

devices.
→ Multiple Disks per Database
→ One Database per Disk
→ One Relation per Disk
→ Split Relation across Multiple Disks

CMU 15-445/645 (Fall 2019)

 29

M U LT I - D I S K PA R A L L E L I S M

Configure OS/hardware to store the

DBMS's files across multiple storage
devices.
→ Storage Appliances
→ RAID Configuration
page1 page2 page3

This is transparent to the DBMS. page4 page5 page6

RAID 0 (Stripping)
CMU 15-445/645 (Fall 2019)
 29

M U LT I - D I S K PA R A L L E L I S M

Configure OS/hardware to store the

DBMS's files across multiple storage
devices.
→ Storage Appliances
→ RAID Configuration
page1 page1 page1

This is transparent to the DBMS. page2 page2 page2

RAID 1 (Mirroring)
CMU 15-445/645 (Fall 2019)
 30

D ATA B A S E PA R T I T I O N I N G

Some DBMSs allow you specify the disk location

of each individual database.
→ The buffer pool manager maps a page to a disk location.

This is also easy to do at the filesystem level if the

DBMS stores each database in a separate directory.
→ The log file might be shared though

CMU 15-445/645 (Fall 2019)

 31

PA R T I T I O N I N G

Split single logical table into disjoint physical

segments that are stored/managed separately.

Ideally partitioning is transparent to the

application.
→ The application accesses logical tables and does not care
how things are stored.
→ Not always true in distributed DBMSs.

CMU 15-445/645 (Fall 2019)

 32

V E R T I C A L PA R T I T I O N I N G
CREATE TABLE foo (
Store a table’s attributes in a separate attr1 INT,
location (e.g., file, disk volume). attr2 INT,
attr3 INT,
Have to store tuple information to attr4 TEXT
reconstruct the original record. );

Tuple#1 attr1 attr2 attr3 attr4

Tuple#2 attr1 attr2 attr3 attr4
Tuple#3 attr1 attr2 attr3 attr4
Tuple#4 attr1 attr2 attr3 attr4

CMU 15-445/645 (Fall 2019)

 32

V E R T I C A L PA R T I T I O N I N G
CREATE TABLE foo (
Store a table’s attributes in a separate attr1 INT,
location (e.g., file, disk volume). attr2 INT,
attr3 INT,
Have to store tuple information to attr4 TEXT
reconstruct the original record. );

Partition #1 Partition #2
Tuple#1 attr1 attr2 attr3 Tuple#1 attr4
Tuple#2 attr1 attr2 attr3 Tuple#2 attr4
Tuple#3 attr1 attr2 attr3 Tuple#3 attr4
Tuple#4 attr1 attr2 attr3 Tuple#4 attr4

CMU 15-445/645 (Fall 2019)

 33

H O R I Z O N TA L PA R T I T I O N I N G
CREATE TABLE foo (
Divide the tuples of a table up into attr1 INT,
disjoint segments based on some attr2 INT,
attr3 INT,
partitioning key. attr4 TEXT
→ Hash Partitioning );
→ Range Partitioning
→ Predicate Partitioning

Tuple#1 attr1 attr2 attr3 attr4

Tuple#2 attr1 attr2 attr3 attr4
Tuple#3 attr1 attr2 attr3 attr4
Tuple#4 attr1 attr2 attr3 attr4

CMU 15-445/645 (Fall 2019)

 33

H O R I Z O N TA L PA R T I T I O N I N G
CREATE TABLE foo (
Divide the tuples of a table up into attr1 INT,
disjoint segments based on some attr2 INT,
attr3 INT,
partitioning key. attr4 TEXT
→ Hash Partitioning );
→ Range Partitioning
→ Predicate Partitioning

Partition #1 Partition #2
Tuple#1 attr1 attr2 attr3 attr4 Tuple#3 attr1 attr2 attr3 attr4
Tuple#2 attr1 attr2 attr3 attr4 Tuple#4 attr1 attr2 attr3 attr4

CMU 15-445/645 (Fall 2019)

 34

CONCLUSION

Parallel execution is important.

(Almost) every DBMS support this.

This is really hard to get right.

→ Coordination Overhead
→ Scheduling
→ Concurrency Issues
→ Resource Contention

CMU 15-445/645 (Fall 2019)

 35

MIDTERM EXAM

Who: You
What: Midterm Exam
When: Wed Oct 16th @ 12:00pm ‐ 1:20pm
Where: MM 103
Why: https://youtu.be/GHPB1eCROSA

Covers up to Query Execution II (inclusive).

→ Please email Andy if you need special accommodations.
→ https://15445.courses.cs.cmu.edu/fall2019/midterm-
guide.html
CMU 15-445/645 (Fall 2019)
 36

MIDTERM EXAM

What to bring:
→ CMU ID
→ Calculator
→ One 8.5x11" page of handwritten notes (double-sided)

What not to bring:

→ Live animals
→ Your wet laundry
→ Votive Candles (aka "Jennifer Lopez" Candles)

CMU 15-445/645 (Fall 2019)

 37

R E L AT I O N A L M O D E L

Integrity Constraints
Relation Algebra

CMU 15-445/645 (Fall 2019)

 38

SQL

Basic operations:
→ SELECT / INSERT / UPDATE / DELETE
→ WHERE predicates
→ Output control
More complex operations:
→ Joins
→ Aggregates
→ Common Table Expressions

CMU 15-445/645 (Fall 2019)

 39

STORAGE

Buffer Management Policies

→ LRU / MRU / CLOCK
On-Disk File Organization
→ Heaps
→ Linked Lists
Page Layout
→ Slotted Pages
→ Log-Structured

CMU 15-445/645 (Fall 2019)

 40

HASHING

Static Hashing
→ Linear Probing
→ Robin Hood
→ Cuckoo Hashing

Dynamic Hashing
→ Extendible Hashing
→ Linear Hashing

CMU 15-445/645 (Fall 2019)

 41

TREE INDEXES

B+Tree
→ Insertions / Deletions
→ Splits / Merges
→ Difference with B-Tree
→ Latch Crabbing / Coupling
Radix Trees

CMU 15-445/645 (Fall 2019)

 42

SORTING

Two-way External Merge Sort

General External Merge Sort
Cost to sort different data sets with different
number of buffers.

CMU 15-445/645 (Fall 2019)

 43

JOINS

Nested Loop Variants

Sort-Merge
Hash

Execution costs under different conditions.

CMU 15-445/645 (Fall 2019)

 44

QUERY PROCESSING

Processing Models
→ Advantages / Disadvantages

Parallel Execution
→ Inter- vs. Intra-Operator Parallelism

CMU 15-445/645 (Fall 2019)

 45

NEXT CLASS

Query Planning & Optimization

CMU 15-445/645 (Fall 2019)