Principles of Distributed Database

Systems
M. Tamer Özsu
Patrick Valduriez

© 2020, M.T. Özsu & P. Valduriez 1

Outline
 Introduction
 Distributed and parallel database design
 Distributed data control
 Distributed Query Processing
 Distributed Transaction Processing
 Data Replication
 Database Integration – Multidatabase Systems
 Parallel Database Systems
 Peer-to-Peer Data Management
 Big Data Processing
 NoSQL, NewSQL and Polystores
 Web Data Management

© 2020, M.T. Özsu & P. Valduriez 2

Outline
 Distributed Query Processing
 Query Decomposition and Localization
 Join Ordering
 Distributed Query Optimization
 Adaptive Query Processing

© 2020, M.T. Özsu & P. Valduriez 3

Query Processing in a DDBMS

High level user query

Query
Processor

Low-level data manipulation

commands for D-DBMS

© 2020, M.T. Özsu & P. Valduriez 4

Query Processing Components

 Query language
 SQL: “intergalactic dataspeak”

 Query execution
 The steps that one goes through in executing high-level
(declarative) user queries.

 Query optimization
 How do we determine the “best” execution plan?

 We assume a homogeneous D-DBMS

© 2020, M.T. Özsu & P. Valduriez 5

Selecting Alternatives

SELECT ENAME
FROM EMP NATURAL JOIN ASG
WHERE RESP = "Manager"

