Principles of Distributed Database

Systems

@ SGGSIE & Tech 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
@ SGGSIE & Tech 2
Outline
◼ Distributed Query Processing
❑ Query Decomposition and Localization
❑ Join Ordering
❑ Distributed Query Optimization
❑ Adaptive Query Processing

@ SGGSIE & Tech 3

Query Processing in a DDBMS

High level user query

Query
Processor

Low-level data manipulation

commands for D-DBMS

@ SGGSIE & Tech 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

@ SGGSIE & Tech 5

Selecting Alternatives

SELECT ENAME
FROM EMP NATURAL JOIN ASG
WHERE RESP = "Manager"
◼ {EMP(ENO, ENAME, TITLE)
ASG(ENO, PNO, RESP, DUR)}
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”
@ SGGSIE & Tech 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

@ SGGSIE & Tech 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
❑ transfer EMP to site 5: 400  tuple transfer cost 4,000
❑ transfer ASG to site 5: 1000  tuple transfer cost 10,000
❑ produce ASG': 1000  tuple access cost 1,000
❑ join EMP and ASG': 400  20  tuple access cost 8,000
Total Cost 23,000

@ SGGSIE & Tech 8

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
@ SGGSIE & Tech 9
 Complexity of Relational Operations

Operation Complexity

Select
Project O(n)
◼ Assume (without duplicate elimination)

❑ Relations of cardinality n Project

(with duplicate elimination) O(n  log n)
❑ Sequential scan
Group

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

Cartesian Product O(n2)

@ SGGSIE & Tech 10

Characterization of Query Processors

 Languages
 Types of Optimization
 Exhaustive search
 randomized strategies
 Iterative improvement & simulated annealing
 Heuristics
 Optimization Timing
 Statistics
 Exploitation of the Network Topology
 Use of Semijoins

@ SGGSIE & Tech 11

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

@ SGGSIE & Tech 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

@ SGGSIE & Tech 13

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

@ SGGSIE & Tech 14

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

@ SGGSIE & Tech 15

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

@ SGGSIE & Tech 16

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

@ SGGSIE & Tech 17

Distributed Query Processing
Methodology

@ SGGSIE & Tech 18

Outline
◼ Distributed Query Processing
❑ Query Decomposition and Localization
❑

@ SGGSIE & Tech 19

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

@ SGGSIE & Tech 20

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

@ SGGSIE & Tech 21

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)

@ SGGSIE & Tech 22

Reduction for PHF
◼ Reduction with selection
❑ Relation R and FR={R1, R2, …, Rw} where Rj=pj(R)
pi(Rj)= if x in R: ¬(pi(x) pj(x))

SELECT *
FROM EMP
WHERE ENO="E5"

@ SGGSIE & Tech 23

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))

@ SGGSIE & Tech 24

 Reduction for PHF

◼ Assume EMP is fragmented as ▷◁ ENO

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

@ SGGSIE & Tech 25

 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

@ SGGSIE & Tech 26

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."

@ SGGSIE & Tech 27

 Reduction for DHF
Generic query

Selections first

@ SGGSIE & Tech 28

Reduction for DHF
Joins over unions

Elimination of the empty

intermediate relations
(left sub-tree)

@ SGGSIE & Tech 29

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.

@ SGGSIE & Tech 30

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"

@ SGGSIE & Tech 31

Outline
◼ Distributed Query Processing
❑

❑ Distributed Query Optimization

❑

@ SGGSIE & Tech 32

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

@ SGGSIE & Tech 33

Query Optimization Process

Input Query

Search Space Transformation

Generation Rules

Equivalent QEP

Search Cost Model

Strategy

Best QEP

@ SGGSIE & Tech 34

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,…)

@ SGGSIE & Tech 35

 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

@ SGGSIE & Tech 36

Join Trees

◼ Two major shapes

◼ Linear versus bushy trees

Linear Join Tree Bushy Join Tree

@ SGGSIE & Tech 37

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

@ SGGSIE & Tech 38

 Search Strategies

◼ Deterministic ⋈
⋈ ⋈ R4

⋈ ⋈ R3 ⋈ R3

R1 R2 R1 R2 R1 R2

◼ Randomized
⋈ ⋈
⋈ R3 ⋈ R2

R1 R2 R1 R3

@ SGGSIE & Tech 39

Outline
◼ Distributed Query Processing
❑

❑ Join Ordering
❑

@ SGGSIE & Tech 40

 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

@ SGGSIE & Tech 41

Join Ordering – Example

Consider
PROJ ⋈PNO ASG ⋈ENO EMP

@ SGGSIE & Tech 42

 Join Ordering – Example
Execution alternatives

1. EMP→ Site 2 2. 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

@ SGGSIE & Tech 43

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)

@ SGGSIE & Tech 44

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)

@ SGGSIE & Tech 45

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

@ SGGSIE & Tech 46

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

@ SGGSIE & Tech 47

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

@ SGGSIE & Tech 48

Join versus Semijoin-based Ordering

◼ Semijoin-based induces more operators, but possibly on

smaller operands

@ SGGSIE & Tech 49

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

@ SGGSIE & Tech 50

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

@ SGGSIE & Tech 51

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

@ SGGSIE & Tech 52

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}

@ SGGSIE & Tech 53

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

@ SGGSIE & Tech 54

 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

@ SGGSIE & Tech 55

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

@ SGGSIE & Tech 56

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

@ SGGSIE & Tech 57

Static Approach

◼ Cost function includes local processing as well as

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

@ SGGSIE & Tech 58

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

@ SGGSIE & Tech 59

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

@ SGGSIE & Tech 60

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

@ SGGSIE & Tech 61

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)

@ SGGSIE & Tech 62

 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)

@ SGGSIE & Tech 63

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

@ SGGSIE & Tech 64

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

@ SGGSIE & Tech 65

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

@ SGGSIE & Tech 66

 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
❑

❑ Adaptive Query Processing

@ SGGSIE & Tech 68

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

@ SGGSIE & Tech 69

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

7
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

@ SGGSIE & Tech 71

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

@ SGGSIE & Tech 72

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

@ SGGSIE & Tech 73

 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 ⋈

@ SGGSIE & Tech 74