Strategy 1
ENAME(RESP=“Manager”EMP.ENO=ASG.ENO(EMP×ASG))
Strategy 2
 ENAME(EMP ⋈ENO (RESP=“Manager” (ASG))

Strategy 2 avoids Cartesian product, so may be “better”

© 2020, M.T. Özsu & P. Valduriez 6
 What is the Problem?

Site 1 Site 2 Site 3 Site 4 Site 5

ASG1=σENO≤“E3”(ASG) ASG2= σENO>“E3”(ASG) EMP1= σENO≤“E3”(EMP) EMP2= σENO>“E3”(EMP) Result

© 2020, M.T. Özsu & P. Valduriez 7

 Cost of Alternatives
 Assume
 size(EMP) = 400, size(ASG) = 1000
 tuple access cost = 1 unit; tuple transfer cost = 10 units
 Strategy 1
 produce ASG': (10+10)  tuple access cost

20
 transfer ASG' to the sites of EMP: (10+10)  tuple transfer cost

200
 produce EMP': (10+10)  tuple access cost  2

40
 transfer EMP' to result site: (10+10)  tuple transfer cost

200
Total Cost 460
 Strategy 2
© 2020, M.T. Özsu & P. Valduriez 8
 transfer EMP to site 5: 400  tuple transfer cost
Query Optimization Objectives
 Minimize a cost function
 I/O cost + CPU cost + communication cost
 These might have different weights in different distributed
environments
 Wide area networks
 Communication cost may dominate or vary much
 Bandwidth
 Speed
 Protocol overhead
 Local area networks
 Communication cost not that dominant,so total cost function
should be considered
 Can also maximize throughput

© 2020, M.T. Özsu & P. Valduriez 9

 Complexity of Relational Operations

Operation Complexity

Select
Project O(n)
 Assume (without duplicate elimination)
 Relations of cardinality n Project
 Sequential scan (with duplicate elimination) O(n  log n)
Group

Join
Semi-join O(n  log n)
Division
Set Operators

Cartesian Product O(n2)

© 2020, M.T. Özsu & P. Valduriez 10

Types Of Optimizers

 Exhaustive search
 Cost-based
 Optimal
 Combinatorial complexity in the number of relations
 Heuristics
 Not optimal
 Regroup common sub-expressions
 Perform selection, projection first
 Replace a join by a series of semijoins
 Reorder operations to reduce intermediate relation size
 Optimize individual operations

© 2020, M.T. Özsu & P. Valduriez 11

 Optimization Granularity

 Single query at a time

 Cannot use common intermediate results

 Multiple queries at a time

 Efficient if many similar queries
 Decision space is much larger

© 2020, M.T. Özsu & P. Valduriez 12

Optimization Timing

 Static
 Compilation  optimize prior to the execution
 Difficult to estimate the size of the intermediate results⇒error
propagation
 Can amortize over many executions
 Dynamic
 Run time optimization
 Exact information on the intermediate relation sizes
 Have to reoptimize for multiple executions
 Hybrid
 Compile using a static algorithm
 If the error in estimate sizes > threshold, reoptimize at run time

© 2020, M.T. Özsu & P. Valduriez 13

Statistics

 Relation
 Cardinality
 Size of a tuple
 Fraction of tuples participating in a join with another relation
 Attribute
 Cardinality of domain
 Actual number of distinct values
 Simplifying assumptions
 Independence between different attribute values
 Uniform distribution of attribute values within their domain

© 2020, M.T. Özsu & P. Valduriez 14

Optimization Decision Sites

 Centralized
 Single site determines the “best” schedule
 Simple
 Need knowledge about the entire distributed database
 Distributed
 Cooperation among sites to determine the schedule
 Need only local information
 Cost of cooperation
 Hybrid
 One site determines the global schedule
 Each site optimizes the local subqueries

© 2020, M.T. Özsu & P. Valduriez 15

Network Topology

 Wide area networks (WAN) – point-to-point

 Characteristics
 Relatively low bandwidth (compared to local CPU/IO)
 High protocol overhead
 Communication cost may dominate; ignore all other cost factors
 Global schedule to minimize communication cost
 Local schedules according to centralized query optimization
 Local area networks (LAN)
 Communication cost not that dominant
 Total cost function should be considered
 Broadcasting can be exploited (joins)
 Special algorithms exist for star networks

© 2020, M.T. Özsu & P. Valduriez 16

Distributed Query Processing
Methodology

© 2020, M.T. Özsu & P. Valduriez 17

Outline
 Distributed Query Processing
 Query Decomposition and Localization
 Distributed Query Optimization
 Join Ordering
 Adaptive Query Processing

© 2020, M.T. Özsu & P. Valduriez 18

Step 1 – Query Decomposition
Same as centralized query processing
Input : Calculus query on global relations
 Normalization
 Manipulate query quantifiers and qualification
 Analysis
 Detect and reject “incorrect” queries
 Simplification
 Eliminate redundant predicates
 Restructuring
 Calculus query  algebraic query
 Use transformation rules

© 2020, M.T. Özsu & P. Valduriez 19

Step 2 – Data Localization

Input: Algebraic query on distributed relations

 Determine which fragments are involved
 Localization program
 Substitute for each global query its materialization program
 Optimize

© 2020, M.T. Özsu & P. Valduriez 20

Example
 Assume
 EMP is fragmented as follows:
 EMP1= ENO≤“E3”(EMP)

 EMP2= “E3”<ENO≤“E6”(EMP)
 EMP3= ENO≥“E6”(EMP)
 ASG fragmented as follows:
 ASG1= ENO≤“E3”(ASG)

 ASG2= ENO>“E3”(ASG)
 In any query
 Replace EMP by (EMP1  EMP2  EMP3)
 Replace ASG by (ASG1  ASG2)

© 2020, M.T. Özsu & P. Valduriez 21

Reduction for PHF
 Reduction with selection
 Relation R and FR={R1, R2, …, Rw} where Rj=pj(R)

p (Rj)= if x in R: ¬(pi(x) pj(x))

i

SELECT *
FROM EMP
WHERE ENO="E5"

© 2020, M.T. Özsu & P. Valduriez 22

Reduction for PHF

 Reduction with join

 Possible if fragmentation is done on join attribute
 Distribute join over union
(R1 R2)⋈S  (R1⋈S)  (R2⋈S)
 Given Ri =pi(R) and Rj = pj(R)

Ri ⋈Rj = if x in Ri, y in Rj: ¬(pi(x) pj(y))

© 2020, M.T. Özsu & P. Valduriez 23

 Reduction for PHF

▷◁ ENO
 Assume EMP is fragmented as
before and
 ASG1: ENO ≤ "E3"(ASG)  
 ASG2: ENO > "E3"(ASG)
 Consider the query EMP1 EMP2 EMP3 ASG1 ASG2
SELECT *
FROM EMP 
NATURAL JOIN ASG
 Distribute join over unions ▷◁ ENO ▷◁ ENO ▷◁ ENO
 Apply the reduction rule
EMP1 ASG1 EMP2 ASG2 EMP3 ASG2

© 2020, M.T. Özsu & P. Valduriez 24

 Reduction for VF
 Find useless (not empty) intermediate relations
Relation R defined over attributes A = {A1, ..., An} vertically
fragmented as Ri =A'(R) where A' A:
D,K(Ri) is useless if the set of projection attributes D is not in A'
Example: EMP1=ENO,ENAME (EMP); EMP2=ENO,TITLE (EMP)
SELECT ENAME
FROM EMP

© 2020, M.T. Özsu & P. Valduriez 25

Reduction for DHF
 Rule :
 Distribute joins over unions
 Apply the join reduction for horizontal fragmentation
 Example
ASG1: ASG ⋉ENO EMP1
ASG2: ASG ⋉ENO EMP2
EMP1: TITLE=“Programmer” (EMP)
EMP2: TITLE=“Programmer” (EMP)
 Query
SELECT *
FROM EMP NATURAL JOIN ASG
WHERE EMP.TITLE = "Mech. Eng."

© 2020, M.T. Özsu & P. Valduriez 26

 Reduction for DHF
Generic query

Selections first

© 2020, M.T. Özsu & P. Valduriez 27

Reduction for DHF
Joins over unions

Elimination of the empty

intermediate relations
(left sub-tree)

© 2020, M.T. Özsu & P. Valduriez 28

Reduction for Hybrid Fragmentation

 Combine the rules already specified:

 Remove empty relations generated by contradicting selections
on horizontal fragments;
 Remove useless relations generated by projections on vertical
fragments;
 Distribute joins over unions in order to isolate and remove
useless joins.

© 2020, M.T. Özsu & P. Valduriez 29

Reduction for HF
Example
Consider the following hybrid
fragmentation:
EMP1= ENO≤"E4" (ENO,ENAME (EMP))

EMP2= ENO>"E4" (ENO,ENAME (EMP)) 

EMP3= ENO,TITLE (EMP)

and the query

SELECT ENAME
FROM EMP
WHERE ENO="E5"

© 2020, M.T. Özsu & P. Valduriez 30

Outline
 Distributed Query Processing
 Query Decomposition and Localization
 Distributed Query Optimization
 Join Ordering
 Adaptive Query Processing

© 2020, M.T. Özsu & P. Valduriez 31

Step 3 – Global Query Optimization

Input: Fragment query

 Find the best (not necessarily optimal) global schedule
 Minimize a cost function
 Distributed join processing
 Bushy vs. linear trees
 Which relation to ship where?
 Ship-whole vs ship-as-needed
 Decide on the use of semijoins
 Semijoin saves on communication at the expense of more local
processing
 Join methods
 Nested loop, merge join or hash join

© 2020, M.T. Özsu & P. Valduriez 32

Query Optimization Process

Input Query

Search Space Transformation

Generation Rules

Equivalent QEP

Search Cost Model

Strategy

Best QEP

© 2020, M.T. Özsu & P. Valduriez 33

Components
 Search space
 The set of equivalent algebra expressions (query trees)
 Cost model
 I/O cost + CPU cost + communication cost
 These might have different weights in different distributed
environments (LAN vs WAN)
 Can also maximize throughput
 Search algorithm
 How do we move inside the solution space?
 Exhaustive search, heuristic algorithms (iterative improvement,
simulated annealing, genetic,…)

© 2020, M.T. Özsu & P. Valduriez 34

 Join Trees
 Characterize the search space
for optimization
 For N relations, there are O(N!)
equivalent join trees that can be
obtained by applying
commutativity and associativity
rules
SELECT ENAME,RESP
FROM EMP
NATURAL JOIN ASG
NATURAL JOIN PROJ

© 2020, M.T. Özsu & P. Valduriez 35

Join Trees

 Two major shapes

 Linear versus bushy trees

Linear Join Tree Bushy Join Tree

© 2020, M.T. Özsu & P. Valduriez 36

Search Strategy

 How to “move” in the search space

 Deterministic
 Start from base relations and build plans by adding one relation
at each step
 Dynamic programming: breadth-first
 Greedy: depth-first
 Randomized
 Search for optimalities around a particular starting point
 Trade optimization time for execution time
 Better when > 10 relations
 Simulated annealing
 Iterative improvement

© 2020, M.T. Özsu & P. Valduriez 37

 Search Strategies

 Deterministic ⋈
⋈ ⋈ R4

⋈ ⋈ R3 ⋈ R3

R1 R2 R1 R2 R1 R2

 Randomized
⋈ ⋈
⋈ R3 ⋈ R2

R1 R2 R1 R3

© 2020, M.T. Özsu & P. Valduriez 38

Outline
 Distributed Query Processing
 Query Decomposition and Localization
 Distributed Query Optimization
 Join Ordering
 Adaptive Query Processing

© 2020, M.T. Özsu & P. Valduriez 39

 Join Ordering

 Multiple relations more difficult because too many

alternatives.
 Compute the cost of all alternatives and select the best one.
 Necessary to compute the size of intermediate relations which is
difficult.
 Use heuristics

© 2020, M.T. Özsu & P. Valduriez 40

Join Ordering – Example

Consider
PROJ ⋈PNO ASG ⋈ENO EMP

© 2020, M.T. Özsu & P. Valduriez 41

 Join Ordering – Example
Execution alternatives

1. EMP Site 22. ASG  Site 1

Site 2 computes EMP'=EMP ⋈ ASG Site 1 computes EMP'=EMP ⋈ ASG
EMP' Site 3 EMP'  Site 3
Site 3 computes EMP' ⋈ PROJ Site 3 computes EMP’ ⋈ PROJ

3. ASG  Site 3 4. PROJ  Site 2

Site 3 computes ASG'=ASG ⋈ PROJ Site 2 computes PROJ'=PROJ ⋈
ASG
ASG'  Site 1 PROJ'  Site 1
Site 1 computes ASG' ▷◁ EMP Site 1 computes PROJ' ⋈ EMP

5. EMP  Site 2
PROJ  Site 2
Site 2 computes EMP ⋈ PROJ ⋈ ASG

© 2020, M.T. Özsu & P. Valduriez 42

Semijoin-based Ordering

 Consider the join of two relations:

 R[A] (located at site 1)
 S[A](located at site 2)
 Alternatives:
1. Do the join R ⋈AS
2. Perform one of the semijoin equivalents

R ⋈AS  (R ⋉AS) ⋈AS

 R ⋈A (S ⋉A R)
 (R ⋉A S) ⋈A (S ⋉A R)

© 2020, M.T. Özsu & P. Valduriez 43

Semijoin-based Ordering
 Perform the join
 Send R to Site 2
 Site 2 computes R ⋈A S
 Consider semijoin (R ⋉AS) ⋈AS
 S' = A(S)
 S'  Site 1
 Site 1 computes R' = R ⋉AS'
 R' Site 2
 Site 2 computes R' ⋈AS

Semijoin is better if
size(A(S)) + size(R ⋉AS)) < size(R)

© 2020, M.T. Özsu & P. Valduriez 44

Full Reducer

 Optimal semijoin program that reduces each relation

more than others
 How to find the full reducer?
 Enumeration of all possible semijoin programs and select the
one that has best size reduction
 Problem
 For cyclic queries, no full reducers can be found
 For tree queries, full reducers exist but the number of candidate
semijoin programs is exponential in the number of relations
 For chained queries, where relations can be ordered so that each
relation joins only with the next relation, polynomial algorithms exist

© 2020, M.T. Özsu & P. Valduriez 45

Full Reducer – Example

Consider
ET (ENO, ENAME, TITLE, CITY)
AT (ENO, PNO, RESP, DUR, CITY)
PT (PNO, PNAME, BUDGET, CITY)

And the cyclic query

SELECT ENAME, PNAME
FROM ET NATURAL JOIN AT
NATURAL JOIN PT
NATURAL JOIN ET

© 2020, M.T. Özsu & P. Valduriez 46

Full Reducer – example

 Solution: transform the cyclic

query into a tree
 Remove one arc of the cyclic
graph
 Add appropriate predicates to
other arcs such that the
removed predicate is
preserved by transitivity

© 2020, M.T. Özsu & P. Valduriez 47

Join versus Semijoin-based Ordering
 Semijoin-based induces more operators, but possibly on
smaller operands

© 2020, M.T. Özsu & P. Valduriez 48

Distributed Cost Model

 Cost functions
 Total Time (or Total Cost)
 Reduce each cost (in terms of time) component individually
 Do as little of each cost component as possible
 Optimizes resource utilization and increases system throughput
 Response Time
 Do as many things as possible in parallel
 May increase total time because of increased total activity

© 2020, M.T. Özsu & P. Valduriez 49

Total Time

Total time = CPU cost + I/O cost + com. Cost

The summation of all cost factors

CPU cost = unit instruction cost * no.of instructions

I/O cost = unit disk I/O cost * no. of disk I/Os

com. cost = message initiation + transmission

© 2020, M.T. Özsu & P. Valduriez 50

Response Time

Response time = CPU time + I/O time + com. time

Must consider parallel execution
CPU time = unit instruction time * no. of seq instructions
I/O time = unit I/O time * no. of seq I/Os
com. time = unit msg initiation time * no. of seq msgs
+ unit transmission time * no. of seq bytes

© 2020, M.T. Özsu & P. Valduriez 51

Example

 Consider communication cost only

 Total time = 2 × msg initialization time + unit transmission time *
(x+y)
 Response time = max {time to send x from 1 to 3, time to send y
from 2 to 3}

© 2020, M.T. Özsu & P. Valduriez 52

Database Statistics

 Primary cost factor: size of intermediate relations

 Need to estimate their sizes
 Make them precise  more costly to maintain
 Simplifying assumption: uniform distribution of attribute
values in a relation

© 2020, M.T. Özsu & P. Valduriez 53

 Statistics
 For each relation R[A1, A2, …, An] fragmented as R1, …, Rr
 length of each attribute: length(Ai)
 the number of distinct values for each attribute in each fragment:
card(AiRj)
 maximum and minimum values in the domain of each attribute:
min(Ai), max(Ai)
 the cardinalities of each domain: card(dom[Ai])
 The cardinalities of each fragment: card(Rj)
 Selectivity factor of each operator on relations
 See centralized query optimization statistics

© 2020, M.T. Özsu & P. Valduriez 54

Distributed Query Optimization

 Dynamic approach
 Distributed INGRES
 No static cost estimation, only runtime cost information
 Static approach
 System R*
 Static cost model
 Hybrid approach
 2-step

© 2020, M.T. Özsu & P. Valduriez 55

Dynamic Approach
1. Execute all monorelation queries (e.g., selection,
projection)
2. Reduce the multirelation query to produce irreducible
subqueries q1 q2  …  qn such that there is only
one relation between qi and qi+1
3. Choose qi involving the smallest fragments to execute
(call MRQ')
4. Find the best execution strategy for MRQ'
1. Determine processing site
2. Determine fragments to move
5. Repeat 3 and 4

© 2020, M.T. Özsu & P. Valduriez 56

Static Approach

 Cost function includes local processing as well as

transmission
 Considers only joins
 “Exhaustive” search
 Compilation

© 2020, M.T. Özsu & P. Valduriez 57

Static Approach – Performing Joins

 Ship whole
 Larger data transfer
 Smaller number of messages
 Better if relations are small
 Fetch as needed
 Number of messages = O(cardinality of external relation)
 Data transfer per message is minimal
 Better if relations are large and the selectivity is good

© 2020, M.T. Özsu & P. Valduriez 58

Static Approach –
Vertical Partitioning & Joins
1. Move outer relation tuples to the site of the inner relation
(a) Retrieve outer tuples
(b) Send them to the inner relation site
(c) Join them as they arrive

Total Cost = cost(retrieving qualified outer tuples)

+ no. of outer tuples fetched * cost(retrieving
qualified inner tuples)
+ msg. cost * (no. outer tuples fetched * avg.
outer tuple size)/msg. size

© 2020, M.T. Özsu & P. Valduriez 59

Static Approach –
Vertical Partitioning & Joins
2. Move inner relation to the site of outer relation
Cannot join as they arrive; they need to be stored
Total cost = cost (retrieving qualified outer tuples)
+ no. of outer tuples fetched * cost(retrieving matching inner
tuples from temporary storage)
+ cost(retrieving qualified inner tuples)
+ cost(storing all qualified inner tuples in temporary storage)
+ msg. cost * no. of inner tuples fetched * avg. inner tuple
size/msg. size

© 2020, M.T. Özsu & P. Valduriez 60

Static Approach –
Vertical Partitioning & Joins
3. Move both inner and outer relations to another site
Total cost = cost(retrieving qualified outer tuples)
+ cost(retrieving qualified inner tuples)
+ cost(storing inner tuples in storage)
+ msg. cost × (no. of outer tuples fetched * avg. outer tuple
size)/msg. size
+ msg. cost * (no. of inner tuples fetched * avg. inner tuple
size)/msg. size
+ no. of outer tuples fetched * cost(retrieving inner tuples from
temporary storage)

© 2020, M.T. Özsu & P. Valduriez 61

 Static Approach –
Vertical Partitioning & Joins
4. Fetch inner tuples as needed
(a) Retrieve qualified tuples at outer relation site
(b) Send request containing join column value(s) for outer tuples to
inner relation site
(c) Retrieve matching inner tuples at inner relation site
(d) Send the matching inner tuples to outer relation site
(e) Join as they arrive
Total Cost = cost(retrieving qualified outer tuples)
+ msg. cost * (no. of outer tuples fetched)
+ no. of outer tuples fetched * no. of inner tuples fetched * avg.
inner tuple size * (msg. cost / msg. size)
+ no. of outer tuples fetched * cost(retrieving matching inner tuples
for one outer value)

© 2020, M.T. Özsu & P. Valduriez 62

2-Step Optimization
1. At compile time, generate a static plan with operation
ordering and access methods only
2. At startup time, carry out site and copy selection and
allocate operations to sites
Static plan Runtime plan

© 2020, M.T. Özsu & P. Valduriez 63

2-Step – Problem Definition

 Given
 A set of sites S = {s1, s2, …,sn} with the load of each site
 A query Q ={q1, q2, q3, q4} such that each subquery qi is the
maximum processing unit that accesses one relation and
communicates with its neighboring queries
 For each qi in Q, a feasible allocation set of sites Sq={s1, s2,
…,sk} where each site stores a copy of the relation in qi
 The objective is to find an optimal allocation of Q to S
such that
 The load unbalance of S is minimized
 The total communication cost is minimized

© 2020, M.T. Özsu & P. Valduriez 64

2-Step Algorithm

 For each q in Q compute load (Sq)

 While Q not empty do
1. Select subquery a with least allocation flexibility
2. Select best site b for a (with least load and best benefit)
3. Remove a from Q and recompute loads if needed

© 2020, M.T. Özsu & P. Valduriez 65

 2-Step Algorithm Example

 Let Q = {q1, q2, q3, q4} where q1 is

associated with R1, q2 is associated with
R2 joined with the result of q1, etc.
 Iteration 1: select q4, allocate to s1, set
load(s1)=2
 Iteration 2: select q2, allocate to s2, set
load(s2)=3
 Iteration 3: select q3, allocate to s1, set
load(s1) =3
 Iteration 4: select q1, allocate to s3 or s4

Note: if in iteration 2, q2 were allocated to s4, this would have produced

a better plan. So hybrid optimization can still miss optimal plans
Outline
 Distributed Query Processing
 Query Decomposition and Localization
 Distributed Query Optimization
 Join Ordering
 Adaptive Query Processing

© 2020, M.T. Özsu & P. Valduriez 67

Adaptive Query Processing -
Motivations
 Assumptions underlying query optimization
 The optimizer has sufficient knowledge about runtime
 Cost information
 Runtime conditions remain stable during query execution
 Appropriate for systems with few data sources in a
controlled environment
 Inappropriate for changing environments with large
numbers of data sources and unpredictable runtime
conditions

© 2020, M.T. Özsu & P. Valduriez 68

Example: QEP with Blocked Operator

 Assume ASG, EMP,

PROJ and PAY each at a
different site
 If ASG site is down, the
entire pipeline is blocked
 However, with some
reorganization, the join of
EMP and PAY could be
done while waiting for
ASG

6
Adaptive Query Processing – Definition
 A query processing is adaptive if it receives information
from the execution environment and determines its
behavior accordingly
 Feed-back loop between optimizer and runtime environment
 Communication of runtime information between DDBMS
components
 Additional components
 Monitoring, assessment, reaction
 Embedded in control operators of QEP
 Tradeoff between reactiveness and overhead of
adaptation

© 2020, M.T. Özsu & P. Valduriez 70

Adaptive Components

 Monitoring parameters (collected by sensors in QEP)

 Memory size
 Data arrival rates
 Actual statistics
 Operator execution cost
 Network throughput
 Adaptive reactions
 Change schedule
 Replace an operator by an equivalent one
 Modify the behavior of an operator
 Data repartitioning

© 2020, M.T. Özsu & P. Valduriez 71

Eddy Approach

 Query compilation: produces a tuple D, P, C, Eddy

 D: set of data sources (e.g. relations)
 P: set of predicates
 C: ordering constraints to be followed at runtime
 Eddy: n-ary operator between D and P
 Query execution: operator ordering on a tuple basis
using Eddy
 On-the-fly tuple routing to operators based on cost and
selectivity
 Change of join ordering during execution
 Requires symmetric join algorithms such as Ripple joins

© 2020, M.T. Özsu & P. Valduriez 72

 QEP with Eddy
 D= {R, S, T}
 P = {P (R), R ⋈1 S, S ⋈2 T)
 C = {S < T} where < imposes S tuples to probe T tuples using an index on join
attribute
 Access to T is wrapped by ⋈

© 2020, M.T. Özsu & P. Valduriez 73