RBD Lectures Merged

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
Outline
◼ Introduction
❑ What is a distributed DBMS
❑ History
❑ Distributed DBMS promises
❑ Design issues
❑ Distributed DBMS architecture

Distributed Computing
◼ A number of autonomous processing elements (not

necessarily homogeneous) that are interconnected by a
computer network and that cooperate in performing their
assigned tasks.
◼ What is being distributed?
❑ Processing logic
❑ Function
❑ Data
❑ Control

Current Distribution – Geographically
Distributed Data Centers

What is a Distributed Database System?
A distributed database is a collection of multiple, logically

interrelated databases distributed over a computer network
A distributed database management system (Distributed

DBMS) is the software that manages the DDB and provides
an access mechanism that makes this distribution
transparent to the users

What is not a DDBS?
◼ A timesharing computer system

◼ A loosely or tightly coupled multiprocessor system
◼ A database system which resides at one of the nodes of
a network of computers - this is a centralized database
on a network node

Distributed DBMS Environment

Implicit Assumptions
◼ Data stored at a number of sites → each site logically

consists of a single processor
◼ Processors at different sites are interconnected by a
computer network → not a multiprocessor system
❑ Parallel database systems
◼ Distributed database is a database, not a collection of
files → data logically related as exhibited in the users’
access patterns
❑ Relational data model
◼ Distributed DBMS is a full-fledged DBMS
❑ Not remote file system, not a TP system

Important Point
Logically integrated
but
Physically distributed

Outline
◼ Introduction
❑
❑ History
❑

History – File Systems

History – Database Management

History – Early Distribution
Peer-to-Peer (P2P)

History – Client/Server

History – Data Integration

History – Cloud Computing
On-demand, reliable services provided over the Internet in

a cost-efficient manner
◼ Cost savings: no need to maintain dedicated compute
power
◼ Elasticity: better adaptivity to changing workload

Data Delivery Alternatives
◼ Delivery modes
❑ Pull-only
❑ Push-only
❑ Hybrid
◼ Frequency
❑ Periodic
❑ Conditional
❑ Ad-hoc or irregular
◼ Communication Methods
❑ Unicast
❑ One-to-many
◼ Note: not all combinations make sense
Outline
◼ Introduction
❑
❑ Distributed DBMS promises

❑

Distributed DBMS Promises
 Transparent management of distributed, fragmented,

and replicated data
 Improved reliability/availability through distributed

transactions
 Improved performance
 Easier and more economical system expansion
© 2020, M.T. Özsu & P. Valduriez

Transparency
◼ Transparency is the separation of the higher-level

semantics of a system from the lower level
implementation issues.
◼ Fundamental issue is to provide
data independence
in the distributed environment
❑ Network (distribution) transparency
❑ Replication transparency
❑ Fragmentation transparency
◼ horizontal fragmentation: selection
◼ vertical fragmentation: projection
◼ hybrid
© 2020, M.T. Özsu & P. Valduriez

Example

Transparent Access
Tokyo
SELECT ENAME,SAL
FROM EMP,ASG,PAY Boston Paris
WHERE DUR > 12 Paris projects
Paris employees
AND EMP.ENO = ASG.ENO Communication Paris assignments
Network Boston employees
AND PAY.TITLE = EMP.TITLE
Boston projects
Boston employees
Boston assignments
Montreal
New
Montreal projects
York Paris projects
Boston projects New York projects
New York employees with budget > 200000
New York projects Montreal employees
New York assignments Montreal assignments

Distributed Database - User View
Distributed Database

Distributed DBMS - Reality
User
Query
User
DBMS
Application
Software
DBMS
Software
DBMS Communication
Software Subsystem
User
DBMS User Application
Software Query
DBMS
Software
User
Query

Types of Transparency
◼ Data independence
◼ Network transparency (or distribution transparency)
❑ Location transparency
❑ Fragmentation transparency
◼ Fragmentation transparency
◼ Replication transparency

Reliability Through Transactions
◼ Replicated components and data should make distributed

DBMS more reliable.
◼ Distributed transactions provide
Concurrency transparency
❑
❑ Failure atomicity
• Distributed transaction support requires implementation of

❑ Distributed concurrency control protocols
❑ Commit protocols
◼ Data replication
❑ Great for read-intensive workloads, problematic for updates
❑ Replication protocols

Potentially Improved Performance
◼ Proximity of data to its points of use
❑ Requires some support for fragmentation and replication
◼ Parallelism in execution
❑ Inter-query parallelism
❑ Intra-query parallelism

Scalability
◼ Issue is database scaling and workload scaling
◼ Adding processing and storage power
◼ Scale-out: add more servers
❑ Scale-up: increase the capacity of one server → has limits

Outline
◼ Introduction
❑
❑ Design issues
❑

Distributed DBMS Issues
◼ Distributed database design

❑ How to distribute the database
❑ Replicated & non-replicated database distribution
❑ A related problem in directory management
◼ Distributed query processing

❑ Convert user transactions to data manipulation instructions
❑ Optimization problem
◼ min{cost = data transmission + local processing}
❑ General formulation is NP-hard

◼ Distributed concurrency control

❑ Synchronization of concurrent accesses
❑ Consistency and isolation of transactions' effects
❑ Deadlock management
◼ Reliability
❑ How to make the system resilient to failures
❑ Atomicity and durability

◼ Replication
❑ Mutual consistency
❑ Freshness of copies
❑ Eager vs lazy
❑ Centralized vs distributed
◼ Parallel DBMS
❑ Objectives: high scalability and performance
❑ Not geo-distributed
❑ Cluster computing

Related Issues
◼ Alternative distribution approaches

❑ Modern P2P
❑ World Wide Web (WWW or Web)
◼ Big data processing
❑ 4V: volume, variety, velocity, veracity
❑ MapReduce & Spark
❑ Stream data
❑ Graph analytics
❑ NoSQL
❑ NewSQL
❑ Polystores

Outline
◼ Introduction
❑
❑ Distributed DBMS architecture

DBMS Implementation Alternatives

Dimensions of the Problem
◼ Distribution
❑ Whether the components of the system are located on the same machine or
not
◼ Heterogeneity
❑ Various levels (hardware, communications, operating system)
❑ DBMS important one
◼ data model, query language,transaction management algorithms
◼ Autonomy
❑ Not well understood and most troublesome
❑ Various versions
◼ Design autonomy: Ability of a component DBMS to decide on issues related to its
own design.
◼ Communication autonomy: Ability of a component DBMS to decide whether and
how to communicate with other DBMSs.
◼ Execution autonomy: Ability of a component DBMS to execute local operations in
any manner it wants to.

Client/Server Architecture

Advantages of Client-Server
Architectures
◼ More efficient division of labor
◼ Horizontal and vertical scaling of resources
◼ Better price/performance on client machines
◼ Ability to use familiar tools on client machines
◼ Client access to remote data (via standards)
◼ Full DBMS functionality provided to client workstations
◼ Overall better system price/performance

Database Server

Distributed Database Servers

Peer-to-Peer Component Architecture

MDBS Components & Execution

Mediator/Wrapper Architecture

Cloud Computing
On-demand, reliable services provided over the Internet in

a cost-efficient manner
◼ IaaS – Infrastructure-as-a-Service
◼ PaaS – Platform-as-a-Service
◼ SaaS – Software-as-a-Service
◼ DaaS – Database-as-a-Service

Simplified Cloud Architecture

DDBS Design
data fragmentation
Tadeusz Morzy
1
Distributed DB Design
Top-down approach:
• have a database
• how to split and allocate to individual sites
Multi-databases (or bottom-up):

• combine existing databases
• how to deal with heterogeneity & autonomy
2
Two issues in top-down design
• Fragmentation
• Allocation
Note: issues not independent, but studied

separately for simplicity.
3
Example
Employee relation E (#,name,loc,sal,…)
40% of queries: 40% of queries:
Qa: select * Qb: select *
from E from E
where loc=Sa where loc=Sb
and… and ...
Motivation: Two sites: Sa, Sb

Qa  Sa Qb  Sb
4
# Name Loc Sal
5 Joe Sa 10
E 7 Sally Sb 25
8 Tom Sa 15
..
.. F = {F1,F2}
5 Joe Sa 10 7 Sally Sb 25
8 Tom Sa 15 At Sb
..
At Sa
..
F1 = loc=Sa(E) F2 = loc=Sb(E)
 primary horizontal fragmentation 5

Horizontal partitioning techniques
• Round robin
• Hash partitioning
• Range partitioning
6
Round robin
R F0 F1 F2
t1 t1
t2 t2
t3 t3
t4 t4
... t5
• Evenly distributes data
• Good for scanning full relation
• Not good for point or range queries
7
Hash partitioning
R F0 F1 F2
t1h(k1)=2 t1
t2h(k2)=0 t2
t3h(k3)=0 t3
t4h(k4)=1 t4
...
• Good for point queries on key; also for joins

• Not good for range queries; point queries not on key
• Good hash function even distribution
8
Range partitioning
R F0 F1 F2
t1: A=5 partitionin
g t1
t2: A=8 vector t2
t3: A=2 4 7 t3
t4: A=3 V0 V1 t4
...
• Good for some range queries on A
• Need to select good vector: else create imbalance
 data skew
 execution skew
9
Fragmentation
• Horizontal Primary
depends on local attributes
R Derived
depends on foreign relation
• Vertical
R
10 10
Which are good fragmentations?
Example 1: F = {F1,F2}
F1 = sal<10(E) F2 = sal>20(E)
Problem: Some tuples lost!
Example 2: F = {F1,F2}
F1 = sal<10(E) F2 = sal>5(E)
Tuples with 5 < sal < 10 are duplicated

11
Prefer to deal with replication explicitly
Example: F = { F5, F6, F7 }
F5 = sal<=5(E)
F6 = 5 < sal<10(E)
F7 = sal>=10(E)
Then replicate F6 if desired as part of allocation
12
Horizontal Fragmentation Desiderata
R  F = {F1,F2,….}
(1) Completeness
t  R,  Fi  F such that t  Fi
(2) Disjointness
Fi  Fj = Ø,  i,j such that i  j
(3) Reconstruction
i
  such that R =  Fi
13
Generating horizontal fragments
• Given simple predicates Pr = {p1, p2,.. pm} and
relation R.
• Generate “minterm” predicates
M = {m | m =  pk*, 1  k  m}, where
pk* is either pk or ¬ pk
• Eliminate useless minterms and simplify M to
get M’.
• Generate fragments m(R) for each m  M’.
14
5 < A < 10
Example
• Example: say queries use predicates
A < 10, A > 5, Loc = SA, Loc = SB
• Eliminate and simplify minterms

A < 10  A > 5  Loc = SA  Loc = SB
A < 10  A > 5  Loc = SA  ¬(Loc = SB)
• Final set of fragments Work out details

for all minterms.
(5 < A < 10)  (Loc = SA)
(5 < A < 10)  (Loc = SB)
(A  5)  (Loc = SA)
(A  5)  (Loc = SB)
(A  10)  (Loc = SA)
(A  10)  (Loc = SB)
15
More on Horizontal Fragmentation
• Elimination of useless fragments/predicates
depends on application semantics:
– e.g.: if Loc  SA and  SB is possible, must retain
fragments such as (5 <A < 10)  (LocSA)  (LocSB)
• Minterm-based fragmentation generates

complete, disjoint, and reconstructible
fragments.
Justify this
statement.
16
Choosing simple predicates
• E (#,name,loc,sal,…) with common queries
Qa: select * from E where loc = SA and…
Qb: select * from E where loc = SB and…
Qc: select * from E where sal < 10 and…
• Three choices for Pr and hence F[Pr]:
– Pr = {} F1 = F[Pr] = {E}
– Pr = {Loc = SA, Loc = SB}
F2 = F[Pr] = {loc=SA (E), loc=SB (E)}
– Pr = {Loc = SA, Loc = SB, Sal < 10}
F3 = F[Pr] = {loc=SA  sal< 10(E),  loc=SB  sal< 10(E),
loc=SA  sal  10(E), loc=SA  sal  10 (E)}
17
Loc=SA  Qa: Select … loc = SA ...
sal < 10
Qb: Select … loc = SB ...
Loc=SA 
sal  10
F2 F3
F1 Loc=SB 
Prefer F2 to F1 and F3
sal < 10
Loc=SB 
sal  10
18
Desiderata for simple predicates
Different from completeness
• Completeness of fragmentation
Set of predicates Pr is complete if for every

Fi  F[Pr], every t  Fi has equal probability
of access by every major application.
• Minimality
Set of predicates Pr is minimal if no Pr’  Pr
is complete.
To get complete and minimal Pr use predicates that are

“relevant” in frequent queries 19
Derived horizontal fragmentation
• Example: Two relations Employee and Projects
E(#, NAME, SAL, LOC)
J(#, DES,…)
• Fragment E into {E1, E2} by LOC
• Common query:
“Given employee name, list projects (s)he works in”
20
# NM Loc Sal # NM Loc Sal
E1 5 Joe Sa 10
E2 7 Sally Sb 25
8 Tom Sa 15 12 Fred Sb 15
… …
(at Sa) (at Sb)
J #
5
Description
datawarehouse
7 Operational res.
5 data mining
12 Software eng.
…
21
# NM Loc Sal # NM Loc Sal
E1 5 Joe Sa 10
E2 7 Sally Sb 25
8 Tom Sa 15 12 Fred Sb 15
… …
(at Sa) (at Sb)
# Des # Des
J1 5 datawarehouse J2 7 Operational res.
5 data mining 12 Software eng.
… …
J1 = J E1 J2 = J E2
22
Derived horizontal fragmentation (1)
R, fragmented as F = {F1, F2, …, Fn}

S, derive D = {D1, D2, …, Dn} where Di =S Fi
Convention: R is called the owner relation

S is called the member relation
23
• Defined on a member relation (referential
integrity constraint) of a link according to a
selection operation specified on its owner.
– Each link is an equijoin
– Equijoin can be implemented by means of
semijoins
24
It may happen that there are more than two links into a relation R – so, there is
more than one possible derived horizontal fragmentation of R
Skill
Title, Sal
Proj
L1
Emp PNO, Pname, Budget, Loc
ENO, Ename, Title

L3
L2
ASG
ENO, PNO, Resp, Duration
25
Completeness of derived fragmentation
# Des
Example: Say J is
…
33 distributed dbms
…
• J1 U J2  J (incomplete fragmentation)
• For completeness, enforce referential
integrity constraint
join attribute of member relation

join attribute of owner relation
26
E1
# NM Loc Sal E2 # NM Loc Sal
5 Joe Sa 10 5 Fred Sb 20
… …
J #
5
Description
web mining
Fragmentation
is not
…
disjoint!
J1 # Description
J2
#
5
Description
web mining
5 web mining
… …
Common way to enforce disjointness: make join

attribute key of owner relation.
27
Vertical fragmentation
• Has been studied within the centralized
context
– Design methodology
– Physical clustering
• More difficult than horizontal, because more
alternatives exist. Two approaches:
– Grouping
• Attributes to fragments
– Splitting
• Relation to fragments
28
E
# NM Loc Sal
Example:
5 Joe Sa 10
7 Sally Sb 25
8 Fred Sa 15
…
E1
#
5
NM
Joe
Loc
Sa
E2 #
5
Sal
10
7 Sally Sb 7 25
8 Fred Sa 8 15
… …
R[T]  R1[T1], R2[T2],…, Rn[Tn] Ti  T

 Just like normalization of relations 29
• Overlapping Fragments
– Grouping
• Non-overlapping Fragments
– Splitting
• We do not consider the replicated key attributes to
be overlapping
• Advantage:
– Easier to enforce functional dependencies
30
Properties
R[T]  Ri[Ti], i = 1.. n
• Completeness: Ti = T
• Reconstruction: Ri = R (lossless join)

– One way to guarantee lossless join: repeat key in
each fragment, i.e., key  Ti  i
• Disjointness: Ti  Tj = {key}
– Check disjointness only on non-key attributes
31
Grouping Attributes
E1(#,NM,LOC)
E2(#,SAL)
Example:
E(#,NM,LOC,SAL) E1(#,NM)
E2(#,LOC)
E3(#,SAL)
…..
Which is the right vertical fragmentation?
32
Vertical fragmentation – Information
Requirements
• Application Information
– Attribute affinities
• A measure that indicates how closely related the
attributes are
• This is obtained from more primitive usage data
– Attribute usage values
• Given a set of queries Q={q1, q2, …, qk) that will run on
the relation R[A1, A2, …, An]
• Use (qi, Aj) = 1 if Aj is referenced by qi, 0 otherwise
33
VF – Definition of use(qi,Aj)
• Consider the following 4 queries for PROJ
SELECT BUDGET SELECT PNAME, BUDGET
FROM PROJ FROM PROJ
WHERE PNO=Value
SELECT PNAME SELECT SUM (BUDGET)

FROM PROJ FROM PROJ
WHERE LOC=Value WHERE LOC=Value
• Let A1=PNO, A2=PNAME, A3=BUDGET, A4=LOC

A1 A2 A3 A4
q1 1 0 1 0
q2 0 1 1 0
q3 0 1 0 1
q4 0 0 1 1
34
VF – Affinity Measure aff(Ai,Aj)
• The attribute affinity measure (miara powinowactwa)
between two attributes Ai and Aj of a relation R with
respect to the set of applications Q={q1, q2, ..., qk} is
defined as follows:
𝑎𝑓𝑓 𝐴𝑖, 𝐴𝑗 = (𝑞𝑢𝑒𝑟𝑦 𝑎𝑐𝑐𝑒𝑠𝑠)

𝑎𝑙𝑙 𝑞𝑢𝑒𝑟𝑖𝑒𝑠 𝑡ℎ𝑎𝑡 𝑎𝑐𝑐𝑒𝑠𝑠 𝐴𝑖 𝑎𝑛𝑑 𝐴𝑗
query access = 𝑎𝑙𝑙 𝑠𝑖𝑡𝑒𝑠 𝑎𝑐𝑐𝑒𝑠𝑠_𝑓𝑟𝑒𝑞_𝑜𝑓_𝑎_𝑞𝑢𝑒𝑟𝑦 * access/execution
35
Calculation of aff(Ai, Aj) (1)
Assume each query in the S1 S2 S3

previous example accesses the q1 15 20 10
attributes once during each
execution. q2 5 0 0
Also assume the access q3 25 25 25
frequencies as follows: 3 0 0
q4
Then
aff(A1, A3) = 15*1 +20*1+10*1
= 45
36
Calculation of aff(Ai, Aj) (2)
The attribute affinity matrix AA is:
A1 A2 A3 A4
A1 45 0 45 0
A2 0 80 5 75
A3 45 5 53 3
A4 0 75 3 78
37
Attribute affinity matrix
A1 A2 A3 A4 A5 Cluster attributes
A1 78 50 45 1 0 based on affinity
A2 50 25 28 2 0
A3 45 28 34 0 4
A4 1 2 0 20 75
R1[K,A1,A2,A3]
A5 0 0 4 75 40 R2[K,A4,A5]
• Ai,j  a measure of how “often” Ai and Aj

are accessed by the same query
• Hand constructed using knowledge of queries and
their frequencies 38
VF – Clustering Algorithm
• Take the attribute affinity matrix AA and reorganize
the attribute orders to form clusters where the
attributes in each cluster demonstrate high affinity
to one another.
• Bond Energy Algorithm (BEA) has been used for
clustering of entities. BEA finds an ordering of
entities (in our case attributes) such that the global
affinity measure is maximized.
n n
AM  
i j
(affinity of Ai and Aj with their neighbors)
39
Bond Energy Algorithm
• BEA is considered appropriate for clustering
attributes since:
– It is designed specifically to determine groups of similar
items (i.e. it clusters attributes with larger affinity values
together)
– The final groupings are insensitive to the order in which
items are presented to the algorithm
– The complexity of the algorithm is O(n2), where n is the
number of attributes
– The maximization function considers the nearest neighbors
only
40
n n
AM   aff(A , A ) [aff (A , A
i j
i j i j-1) + aff(Ai, Aj+1) +
+ aff(Ai-1, Aj) + aff(Ai+1, Aj)]

where
aff(A0, Aj) = aff (Ai, A0) = aff(An+1, Aj) = aff(Ai, An+1) = 0

Since the AA matrix is symmetric, the objective function
AM reduces to:
n n
AM   aff(A , A ) [aff (A , A
i j
i j i j-1) + aff(Ai, Aj+1)]
41
Input: The AA matrix
Output: The clustered affinity matrix CA which is a
perturbation of AA
 Initialization: Place and fix one of the columns of AA in CA.
 Iteration: Place the remaining n-i columns in the remaining i+1
positions in the CA matrix. For each column, choose the
placement that makes the most contribution to the global
affinity measure.
 Row order: Order the rows according to the column ordering.
42
“Best” placement?
n n
AM   aff(A , A ) [aff (A , A
i j
i j i j-1) + aff(Ai, Aj+1)]
n n n
AM    aff(A , A ) aff (A , A ) + aff(A , A ) aff(A , A
j i
i j i j-1
i
i j i j+1)
Let us define the bond between attrbutes Ax and Ay as:

n
bond(Ax,Ay) =  aff(Az,Ax)aff(Az,Ay)
z 1
43
Then, the objective function AM can be written as:
𝑛
AM = [𝑏𝑜𝑛𝑑 𝐴𝑗, 𝐴𝑗 − 1 + 𝑏𝑜𝑛𝑑 𝐴𝑗, 𝐴 𝑗 + 1 ]

𝑗=1
Consider the following n attributes:
A1 A2 … Ai-1 Ai Aj Aj+1 … An
The global AM for these attributes is AMold
44
• Now, consider placing a new attrbute Ak between Ai
and Aj in the clustered affinity matrix:
AMnew = AMold + 2bond(Ai, Ak)+2bond(Ak, Aj) –

2bond(Ai, Aj)
• Thus, the net contribution to the global affinity
measure of placing the attribute Ak between Ai and
Aj is:
cont(Ai, Ak, Aj) = 2bond(Ai, Ak)+2bond(Ak, Aj) –

2bond(Ai, Aj)
45
Example (1)
Consider the following AA matrix and the corresponding CA
matrix where A1 and A2 have been placed. Place A3:
46
Example (2)
Ordering (0-3-1) :
cont(A0,A3,A1) = 2bond(A0 , A3)+2bond(A3 , A1)–2bond(A0 , A1)
= 2* 0 + 2* 4410 – 2*0 = 8820
Ordering (1-3-2) :
cont(A1,A3,A2) = 2bond(A1 , A3)+2bond(A3 , A2)–2bond(A1,A2)
= 2* 4410 + 2* 890 – 2*225 = 10150
Ordering (2-3-4) :
cont (A2,A3,A4) = 1780
47
Example (3)
A 1 A3 A2
• Therefore, the CA matrix has the form
45 45 0
0 5 80
45 53 5
0 3 75
• When A4 is placed, the final form of the CA matrix (after
row organization) is A1 A3 A2 A4
A1 45 45 0 0
A3 45 53 5 3
A2 0 5 80 75
A4 0 3 75 78
48
VF – Algorithm
How can you divide a set of clustered attributes {A1, A2, …, Am}
into two (or more) sets {A1, A2, …, Ai} and {Ai+1, …, Am} such that
there are no (or minimal) applications that access both (or
more than one) of the sets.
A1 A2 A3 … Ai Ai+1 . . .Am
A1
A2
TA
Ai
Ai+1
BA
Am
49
VF – Algorithm
Define
TQ = set of applications that access only TA
BQ = set of applications that access only BA
OQ = set of applications that access both TA and BA
and
CTQ = total number of accesses to attributes by
applications that access only TA
CBQ = total number of accesses to attributes by
applications that access only BA
COQ = total number of accesses to attributes by
applications that access both TA and BA
Then find the point along the diagonal that maximizes
CTQCBQCOQ2
50
VF – Algorithm
Two problems :
• Cluster forming in the middle of the CA matrix
– Shift a row up and a column left and apply the algorithm to find
the “best” partitioning point
– Do this for all possible shifts
– Cost O(m2)
• More than two clusters
– m-way partitioning
– try 1, 2, …, m–1 split points along diagonal and try to find the best
point for each of these
– Cost O(2m)
51
Hybrid Fragmentation
R
HF HF
R1 R2
VF VF VF VF VF
R11 R12 R21 R22 R23
52
Hybrid Fragmentation
• Horizontal fragmentation of vertical fragments

• Vertical fragmentation of horizontal fragments
53
DDBS Design
Data Allocation
Tadeusz Morzy
Fragment Allocation
• Problem Statement
Given
F = {F1, F2, …, Fn} fragments
S ={S1, S2, …, Sm} network sites
Q = {q1, q2,…, qq} applications
Find the "optimal" distribution of F to S.
• Optimality
– Minimal cost
• Communication + storage + processing (read & update)
• Cost in terms of time (usually)
– Performance
Response time and/or throughput
– Constraints
• Per site constraints (storage & processing)
2
Types of DDBSs
• Centralized database system
• Non-replicated distributed database system

• Fully replicated distributed database system
• Partially replicated distributed database system
3
Problem (1)
Update processing cost vs query processing cost
cost
• update cost
• read cost
• storage cost
number of replicas
4
Problem (2)
File Allocation (FAP) vs Database Allocation (DAP):
– Fragments are not individual files
• relationships have to be maintained
– Access to databases is more complicated

• remote file access model not applicable
• relationship between allocation and query processing
– Cost of integrity enforcement should be considered

– Cost of concurrency control should be considered
5
Problem (3)
• Solution Methods
– FAP is NP-complete
– DAP also NP-complete
• Heuristics based on
– knapsack problem
– branch and bound techniques
– linear programming techniques
6
Information Requirements (1)
• Database information
– global conceptual schema
– fragmentation schema
– selectivities and sizes of fragments
– security: authorization
– recovery & back-up: frequency and volums
– Integrity constrains
• Application information
– transaction types and their frequencies
– access localities
7
Information Requirements (2)
• Computer system information:
– unit cost of storing data at a site
– unit cost of processing at a site
– concurrency control algorithms
– data producers and consumers
• Communication network information
– network topology
– bandwidth of communication channels
– latency
– communication overhead (communication cost)
8
Allocation – Information Requirements
• Database Information
– selectivity of fragments
– size of a fragment
• Application Information
– number of read accesses of a query to a fragment
– number of update accesses of query to a fragment
– a matrix indicating which queries updates which fragments
– a similar matrix for retrievals
– originating site of each query
• Site Information
– unit cost of storing data at a site
– unit cost of processing at a site
• Network Information
– communication cost/frame between two sites
– frame size
9
Evaluation Criteria
• Criteria
– response time (mean response time)
– throughput (total response time or total cost)
• General form of the criterion:
min(Total Cost)
where Total Cost (C):
C = C COMM + C PROC + CSTOR
10
Notation
• Decision variable
1 if fragment Fi is stored at site Sj

Rij 
0 otherwise
11
Notation
• i – index of a fragment
• j – index of a site
• k – index of an application
• fkj denotes the frequency of kth application at jth site
• rki denotes the number of read references (reads) of
kth application of ith fragment
• uki denotes the number of update references
(updates) of kth application of ith fragment
nki=rki+uki
12
Simple Data Allocation Heuristics
• Best Fit
• All Beneficial Sites
• Progressive Fragment Allocation
13
Best Fit (BF) Strategy
• BF is dedicated for non-replicated DDBS
• BF determines a site at which a given fragment
should be stored (allocated)
• Basic evaluation criterion – sum of local references
(read and update references) of the fragment at all
sites
max  (local read and update references)
• Relation (fragment) Ri is allocated to the site Sj where
the sum of local read and update references is the
largest:
Rij = max  fkj nki
14
BF – Example (1)
• Assume each fragment is a relation
• Given mean read and update local (remote)
access times to each relation (database
information)
Database information
Relation Size Mean local read Mean remote
accesss (update) read access
in ms (update) in ms
R1 300 KB 100 (150) 500 (600)
R2 500 KB 150 (200) 650 (700)
R3 1 MB 200 (250) 1000 (1100)
15
BF – Example (2)
Application information
Trans. Site Frequency N. of references
T1 S1,S4,S5 1 4 to R1 (3 r, 1 u)
2 to R2 (2 r)
T2 S2,S4 2 2 to R1 (2r)
4 to R3 (3 r, 1 u)
T3 S3,S5 3 4 to R2 (3 r, 1 u)
2 to R3 (2 r)
r means read, u means update
16
BF – Example (3)
Calculations of local references
Relation Site Trans. T1 Trans. T2 Trans. T3 Sum of
referen.
R1 S1 3r 0 0 4
1 u (1)
S2 0 2 r (2) 0 4
S3 0 0 0 0
S4 3r 2 r (2) 0 8 (max)
1 u (1)
S5 3r 0 0 4
1 u (1)
17
BF – Example (4)

referen.
R2 S1 2 r (1) 0 0 2
S2 0 0 0 0
S3 0 0 3r 12
1 u (3)
S4 2 r (1) 0 0 2
S5 2 r (1) 0 3r 14 (max)
1 u (3)
18
BF – Example (5)

referen.
R3 S1 0 0 0 0
S2 0 3r 0 8 (max)
1 u (2)
S3 0 0 2 r (3) 6
S4 0 3r 0 8 (max)
1 u (2)
S5 0 0 2 r (3) 6
19
BF – Example (6)
T1
T1, T3 S1
R2 S5
T2
comm.
medium S2 R3
T1, T2
S4
T3
R1
S3
Advantage of BF – simplicity of calculations

Disadvantage of BF – precision and lack of replication
20
All Beneficial Sites (ABS)
• The algorithm determines all sites at which a given
fragment should be stored (allocated to)
• Relation Ri is allocated to a site Sj at which the cost of
read references (accesses) is greater than the cost of
update references (accesses) of the relation Ri from
all sites in the system
• Allocate Ri to a site Sj if the profit of storing Ri at Sj is
greater than the cost of storing and updating Ri at Sj
from the point of view of read processing
21
• The formula
Rij =  fkj rki - C   fkj uki  0
where C – a constant defining the cost ratio of the
write operation to the cost of the read operation for
a given relation
• The relation Ri is allocated to all sites Sj for
which Rij  0
22
• Profit of storing an additional copy of a fragment F at

site Sj – difference between the cost of remote query
processing of the fragment F from the site Sj (without
replication) and the cost of local query processing of
the fragment F at the site Sj times frequency of the
query at the site Sj.
• Cost of storing an additional copy of a fragment F at

site Sj – sum of costs of all local updates of the
fragment F at site Sj by transactions initiated at Sj plus
sum of costs of all remote updates of the fragment F at
site Sj by transactions initiated at other sites
23
ABS – Example (Input data)

R1 300 KB 100 (150) 500 (600)
R2 500 KB 150 (200) 650 (700)
R3 1 MB 200 (250) 1000 (1100)
T1 S1,S4,S5 1 4 to R1 (3 r, 1 u)
2 to R2 (2 r)
T2 S2,S4 2 2 to R1 (2r)
4 to R3 (3 r, 1 u)
T3 S3,S5 3 4 to R2 (3 r, 1 u)
2 to R3 (2 r)
24
ABS – Example (1)
Rel. Site Remote (local) no. of updates. * Cost

updates frequency * time
R1 S1 T1 from S4, S5 (1+1)*1*600+1*1*150 1350
(T1 from S1)
S2 T1 from S1, S4, S5 (1+1+1)*1*600 1800
S3 T1 from S1, S4, S5 (1+1+1)*1*600 1800
S4 T1 from S1, S5 (1+1)*1*600+1*1*150 1350
(T1 from S4)
S5 T1 from S1, S4 (1+1)*1*600+1*1*150 1350
(T1 from S5)
25
ABS – Example (2)
Rel. Site Remote (local) No. of updates * Cost

R2 S1 T3 from S3, S5 2*3*700 4200
S2 T3 from S3, S5 2*3*700 4200
S3 T3 from S5 1*3*700+1*3*200 2700
(T3 from S3)
S4 T3 from S3, S5 2*3*700 4200
S5 T3 from S3 1*3*700+1*3*200 2700
(T3 from S5)
26
ABS – Example (3)
Rel. Site Remote (local) No. of updates * Cost

R3 S1 T2 from S2, S4 2*2*1100 4400
S2 T2 from S4 1*2*1100+ 2700
(T2 from S2) 1*2*250
S3 T2 from S2, S4 2*2*1100 4400
S4 T2 from S2 1*2*1100+ 2700
(T2 from S4) 1*2*250
S5 T2 from S2, S4 2*2*1100 4400
27
ABS – Example (Input data)

R1 300 KB 100 (150) 500 (600)
R2 500 KB 150 (200) 650 (700)
R3 1 MB 200 (250) 1000 (1100)
T1 S1,S4,S5 1 4 to R1 (3 r, 1 u)
2 to R2 (2 r)
T2 S2,S4 2 2 to R1 (2r)
4 to R3 (3 r, 1 u)
T3 S3,S5 3 4 to R2 (3 r, 1 u)
2 to R3 (2 r)
28
ABS – Example (4)
Rel. Site query no. of reads * frequency * Profit
(remote-local) time
R1 S1 T1 from S1 3*1*(500-100) 1200

S2 T2 from S2 2*2*(500-100) 1600
S3 - 0 0
S4 T1, T2 from S4 (3*1+2*2)* 2800
(500-100)
S5 T1 from S5 3*1*(500-100) 1200
R2 S1 T1 from S1 2*1*(650-150) 2800

S2 - 0 0
S3 T3 from S3 3*3*(650-150) 4500
S4 T1 from S4 2*1*(650-150) 1000
S5 T1, T3 from S5 (2*1+3*3)* 5500
(650-150)
R3 S1 - 0 0
S2 T2 from S2 3*2*(1000-200) 4800
S3 T3 from S3 2*3*(1000-200) 4800
S4 T2 from S4 3*2*(1000-200) 4800
S5 T3 from S5 2*3*(1000-200) 4800
29
ABS – Example (5)
Relation Site Cost Profit
R1 S1 1350 1200
S2 1800 1600
S3 1800 0
S4 1350 2800
S5 1350 1200
R2 S1 4200 1000
S2 4200 0
S3 2700 4500
S4 4200 1000
S5 2700 5500
R3 S1 4400 0
S2 2700 4800
S3 4400 4800
S4 2700 4800
S5 4400 4800
30
ABS – Example (6)
T1
T1, T3 S1
R2,R3 S5
T2
S2 R3
T1, T2
S4
T3
R1,R3
S3
R2, R3
ABS takes into consideration the replication of fragments
31
(BF vs BAS)
Relation Site BF Site BAS

R1 S4 S4
R2 S5 S3, S5
R3 S2 S2, S3, S5
32
Progressive Fragment Allocation (PFA)
• Algorithm PFA is the extension of ABS algorithm

• Idea: we calculate the profit following from the
allocation of a new copy of the fragment Ri at a given
site in terms of increased reliability and availability of
data
33
Progressive Fragment Allocation (PFA)
• Let di denotes the degree of redundancy of a
fragment Ri (number of copies) and let Fi denotes a
profit following from the full replication of the
fragment Ri at all sites of the system
• Profit measure is defined as the function (di):
(di) = (1 - 21-di) * Fi
• Notice that (1) = 0, (2) = Fi/2, (3) = 3* Fi/4
• Profit of storing additional copy Ri at site Sj is defined
as follows:
Rij =  fkj rki - C   fkj uki + (di)
34
Distributed Databases
Fragmentation vs Query optimization
Lecture 1
1
Query Processing Steps
• Decomposition
– Given SQL query, generate one or more algebraic query
trees
• Localization
– Rewrite query trees, replacing relations by fragments
• Optimization
– Given cost model + one or more localized query trees
– Produce minimum cost query execution plan
2
Decomposition (1)
Input : Calculus query on global relations
• Normalization
– manipulate query quantifiers and qualification
• Semantic analysis
– detect and reject “incorrect” queries
– possible for only a subset of relational calculus
• Simplification
– eliminate redundant predicates
• Restructuring
– calculus query  algebraic query
– more than one translation is possible
– use transformation rules
3
Decomposition (2)
• Same as in a centralized DBMS
• Normalization (usually into relational algebra)
Select A,C
from R Natural Join S
where (R.B = 1 and S.D = 2) or (R.C > 3 and S.D = 2)
 (R.B = 1 v R.C > 3)  (S.D = 2)

Conjunctive
normal
form
R S
4
Decomposition (3)
• Lexical and syntactic analysis
– check validity (similar to compilers)
– check for attributes and relations
– type checking on the qualification
• Put into normal form

– Conjunctive normal form
(p11 p12  …  p1n)  …  (pm1  pm2  …  pmn)
– Disjunctive normal form
(p11  p12  …  p1n)  …  (pm1  pm2  …  pmn)
– OR's mapped into union
– AND's mapped into join or selection
5
Decomposition (4)
• Redundancy elimination (simplification)
(S.A = 1)  (S.A > 5)  False
(S.A < 10)  (S.A < 5)  S.A < 5
• Algebraic Rewriting
– Example: pushing conditions down

cond3
 cond
 cond1  cond2
S T S T 6
Algebraic Rewriting (1)
• Convert relational calculus to relational
algebra
• Make use of query trees
• Example
Find the names of employees other than J.
Doe who worked on the CAD/CAM project
for either 1 or 2 years.
SELECT ENAME
FROM EMP, ASG, PROJ
WHERE EMP.ENO = ASG.ENO
AND ASG.PNO = PROJ.PNO
AND ENAME≠ "J. Doe"
AND PNAME = "CAD/CAM"
AND (DUR = 12 OR DUR = 24)
7
Algebraic Rewriting - example
ENAME Project
σDUR=12 OR DUR=24
σPNAME=“CAD/CAM” Select
σENAME≠“J. DOE”
⋈PNO
⋈ENO Join
PROJ ASG EMP 8

Algebraic Rewriting Rules (1)
• Commutativity of binary operations
R×SS×R
R ⋈S  S ⋈R
RSSR
• Associativity of binary operations

( R × S) × T  R × (S × T)
(R ⋈S) ⋈T  R ⋈ (S ⋈T)
• Idempotence of unary operations

A’( A’(R))   A’(R)
p1(A1)(p2(A2)(R))  p1(A1)p2(A2)(R)
• Commuting selection with projection

A’(p1(A’’)(R))  p1(A’’)(A’(R)), where A' ' A'  A 9
Algebraic Rewriting Rules (2)
• Commuting selection with binary operations
p(A)(R × S)  (p(A) (R)) × S
p(Ai)(R ⋈(Aj,Bk)S)  (p(Ai) (R)) ⋈(Aj,Bk)S
p(Ai)(R  T)  p(Ai) (R)  p(Ai) (T)
where Ai belongs to R and T
• Commuting projection with binary operations
C(R × S)  A’(R) × B’(S)

C(R ⋈(Aj,Bk)S)  A’(R) ⋈(Aj,Bk) B’(S)
C(R  S)  C(R)  C(S)
where R[A] and S[B]; C = A'  B' where A'  A, B'  B
10
Example
Recall the previous example:

Find the names of employees other than J. Doe who
worked on the CAD/CAM project for either one or
two years.
SELECT ENAME
FROM PROJ, ASG, EMP
WHERE ASG.ENO=EMP.ENO
AND ASG.PNO=PROJ.PNO
AND ENAME ≠ "J. Doe"
AND PROJ.PNAME="CAD/CAM"
AND (DUR=12 OR DUR=24)
11
Example
ENAME Project
DUR=12  DUR=24
PNAME=“CAD/CAM” Select
ENAME≠“J. DOE”
⋈PNO
⋈ENO Join
PROJ ASG EMP

12
Example
ENAME
⋈PNO
PNO,ENAME
⋈ENO
PNO
PNO,ENO PNO,ENAME
PNAME = "CAD/CAM"
DUR =12DUR=24 ENAME ≠ "J. Doe"
PROJ ASG EMP

13
Localization Steps
1. Start with query tree
2. Replace relations by fragments
3. Push  up & , down (rewriting rules)
4. Simplify – eliminating unnecessary operations
Note: To denote fragments in query trees

[R: cond]
Relation that fragment belongs to Condition its tuples satisfy
14
Example 1
E=3
E=3 
R
[R: E<10] [R: E  10]

E=3 E=3 E=3
[R: E<10]
[R: E<10] [R: E  10]
15
Example 2
A
A
R S
 
[R: A<5] [R: 5  A  10] [R: A>10] [S: A<5] [S: A  5]

R1 R2 R3 S1 S2
16

A A A A
A A
R1 S1 R1 S2 R2 S1 R2 S2 R3 S1 R3 S2
A A A
[R:A<5][S:A<5] [R:5A10] [S:A5] [R:A>10][S:A5]

17
Rules for Horiz. Fragmentation
• C1[R: C2]  [R: C1  C2]
• [R: False]  Ø
• [R: C1] [S: C2]  [R S: C1  C2  R.A = S.A]
A A
• In Example 1:
E=3[R2: E  10]  [R2: E=3  E  10]
 [R2: False]  Ø
• In Example 2:
[R: A<5] A [S: A  5]
 [R A S: R.A < 5  S.A  5  R.A = S.A]
 [R A S: False]  Ø
18
Example 3 – Derived Fragmentation
S’s fragmentation K
is derived from
that of R. R S
 
[R: A<10] [R: A  10] [S: K=R.K  R.A<10] [S: K=R.K  R.A10]
R1 R2 S1 S2 19

K K K K
R1 S1 R1 S2 R2 S1 R2 S2
K
K
[R: A<10] [S: K=R.K  R.A<10] [R: A  10] [S: K=R.K  R.A  10]
20
Example 4 – Vertical Fragmentation
A A
K
R
R1(K,A,B) R2(K,C,D)
A
A
K
K,A K,A
R1(K,A,B)
R1(K,A,B) R2(K,C,D)
21
Rule for Vertical Fragmentation
• Given vertical fragmentation of R(A):
Ri = Ai(R), Ai  A
• For any B  A:
B (R) = B [ Ri | B  Ai  Ø]
i
22
Parallel/Distributed Query Operations
• Sort
– Basic sort
– Range-partitioning sort
– Parallel external sort-merge
• Join
– Partitioned join
– Asymmetric fragment and replicate join
– General fragment and replicate join
– Semi-join programs
• Aggregation and duplicate removal
23
Parallel/distributed sort
• Input: relation R on
– single site/disk
– fragmented/partitioned by sort attribute
– fragmented/partitioned by some other attribute
• Output: sorted relation R

– single site/disk
– individual sorted fragments/partitions
24
Basic sort
• Given R(A,…) range partitioned on attribute A, sort R
on A
11
7 27
10 17 20
3 22
14
11
3 22
10 14 20
7 27
17
• Each fragment is sorted independently
• Results shipped elsewhere if necessary
25
Range partitioning sort
• Given R(A,….) located at one or more sites, not
fragmented on A, sort R on A
• Algorithm: range partition on A and then do basic sort
R1 Local sort
Ra R1s
a0
Rb Local sort
R2 R2s Result
a1
Local sort
R3 R3s
26
Selecting a partitioning vector
• Possible centralized approach using a “coordinator”
– Each site sends statistics about its fragment to coordinator
– Coordinator decides # of sites to use for local sort
– Coordinator computes and distributes partitioning vector
• For example,
– Statistics could be (min sort key, max sort key, # of tuples)
– Coordinator tries to choose vector that equally partitions
relation
27
Example
• Coordinator receives:
– From site 1: Min 5, Max 9, 10 tuples
– From site 2: Min 7, Max 16, 10 tuples
• Assume sort keys distributed uniformly within
[min,max] in each fragment
• Partition R into two fragments
3,6
2,5 What is k0?
5
10
1,1 5
10
5 7 9 16
k0 = 5/3,6 + 7 ~ 8,4 28
Variations
• Different kinds of statistics
– Local partitioning vector
Site 1
– Histogram # of tuples
3 4 3
5 6 8 10 local vector
• Multiple rounds between coordinator and sites
– Sites send statistics
– Coordinator computes and distributes initial vector V
– Sites tell coordinator the number of tuples that fall in
each range of V
– Coordinator computes final partitioning vector Vf
29
Parallel external sort-merge
• Local sort
• Compute partition vector
• Merge sorted streams at final sites
In order R1
Ra Local sort Ras a0
R2 Result
Rb Local sort Rbs
a1
R3
30
Parallel/distributed join
Input: Relations R, S
May or may not be partitioned
Output: R S
Result at one or more sites
31
Partitioned Join
Join attribute A Local join
Ra R1 S1 Sa
R2 S2
Rb Sb
R3 S3
f(A)
Result f(A)
Note: Works only for equi-joins

32
Partitioned Join
• Same partition function (f) for both relations
• f can be range or hash partitioning
• Any type of local join (nested-loop, hash, merge, etc.)
can be used
• Several possible scheduling options. Example:
– partition R; partition S; join
– partition R; build local hash table for R; partition S and join
• Good partition function important
– Distribute join load evenly among sites
33
Asymmetric fragment + replicate join
Join attribute A Local join
Ra R1 S Sa
R2 S
Rb Sb
R3 S
f union
Partition function
Result
• Any partition function f can be used (even round-robin)

• Can be used for any kind of join, not just equi-joins
34
General fragment + replicate join
Ra R1 R1
R2 Replicate R2
Rb m copies
Partition Rn Rn
Sa S1 S1
S2 Replicate S2
Sb n copies
Partition Sm Sm 35
R1 S1 R1 Sm
R2 S1 R2 Sm
All n x m pairings of
R,S fragments
Rn S1 Rn Sm
Result
•Asymmetric F+R join is a special case of general F+R.

•Asymmetric F+R is useful when S is small. 36
Semi-join programs
• Used to reduce communication traffic during join
processing
• R S = (R S) S
= R (S R)
= (R S) (S R)
37
A B Example A C
2 a 3 x
S R
10 b 10 y
25 c 15 z
30 d 25 w
32 x
Compute A(S) = [2,10,25,30]
S (R S)
R S = 10 y
25 w
• Using semi-join, communication cost = 4 A + 2 (A + C) + result

• Directly joining R and S, communication cost = 4 (A + B) + result
38
Comparing communication costs
• Say R is the smaller of the two relations R and S
• (R S) S is cheaper than R S if
size (A(S)) + size (R S) < size (R)
• Similar comparisons for other types of semi-joins
• Common implementation trick:
– Encode AS (or AR) as a bit vector
– 1 bit per domain of attribute A
001101000010100
39
n-way joins
• To compute R S T
– Semi-join program 1: R’ S’ T
where R’ = R S & S’ = S T
– Semi-join program 2: R’’ S’ T
where R’’ = R S’ & S’ = S T
– Several other options
• In general, number of options is exponential in
the number of relations
40
Other operations
• Duplicate elimination
– Sort first (in parallel), then eliminate duplicates in the result
– Partition tuples (range or hash) and eliminate duplicates
locally
• Aggregates
– Partition by grouping attributes; compute aggregates locally
at each site
41
Example
sum
Ra
# dept sal # dept sal dept sum
1 toy 10 1 toy 10 toy 50
2 toy 20 2 toy 20 mgmt 45
3 sales 15 5 toy 20
6 mgmt 15
8 mgmt 30
# dept sal
sum
Rb
4 sales 5
# dept sal dept sum
5 toy 20
3 sales 15 sales 30
6 mgmt 15
4 sales 5
7 sales 10
7 sales 10
8 mgmt 30
sum(sal) group by dept

42
Example
sum sum
# dept sal dept sum dept sum
Ra 1 toy 10 toy 30 toy 50
2 toy 20 toy 20 mgmt 45
3 sales 15 mgmt 45
# dept sal
sum
Rb 4
5
sales
toy
5
20
sum dept sum
sales 15
dept sum
sales 30
6 mgmt 15 sales 15
7 sales 10
8 mgmt 30
Does this work for all

kinds of aggregates?
Aggregate during partitioning to reduce communication cost
43
Query Optimization
• Generate query execution plans (QEPs)
• Estimate cost of each QEP ($,time,…)
• Choose minimum cost QEP
• What’s different for distributed DB?

– New strategies for some operations (semi-join, range-
partitioning sort,…)
– Many ways to assign and schedule processors
– Some factors besides number of IO’s in the cost model
44
Cost estimation
• In centralized systems - estimate sizes of
intermediate relations
• For distributed systems
– Transmission cost/time may dominate
Work T1 Work T2 answer
at site at site
Plan B
– Account for parallelism Plan A
50 IOs
70 IOs
100 IOs 20 IOs
– Data distribution and result re-assembly cost/time

45
Optimization in distributed DBs
• Two levels of optimization
• Global optimization
– Given localized query and cost function
– Output optimized (min. cost) QEP that includes relational and
communication operations on fragments
• Local optimization
– At each site involved in query execution
– Portion of the QEP at a given site optimized using techniques
from centralized DB systems
46
Search strategies
1. Exhaustive (with pruning)
2. Hill climbing (greedy)
3. Query separation
47
Exhaustive with Pruning
• A fixed set of techniques for each relational operator

• Search space = “all” possible QEPs with this set of
techniques
• Prune search space using heuristics
• Choose minimum cost QEP from rest of search
space
• Master site – makes all intersite decisions
• Apprentice sites – make local decisions
48
Example
|R|>|S|>|T| A B
R S T
R S T
R S RT S R S T T S T R
2 1 2 1
(S R) T (T S) R
Ship S Semi-join Ship Semi-join

to R T to S
1 Prune because cross-product not necessary

2 Prune because larger relation first 49
Hill Climbing
2
Initial plan
1 x
• Begin with initial feasible QEP

• At each step, generate a set S of new QEPs by applying
‘transformations’ to current QEP
• Evaluate cost of each QEP in S
• Stop if no improvement is possible
• Otherwise, replace current QEP by the minimum cost
QEP from S and iterate
50
Example
• Goal: minimize communication
R S T V
cost
R S T V • Initial plan: send all relations to

A B C
one site
To site 1: cost=20+30+40= 90
Rel. Site # of tuples To site 2: cost=10+30+40= 80
R 1 10 To site 3: cost=10+20+40= 70
S 2 20 To site 4: cost=10+20+30= 60
T 3 30
V 4 40 • Transformation: send a relation
to its neighbor
51
Local search
• Initial feasible plan
P0: R (1  4); S (2  4); T (3  4)
Compute join at site 4
• Assume following sizes: R S  20

S T5
T V1
52
No change 4
R S 20 cost = 30
10
cost = 30 1 R 2
4
10 20
R S 4 cost = 40
1 2
S R 20
20
1 2
S
Worse
53
Improvement
4
T S 5
cost = 35
30
cost = 50 2 3
T
4
S T
2
20 30 4 cost = 25
3
5 S T
20
2 S 3
Improvement
54
Next iteration
• P1: S (2  3); R (1  4);  (3  4)
where  = S T
Compute answer at site 4
• Now apply same transformation to R and 
4
 R
1  3
4
R 
4
1 3 R 
1 3
R 55
Query optimization in
distributed database systems
Lecture 2
Framework for query optimization
• The selection of a query processing strategy
involves:
– determining the physical copies of the fragments upon
which to execute the query
– selecting the order of the execution of operations,
particularly, this involves the determination of a „good”
sequence of joins
– selecting the method for executing each operation
2
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 vs ordered joins (merge join or hash join) 3
Cost-Based Optimization
• Solution space:
– The set of equivalent algebra expressions (query trees).
• Cost function (in terms of time):
– 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,…)
4
Search Space
▷◁
• Search space characterized by PNO
alternative execution ▷◁ PROJ
• Focus on join trees PNO
EMP ASG
• For N relations, there are O(N!)
equivalent join trees that can be
obtained by applying commutativity ▷◁
and associativity rules PNO
SELECT ENAME,RESP
▷◁ EMP
PNO
FROM EMP, ASG,PROJ
PROJ ASG
WHERE EMP.ENO=ASG.ENO
AND ASG.PNO=PROJ.PNO ▷◁
PNO
× ASG
PROJ EMP 5
Search Space
• Restrict by means of heuristics
– Perform unary operations before binary operations
– …
• Restrict the shape of the join tree
– Consider only linear trees, ignore bushy ones
6
Left-Deep Join Trees vs Bushy Trees
⋈
⋈ R4
⋈
⋈ R3 ⋈ ⋈
R1 R2 R1 R2 R3 R4
7
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, Tabu Search
8
Deterministic Strategy
⋈ ⋈ R4
⋈ R3 ⋈ R3
⋈ R1 R2 R1 R2
R1 R2
9
Randomized Strategy
⋈ ⋈
⋈ R3 ⋈ R2
R1 R2 R1 R3
10
Cost Function
• Total Time (or Total Cost)
– Reduce each cost (in terms of time) component
individually
– Optimizes the utilization of the resources
Increases system throughput
• Response Time
– Do as many things as possible in parallel
– May increase total time because of increased total
activity
11
Total Cost Factors
• Wide area network
– Message initiation and transmission costs high
– Local processing cost is low
– Ratio of communication to I/O costs = 20:1
• Local area networks
– Communication and local processing costs are more or
less equal
– Ratio = 1:1.6
12
Total Time vs Response Time
Site 1 x units
Site 3
Site 2 y units
Assume that only the communication cost is considered:
Total time = 2  message 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}

time to send x from 1 to 3 = message initialization time
+ unit transmission time * x
time to send y from 2 to 3 = message initialization time
+ unit transmission time * y 13
Transmission cost
• Transmission requirements are neutral with respect to
systems; they are typically a function of the amount of data
transmitted among sites
• The optimization of a distributed query can be partitioned
into two independent problems: the distribution of the
access strategy among sites, which is done considering
transmission only, and the determination of local access
strategies at each site, which use traditional methods of
centralized databases
• Transmission cost:
TC(X) = C0 + C1 * x
14
Database Profile
Database profile:
• The number of tuples in each relation Ri (card(Ri))
• The size of each attribute A (size(A) )
• The size of Ri (size(Ri)) is sum of the sizes of its attributes
• For each attribute A in each relation Ri: the number of
distinct values appearing in Ri (val(A[Ri])), max and min
LDBS1 LDBS2
Supply1 Supply2
Dept1 Dept2
15
Database Profile
Supply card(Supply)=50 000

SNUM PNUM DEPTNUM QUAN
size 6 7 2 10
val 3000 1000 30 500
Dept card(dept)= 30
16
Database Profile
Supply1 card(Supply1)=30 000 site(Supply1) = 1
Dept1 card(dept)= 10 site(Dept1) = 2
17
Profile of partial results of algebraic
operations - SELECTION
Let S denote the result of performing a unary relation over
a relation R
• Cardinality - to each selection we associate a selectivity
factor  which is the fraction of tuples satisfying it
In simple selection attribute = value (A=v),  can be
defined as follows:
 = 1/val(A[Ri])
under the assumptions that values are homogeneously
distributed. Thus
card(S) =  * card(R)
18
• Size: selection does not affect the size of relations
size(S) = size(R)
• Distinct values : depends on the selection criterion
Consider an attribute B which is not used in selection
formula. The determination of val(B[S]) may be as follows
Given n=card(R) - objects uniformly distributed over m =
val(B[R]) colors. How many different colors c= val(B[S])
are selected if we take just r objects?
19
• Yao approximation:
r, for r < m/2

c(n, m, r) = (r+m)/3 for m/2 < r < 2m
m, for r > 2m
c
m
m/2
r 20
m/2 2m
operations - PROJECTION
Let S denote the result of performing a unary relation over
a relation R
• Cardinality – projection affects the cardinality of
operands since duplicates are eliminated from the result.
This effect is difficult to evaluate, the following three rules
can be applied
– If the projection involves a single attribute A, set
card(S) = val(A[R])
– If the product  AiAttr(S) val(Ai[R]) is less than card(R), where
Attr(S) are the attributes in the result of the projection, set
card(S) =  AiAttr(S) val(Ai[R])
21
operations - PROJECTION
– If the projection includes a key of R, set
card(S) = card(R)
• Note that if the system does not eliminate duplicates, the
cardinality of the result is the same as the cardinality of the
operand relation
• Size: the size of the result of a projection is reduced to the
sum of the sizes of attributes in its specification
• Distinct values : the distinct values of projected attributes
are the same as in the operand relation
22
operations – GROUP BY
Let G denote the attributes on which the grouping is
performed, AF indicates the aggregate functions to be
evaluated
• Cardinality – we give an upper bound on the cardinality
of S:
card(S) <  AiG val(Ai[R])
• Size: for all attributes A appearing in G
size(R.A) = size (S.A)
• Distinct values : for all attributes A appearing in G
val(A[S]) = val(A[R])
23
operations – UNION
• Cardinality – an upper bound:
card(T) < card(R) + card(S)
lower bound: card(T) = max{card(R), card(S)}
Equality holds when duplicates are not eliminated
• Size: we have
size(T) = size(R) = size(S)
• Distinct values : an upper bound is
val(A[T]) < val(A[R]) + val(A[S])
lower bound: max{val(A[R]), val(A[S])}
24
operations – DIFFERENCE
• Cardinality – we have:
max(0, card(R)-card(S)) < card(T)
• Size: we have
size(T) = size(R) = size(S)
• Distinct values : an upper bound is
val(A[T]) < val(A[R])
25
operations – CARTESIAN PRODUCT
• Cardinality – we have:
card(T) < card(R) x card(S)
• Size: we have
size(T) = size(R) + size(S)
• Distinct values : the distinct values of attributes are the
same as in the operand relation
26
operations – JOIN
• Cardinality – estimating precisely the cardinality of T is
very complex; we can give an upper bound to card(T)
because card(T) < card(R) x card(S), but this value is
usually much higher than the actual cardinality. Assuming
that all the values of A in R appear also as values of B in S
and vice versa and that the two attributes are both
uniformly distributed over tuples of R and S, we have
card(T) = (card(R) x card(S))/val(A[R])
if one of the two attributes, say A, is a key of R, then
card(T) = card(S)
27
operations – JOIN
• Size: we have
size(T) = size(R) + size(S)
In the case of natural join the size of the join attribute must
be subtracted from the size of the result
• Distinct values : if A is a join attribute, an upper bound is
val(A[T]) < min(val(A[R]), val(B[S]) )
if A is not a join attribute, an upper bound is
val(A[T]) < val(A[R])
28
operations – SEMIJOIN
Consider the semijoin T=R SJ A=B S
• Cardinality – the estimation of the cardinality of T is
similar to that of a selection operation; we denote with 
the selectivity of the semijoin operation, which measures
the fraction of the tuples of R which belong to the result.
The estimation is the following:
 = 1/val(A[S]) / val(dom[A])
Given 
card(T) =  * card(R)
29
operations – SEMIJOIN
• Size: The size of the result of a semijoin is the same as the
size of its first operand
size(T) = size(R)
• Distinct values : the number of distinct values of attributes
which do not belong to the semijoin specification can be
estimated using Yao’s formula with n= card(R),
m=val(A[R]), and r =card(T). If A is the only attribute
appearing in the semijoin specification, then
val(A[T]) =  * val(A[R])
30
Histograms
• For skewed data, the uniform distribution
assumption of attribute values yields inaccurate
estimations
• Use an histogram for each skewed attribute A
• Types of histograms: equi-with and equi-depth
• Histogram = set of buckets
• Each bucket describes a range of values of A, with its
average frequency f (number of tuples with A in that
range) and number of distinct values d
• Buckets can be adjusted to different ranges
31
Histograms
• Examples
– Equality predicate
• With (value in Rangei), we have: SFσ(A = value) = 1/di
– Range predicate
• Requires identifying relevant buckets and summing up
their frequencies
32
Histograms
For ASG.DUR=18: we have SF=1/12 so the card of selection is

50/12 = 4 tuples
For ASG.DUR≤18: we have min(range3)=12 and

max(range3)=24 so the card. of selection is
100+75+(((18−12)/(24 − 12))*50) = 200 tuples
33
Architecture of a Query Processing
Query result
Parser Catalog
dynamic optimization
Internal rep. plan query execution

plan
Query Query Plan Query
Rewrite Optimizer Refinement Execution
Engine
Internal rep.
Base data
34
• Parser: the query is parsed and translated into an internal
representation (flex and bison can be used for the
construction of SQL parser)
• Query Rewrite: query rewrite transforms a query in order
to carry out optimizations that are good regardless of the
physical state of the system (elimination of redundant
predicates, unnesting of subqueries, simplification of
expressions). Query rewrite is carried out by a rule engine
• Query Optimizer: this component carries out
optimizations that depend on the physical state of the
system. QO decides which index, which method, and in
which order to execute operations of a query.
35
• Query optimizer: in distributed system QO must decide at
which site each operation is to be executed. QO
enumerates alternative plans and chooses the best plan
using a cost estimation model
• Plan: specifies precisely how the query is to be executed.
The nodes are operators, and every operator carries out one
particular operation. The edges represent consumer-
producer relationships of operators.
• Plan Refinement: this component transforms the plan into
an executable plan. In DB2 this transformation involves
the generation of an assembler-like code to evaluate
expressions and predicates efficiently
36
Centralized Query Optimization
• Dynamic (Ingres project at UC Berkeley)
– Interpretive
• Static (System R project at IBM)

– Exhaustive search
• Hybrid (Volcano project at Oregon Graduate Institute)

– Choose node within plan
37
Static Approach
• Simple (i.e., mono-relation) queries are executed
according to the best access path
• Execute joins
– Determine the possible ordering of joins
– Determine the cost of each ordering
– Choose the join ordering with minimal cost
38
Static Optimization Algorithm
Input: QT: query tree with n relations
Output: best QEP
begin
for each relation Ri  QT do
for each access path APij to Ri do
compute cost(APij);
best_APi  APij with minimum cost;
for each order (Ri1, Ri2, …, Rin) with i=1, …, n! do
build QEP(…((best_APi join Ri2) join Ri3) join … join Rin);
compute cost(QEP);
output  QEP with minimum cost;
end;
39
Query Optimization (1)
• Plan enumeration with Dynamic Programming
Input: SPJ query q on relations R1, ..., Rn
Output: A query plan for q
1. for i=1 to n do {
2. optPlan({Ri}) = accessPlans(Ri)
3. prunePlans(optPlan({Ri}))
4. }
5. for i=2 to n do {
6. for all S  {R1, ..., Rn} such that |S| = i do {
7. optPlan(S) = 
40
Query Optimization (2)
8. for all O  S do {
9. optPlan(S) = optPlan(S) 
joinPlans(optPlan(O), optPlan(S-O))
10. prunePlans(optPlan(S))
11. }
12. }
13. }
14. return optPlan({R1, ..., Rn})
Problem: alternative plans cannot be immediately pruned
41
Dynamic Programming (1)
• Idea: dla każdego podzbioru {R1, …, Rn}, oblicz (znajdź)

najlepszy plan wykonania tego podzbioru
• W rosnącym porządku rozmiarów (cardinalities) zbiorów
krotek:
– Krok1: dla {R1}, {R2}, …, {Rn}
– Krok 2: dla par {R1,R2}, {R1,R3}, …, {Rn-1, Rn}
– …
– Krok n: dla {R1, …, Rn}
• Podzbiór zbioru{R1, …, Rn} nazywamy podzapytaniem
(subquery)
42
• Dla każdego podzapytania Q ⊆ {R1, …, Rn}
wyznacz:
– Size(Q)
– Najlepszy plan wykonania podzapytania Q: Plan(Q)
– Koszt tego planu: Cost(Q)
43
• Krok 1: Dla każdej relacji {Ri} do:

– Size({Ri}) = B(Ri)
– Plan({Ri}) = Ri
– Cost({Ri}) = (koszt skanowania relacji Ri)
44
• Krok i: dla każdego podzapytania Q ⊆ {R1, …, Rn} o

rozmiarze (cardinality) i do:
– Oblicz Size(Q) (później…)
– Dla każdej pary podzapytań Q’, Q’’
s.t. Q = Q’  Q’’
oblicz cost(Plan(Q’) Plan(Q’’))
– Cost(Q) = najniższy koszt
– Plan(Q) = odpowiadający mu plan
• Return Plan({R1, …, Rn})
45
• Podsumowanie: znajdź optymalne plany dla podzapytań:
– Krok 1: {R1}, {R2}, …, {Rn}
– Krok 2: {R1, R2}, {R1, R3}, …, {Rn-1, Rn}
– …
– Krok n: {R1, …, Rn}
• Praktyka:
– Estymacja rozmiarów i kosztów w oparciu o statystyki bazy
danych (patrz poprzednie slajdy)
– Heurystyki do redukcji przestrzeni rozwiązań (search space)
• Ograniczamy się do LDJT (drzewa lewostronnie zagnieżdżone)
• Ograniczamy się do LDJT “without cartesian product”
– Potrzebujemy więcej niż jednego planu dla każdego podzapytania:
• “interesting orders”
46
Example (1)
• Rozważmy połączenie 4 relacji R, S, T i U. Każda z relacji
zawiera 1000 krotek.
R(a, b) S(b, c) T(c, d) U(d, a)
V(R, a) = 100 V(U, a) = 50
V(R, b) = 200 V(S, b) = 100
V(S, c) = 500 V(T, c) = 20
V(T, d) = 50 V(U, d) = 1000
47
Example (2)
• Dla pojedynczych relacji rozmiar (size) odpowiada

rozmiarowi relacji, koszt wynosi 0, ponieważ nie sa
generowane żadne relacje pośrednie
{R} {S} {T} {U}

size 1000 1000 1000 1000
cost 0 0 0 0
plan R S T U
48
Example (3)
• Rozważamy pary relacji: koszt wynosi 0, gdyż nie

powstają w wyniku złączenia żadne relacje pośrednie
{R,S} {R, T} {R,U} {S,T} {S,U} {T,U}

Size 5 000 1M 1M 2 000 1M 1 000
Cost 0 0 0 0 0 0
Plan R⋈S RT RU S⋈T SU T⋈U
49
Example (4)
• Rozważamy połączenie 3 relacji: łączymy dwie relacje a
następnie ich wynik z trzecia relacją
• Koszt dla każdej trójki to wielkość relacji pośredniej
• Rozważamy wszystkie możliwe kombinacje trzech relacji i
wybieramy parę o najmniejszym koszcie
{R, S, T} {R, S, U} {R, T, U} {S, T, U}

Size 10 000 50 000 10 000 2 000
Cost 2 000 5 000 1 000 1 000
Plan (S ⋈ T) ⋈ R (R ⋈ S)  U (T ⋈ U)  R (T ⋈ U) ⋈ S
50
Example (5)
• Rozważmy połączenie wszystkich 4 relacji
• Wynik złączenia dla wszystkich planów wynosi 100 krotek
• Koszt jest określony przez koszt konstrukcji relacji
pośrednich (nie wliczamy kosztu generowania wyniku)
Porządek wykonania operacji Koszt

((S ⋈ T) ⋈ R) ⋈ U 12 000
((R ⋈ S)  U) ⋈ T 55 000
((T ⋈ U)  R) ⋈ S 11 000
((T ⋈ U) ⋈ S) ⋈ R 3 000
51
Join Ordering in Fragment Queries
• Ordering joins
– Distributed INGRES
– System R*
– Two-step
• Semijoin ordering
– SDD-1
53
Query evaluation plan
• Fragment reducers: a set of unary operations which apply
to the same fragment are collected into programs
• Binary operations: joins and unions
• Optimization graph: nodes represent reduced fragments,
and joins (unions) are represented by edges (hypernodes)
A2=B2
A B
54
Query Execution Techniques
• Row blocking – implementation of send and receive
operators is based on TCP/IP, UDP protocols;
idea: ship tuples in a blockwise fashion
• Optimization of Multicasts: send data sequentially
instead of sending data twice (NY  Berlin  Poznan)
• Joins with Horizontally Partitioned Data –
(A1  A2) ⋈ B or (A1 ⋈ B)  (A2 ⋈ B)
If A and B are both partitioned than we have more plans
• Semijoin and Bloomjoin (bit vector for join column)
55
Semijoin Programs
• Semijoin between R and S over two attributes A and B is
defined as follows:
( R A=B S) ⋈ A=B S is equal R ⋈ A=B S
1. Send PJ B (S) to site R at a cost

C0 + C1 * size(B) * val(B(S))
2. Compute semijoin on R at a null communication cost; Let
R’= R A=B S
3. Send R’ to site S at a cost
C0 + C1 * size(R) * card(R’)
4. Compute the join on site S at a null value
56
Reducers
• Semijoin programs can be regarded as reducers, i.e.
Operations that can be applied to reduce the cardinality of
their operands
• Let RED(Q, R) denote the set of reducer programs that can
be built for a given relation R in a given query Q
• There is one reducer program, element of RED(Q, R),
which reduces R more than all other programs – full
reducer
• The problem : find all full reducers for the relations of a
query (difficult task)
• Acyclic (tree queries) versus cyclic queries
57
Reducers
• Is it possible to give a limitation to the length of the full
reducer?
• Tree queries – YES
The limitation on the length of the full reducer amounts to
n-1, where n is the number of nodes of the tree
• Cyclic queries – NO
The limitation on the length of the ‘best’ reducer is linearly
bound by the number of tuples of some relations of the
query
• Best reducer does not mean full reducer
58
Example (1)
R S T
A B B C C A
1 a a x x 2
2 b b y y 3
3 c c z z 4
S
Cyclic query
B=B C=C
R T
A=A
The final result is empty relation; the length of the reducers

is 3*(m-1), where m is the number of tuples,
59
Example (2)
R S T
A B B C C D
1 a a x x 10
2 b b y p 20
3 e c z q 30
S
Acyclic query
B=B C=C
R T
The final result - one tuple (a, x)
60
Testing the graph for cycles
• There are two cases in which cycles can be broken without
changing the meaning of the query
1. In the cycle (R.A=S.B), (S.B=T.C), (T.C=R.A), in which
R, S, T are relation names, and A, B, C are attributes, any
one of the edges can be dropped, as any edge can be
obtained from the remaining ones by transitivity.
2. In the cycle (R.A=S.B), (S.B=T.C), (T.C=R.D), we can
substitute (R.A=R.D) for (T.C=R.D) because, by
transitivity, T.C must equal R.A; the remaining graph
contains two edges (R.S) and (S.T) and is acyclic, because
an interrelation clause can be substituted by an
intrarelation clause
61
Semijoin-based approach
• Takes full advantage of the semijoins to minimize
communication cost
• It is derived from an earlier method called „hill-climbing”
algorithm (previous lecture) – greedy approach
– We start with IFS (Initial Feasible Solution)
– Refinements of IFS are recursively computed until no more cost
improvements can be made
– It does not use semijoins
– The algorithm is quite general in that it can minimize an arbitrary
objective function
62
• The algorithm extensively uses semijoins
• The objective function is expressed in terms of total
communication cost
• Initially, the algorithm selects IFS that is iteratively refined
• The main step of the algorithm consists in determining
and ordering beneficial semijoins – semijoins whose cost
is less than their benefit
• Cost of a semijoin – cost of transferring the semijoin
attribute A
• Benefit of a semijoin – (1-sfSJ(S.A))*size(R)
63
• The algorithm proceeds in 4 steps:
– Initialization
– Selection of beneficial semijoins (program P)
– Site selection
– Postprocessing
• Initialization: generates a set BS of beneficial semijoins
and an execution strategy ES that includes only local
processing
• Selection: selects the beneficial semijoins from BS by
iteratively choosing the most beneficial semijoin and
modifying the database profile and BS accordingly
64
• Assembly site selection: selects the assembly site by
evaluating, for each candidate site, the cost of transferring
to it all the required data and taking the one with the least
cost
• Postoptimization: permits the removal from the execution
strategy of those semijoins that affect only relations stored
at the assembly site
65
Example
• Consider the following query:
select R3.C from R1, R2, R3
where R1.A = R2.A and R2.B = R3.B
• The join graph of the query:
A B
R1 R2 R3
site1 site2 site3
• The database profile:

relation card tuple size rel. size attribute sfSJ size(attr)
R1 30 50 1500 R1.A 0.3 36
R2 100 30 3000 R2.A 0.8 320
R3 50 40 2000 R2.B 1.0 400
R3.B 0.4 80
66
Example
• Initial set of beneficial semijoins: (I iter.)
SJ1: R1 SJ R2 = benefit 300 = (1 – 0.8)*1500 cost = 320
SJ4: R3 SJ R2 = benefit 0 = (1 – 1)*2000 cost = 400
• SJ2 is appended to ES. Modification of database profile:

relation card tuple size rel. size attribute sfSJ size(attr)
R2 30 30 900 R2.A 0.24 96
R2.B ??? ???
Benefit of a semijoin – (1-sfSJ(S.A))*size(R)
67
Example
• II iter.
SJ1: * R1 SJ R2’ = benefit 1140 = (1 – 0.24)*1500 cost = 96
SJ2: R2’ SJ R1 = benefit 0 cost = 36
SJ3: R2’ SJ R3 = benefit 540= (1 – 0.4)*900 cost = 80
SJ4: R3 SJ R2’ = benefit ??? cost = ???
• SJ1 is appended to ES. Modification of database profile:
relation card tuple size rel. size
R1 7,2 30 360
• III iter.
SJ3: R2’ SJ R3 = benefit 540= (1 – 0.4)*900 cost = 80
• SJ3 is appended to ES
68
Example
• Assembly site selection:
amount of data stored at site 1 = 360
Site 3 is therefore chosen as the assembly site
69
Zarządzanie rozproszoną
współbieżnością
Motywacja
• Światowy system telefoniczny
• Światowa sieć komputerowa
• Ogólnoświatowy system baz danych
• Projekty kooperacyjne – projekt posiada bazę danych
składającą się z mniejszych lokalnych baz danych każdego
badacza
• Biuro podróży organizujące wakacje – konsultuje się z
lokalnymi podwykonawcami (lokalnymi firmami), które
podają ceny i oceny jakości hoteli, restauracji i taryf
• Usługa biblioteczna – osoby poszukujące artykułów
przeszukują dwie lub więcej bibliotek
2
Rodzaje systemów rozproszonych
• Homogeniczna federacja – serwery uczestniczące w
federacji są logicznie częścią jednego systemu; wszystkie
obsługują ten sam zestaw protokołów, a nawet mogą
znajdować się pod kontrolą „master site”
• Homogeniczna federacja charakteryzuje się
transparentnością rozproszenia
• Federacja heterogeniczna - serwery uczestniczące w
federacji są autonomiczne i heterogeniczne; mogą
uruchamiać różne protokoły i nie ma „master site”
3
Rodzaje transakcji
• Transakcje lokalne
• Transakcje globalne
4
Zarządzanie współbieżnością w
homogenicznych federacjach
Założenia wstępne
• Niech federacja składa się z n węzłów i niech T = {T1, ...,
Tm} będzie zbiorem globalnych transakcji
• Niech s1, ..., sn będą lokalnymi realizacjami
• Niech D =  Di , gdzie Di jest lokalną bazą danych w
węźle i
• Zakładamy brak replikacji (każda replika traktowana jest
jako osobny element danych)
• Globalna realizacja dla T i s1, ..., sn jest realizacją s dla
T takim, że jego lokalne odwzorowanie s jest równe
realizacji lokalnej w każdym węźle,
tj.  i (s) = si dla wszystkich i, 1  i  n
6
•  i (s) oznacza projekcję realizacji s w węźle i

• Projekcję transakcji T w węźle i nazywamy podtransakcją
T (Ti), która obejmuje wszystkie kroki T w węźle i
• Transakcje globalne formalnie muszą mieć operacje
zatwierdzenia we wszystkich lokalizacjach, w których są
aktywne
• Konfliktowa uszeregowalność – globalna [lokalna]
realizacja jest globalnie [lokalnie] konfliktowo
uszeregowalna, jeśli istnieje sekwencyjna realizacja dla
globalnych [lokalnych] (pod-) transakcji, która jest
równoważna konfliktowo z realizacją s
7
Przykład 1
• Rozważmy federację dwóch węzłów, gdzie D1 = (x)
i D2 = (y). Oraz s1 = r1(x) w2(x) i s2 = w1(y) r2(y) są
realizacjami lokalnymi i
s = r1(x) w1(y) w2(x) c1 r2(y) c2
jest realizacją globalną
•  1 (s) = s1 i  2 (s) = s2
• Inna forma realizacji
serwer 1: r1(x) w2(x)

serwer 2: w1(y) r2(y)
8
Przykład 2
• Rozważmy federację dwóch węzłów, gdzie D1 = (x) i D2
= (y). Przyjmijmy następującą realizację

serwer 2: r2 (y) w1 (y)
Realizacja nie jest konfliktowo uszeregowalna, ponieważ graf

konfliktowej uszeregowalności będzie miał cykl
9
Globalna konfliktowa
uszeregowalność
Niech s będzie globalną realizacją z lokalnymi
realizacjami s1, s2, ..., sn obejmującymi zbiór T
transakcji takich, że każde si, 1  i  n, jest
uszeregowane konfliktowo. Wówczas:
s jest globalnie konfliktowo uszeregowane, wtedy i

tylko wtedy gdy istnieje całkowity porządek „<”
na T, który jest zgodny z lokalnymi porządkami
transakcji
10
Algorytmy kontroli współbieżności
• Rozproszone algorytmy blokowania 2PL

• Rozproszone algorytmy T/O
• Rozproszone algorytmy optymistyczne
11
Rozproszone algorytmy blokowania
2PL
• Główny problem polega na tym, jak ustalić, czy transakcja
osiągnęła swój punkt akceptacji?
• Primary site 2PL – zarządzanie blokadą odbywa się
wyłącznie w wyróżnionej lokalizacji – primary site
• Distributed 2PL – gdy serwer chce rozpocząć fazę
odblokowania transakcji, komunikuje się ze wszystkimi
innymi serwerami w sprawie punktu akceptacji tej
transakcji
• Strong 2PL – wszystkie blokady założone w imieniu
transakcji są utrzymywane do momentu zatwierdzenia
transakcji (2PC)
12
Rozproszone algorytmy znaczników
czasowych (T/O)
• Załóżmy, że każda węzeł wykonuje swój prywatny
protokół T/O w celu synchronizacji dostępów w swojej
części bazy danych:

Gdyby sygnatury czasowe zostały przypisane tak, jak w

przypadku scentralizowanym, każdy z dwóch serwerów
przypisałby wartość 1 pierwszej transakcji, którą widzi
lokalnie; T1 na serwerze 1 i T2 na serwerze 2, co
doprowadziłoby do globalnie błędnego wyniku
13
Rozproszone algorytmy T/O
• Musimy znaleźć sposób na przypisanie globalnie
unikalnych znaczników czasu do transakcji we wszystkich
węzłach:
– Scentralizowane podejście – za generowanie i dystrybucję
znaczników czasu odpowiada konkretny serwer
– Podejście rozproszone – każdy serwer generuje unikalny lokalny
znacznik czasu za pomocą zegara lub licznika
TS(T1) =(100)
TS(T2) =(110)
14
Rozproszone algorytmy T/O
• Zegar Lamporta – używany do rozwiązania
ogólniejszego problemu ustalenia pojęcia czasu
logicznego w sieci asynchronicznej
– Węzły komunikują się za pomocą wiadomości
– Czas logiczny to para (c, i), gdzie c to nieujemna liczba
całkowita, a i to numer transakcji
– Zmienna zegarowa jest zwiększana o 1 przy każdej
operacji transakcyjnej; logiczny czas operacji jest
zdefiniowany jako wartość zegara bezpośrednio po
operacji
15
Rozproszone algorytmy optymistyczne
• Przy podejściu optymistycznym każda transakcja jest
przetwarzana w trzech fazach (odczyt, walidacja, zapis)
• Problem: jak zapewnić, że walidacja doprowadzi do tego
samego wyniku w każdym węźle, w której aktywna była
transakcja globalna
• Nie zaimplementowano
16
Rozproszone wykrywanie zakleszczeń
• Problem: globalne zakleszczenie, którego nie można
wykryć tylko lokalnie (każdy serwer utrzymuje WFG
lokalnie)
Węzeł 3
czeka na wiadomość
Węzeł 1 T1 T1
T2 T3
czeka na blokadę
T2 T3
Węzeł 2
17
• Scentralizowana detekcja – scentralizowany
monitor zbierający lokalne WFG
– wydajność
– fałszywe zakleszczenia
• Podejście limitu czasu
• Podejścia rozproszone:
– Pogoń za krawędzią
– Pchanie ścieżki
18
• Edge chasing – każda transakcja, która zostaje
zablokowana w trakcie oczekiwania, wysyła swój
identyfikator w specjalnej wiadomości zwanej sondą do
transakcji blokującej. Jeśli transakcja otrzyma sondę,
przekazuje ją do wszystkich transakcji, przez które sama
jest blokowana. Jeśli sonda wróci do transakcji, przez którą
została zainicjowana – ta transakcja wie, że uczestniczy w
cyklu, a więc jest częścią zakleszczenia
19
• Path pushing – między transakcjami krążą całe
ścieżki zamiast pojedynczych identyfikatorów transakcji.
• Podstawowy algorytm jest następujący:
1. Każdy serwer, który ma ścieżkę oczekiwania od transakcji Ti do
transakcji Tj taką, że Ti ma krawędź oczekiwania na wiadomość
przychodzącą, a Tj krawędź oczekiwania na wiadomość
wychodzącą, wysyła tę ścieżkę do serwera wzdłuż krawędzi
wychodzącej, pod warunkiem, że identyfikator Ti jest mniejsze
niż Tj
2. Po otrzymaniu ścieżki serwer łączy ją z już istniejącymi
ścieżkami lokalnymi i ponownie przekazuje wynik wzdłuż
wychodzących krawędzi. Jeśli istnieje cykl wśród n serwerów,
przynajmniej jeden z nich wykryje ten cykl w co najwyżej n
takich rundach
20
• Rozważmy przykład zakleszczenia:
Wezęł 1 Wezęł 2 Wezęł 3

T1 T2 T2 T3 T3 T1
T1 T2 T3
Wezęł 3 wie, że T3 T1 lokalnie i wykrywa

globalne zakleszczenie
Kontrola współbieżności w
federacjach heterogenicznych
• Heterogeniczny system rozproszonej bazy danych, który
integruje istniejące wcześniej zewnętrzne źródła danych w
celu obsługi globalnych aplikacji uzyskujących dostęp do
więcej niż jednego zewnętrznego źródła danych
• HDDBS kontra LDBS
• Lokalna autonomia i heterogeniczność lokalnych źródeł
danych
– Autonomia projektowania
– Autonomia komunikacji
– Autonomia wykonania
• Lokalna autonomia odzwierciedla fakt, że lokalne źródła
danych zostały zaprojektowane i wdrożone niezależnie i
były całkowicie nieświadome procesu integracji
23
• Autonomia projektowa: odnosi się do zdolności systemu
bazy danych do wyboru własnego modelu danych i
procedur implementacji
• Autonomia komunikacyjna: odnosi się do zdolności
systemu bazy danych do decydowania, z jakimi innymi
systemami będzie się komunikować i jakie informacje
będzie z nimi wymieniać
• Autonomia wykonania: odnosi się do zdolności systemu
bazy danych do decydowania, jak i kiedy wykonać żądania
otrzymane z innych systemów
24
Trudności
• Akcje transakcji mogą być wykonywane w różnych EDS
(External Data Source), z których jeden posiada system
wykorzystujący blokady w celu zagwarantowania
uszeregowania, podczas gdy inny może wykorzystywać
znaczniki czasu
• Zagwarantowanie właściwości transakcji może ograniczyć
lokalną autonomię, np. aby zagwarantować atomowość,
uczestniczące EDS muszą wykonać jakiś rodzaj protokołu
zatwierdzenia
• EDS mogą nie zapewniać funkcjonalności niezbędnej do
wdrożenia wymaganych protokołów globalnej
koordynacji. Dla 2PC, konieczne jest, aby EDS był w
stanie przygotowania gwarantując, że lokalne operacje
transakcji mogą zostać zakończone. Istniejące EDS mogą
nie zezwalać na przejście transakcji w ten stan. 25
Model HDDBS
Transakcje globalne
Menedżer transakcji
globalnych (GTM)
Menedżer transakcji Menedżer transakcji

lokalnych (LTM) lokalnych (LTM)
Transakcje lokalne Transakcje lokalne
Zewnętrzne źródło Zewnętrzne źródło

danych EDS1 danych EDS2
26
Notacja podstawowa
• HDDBS składa się ze zbioru D zewnętrznych źródeł danych
oraz zbioru transakcji 
• D = {D1, D2, ..., Dn} Di – i-te zewnętrzne źródło danych
•  = T  T 1  T 2  ...  T n
• T – zbiór transakcji globalnych
• T i – zbiór lokalnych transakcji, które mają dostęp tylko do D i
27
Przykład
• Biorąc pod uwagę federację dwóch serwerów:
D1 = { a, b} D2 = {c, d, e} D={a, b, c, d, e}
• Transakcje lokalne:
T1 = r(a) w(b) T2 = w(d) r(e)
• Transakcje globalne:
T3 = w(a) r(d) T4 = w(b) r(c) w(e)
• Lokalne realizacje:
s1: r1(a) w3(a) c3 w1(b) c1 w4(b) c4
s2: r4(c) w2(d) r3(d) c3 r2(e) c2 w4(e) c4
28
Globalna realizacja
Niech heterogeniczna federacja składa się z n węzłów i niech
T 1 , ..., T n będzie zbiorem transakcji lokalnych w
węzłach1, ..., n. Niech T będzie zbiorem transakcji
globalnych. Oraz niech s1, s2, ..., sn będzie zbiorem
lokalnych realizacji na węzłach 1, ..., n
(Heterogeniczna) globalna realizacja (dla s1, ..., sn ) jest

n
realizacją s dla T  T tak, że jego lokalna projekcja
i 1 i
jest równa realizacji lokalnej w każdym węźle, tj.  i (s) =

si dla wszystkich i, 1  i  n
29
Poprawność realizacji
D1 = {a} D2 = {b, c}
• Biorąc pod uwagę dwie transakcje globalne T1 i T2 oraz
transakcję lokalną T3:
T1 = r(a) w(b) T2= w(a) r(c) T3 = r(b) w(c)
• Załóżmy następujące lokalne realizacje: konflikt pośredni
serwer 1: r1(a) w2(a)
serwer 2: r3(b) w1(b) r2(c) w3(c)
• Globalne transakcje T1 i T2 są wykonywane ściśle
sekwencyjnie w obu lokalizacjach – globalna realizacja nie
jest globalnie uszeregowana (T1->T2, T3->T1, T2->T3 –
cykl)
30
Globalna uszeregowalność
• W heterogenicznej federacji GTM nie ma bezpośredniej
kontroli nad lokalnymi realizacjami; najlepsze, co może
zrobić, to kontrolować uszeregowanie transakcji
globalnych poprzez uważne kontrolowanie kolejności, w
jakiej operacje są wysyłane do lokalnych systemów w ich
celu wykonania i w jakiej są one potwierdzane.
• Konflikt pośredni: Ti i Tk są w konflikcie pośrednim w si,
jeśli istnieje ciąg transakcji T1 , ..., Tr w si taki, że Ti jest w
si w bezpośrednim konflikcie z T1; Tj jest w bezpośrednim
konflikcie z Tj+1 , 1 jr-1, a Tr jest w bezpośrednim
konflikcie Tk.
• Równoważność konfliktów: dwie realizacje zawierają te
same operacje i te same bezpośrednie i pośrednie konflikty
31
• Globalny graf konfliktowej uszeregowalności:
Niech s będzie globalną realizacją dla lokalnych realizacji s1,
s2, ..., sn; niech G(si) oznacza graf konfliktowej
uszeregowalności si, wywodzącący się z bezpośrednich i
pośrednich konfliktów. Globalny graf konfliktowej
uszeregowalności realizacji s jest zdefiniowany jako suma
wszystkich G(si), 1  i  n, tj
n
G(S )  i 1
G ( si )
• Twierdzenie o globalnym uszeregowalności
Niech będą dane realizacje lokalne s1, s2, ..., sn, gdzie każdy
G(si), 1  i  n, jest acykliczny. Niech s będzie globalną
realizacją dla si, 1  i  n. Globalna realizacja s jest
globalnie konfliktowo uszeregowalna, jeśli G(s) jest
acykliczny 32
• Aby zapewnić globalne uszeregowanie, kolejność
uszeregowania transakcji globalnych musi być taka sama
we wszystkich węzłach, które je wykonują
• Kolejności uszeregowania lokalnych realizacji muszą

zostać sprawdzone przez HDDBS
– Te uszeregowania nie są zgłaszane przez EDSy
– Można je określić kontrolując zlecanie globalnych podtransakcji i
obserwując kolejność ich realizacji
33
Przykład
• Globalna realizacja, której nie można uszeregować
s1: w1(a) r2(a) T1 T2
s2: w2(c) r3(c) w3(b) r1(b) T2 T3 T1
• Globalna realizacja, którą można uszeregować
s1: w1(a) r2(a) T1 T2
s2: w2(c) r1(b)
• Globalna realizacja, której nie można uszeregować
s1: w1(a) r2(a) T1 T2
s2: w3(b) r1(b) w2(c) r3(c) T2 T3 T1
34
Quasi uszeregowalność
• Odrzucenie globalnej uszeregowalności jako kryterium

poprawności
• Podstawowa idea: zakładamy, że między EDS nie istnieją
żadne zależności wartości, więc konflikty pośrednie można
zignorować
• Aby zachować spójność w globalnej bazy danych, tylko
transakcje globalne muszą być wykonywane w sposób
uszeregowalny z należytym uwzględnieniem skutków
transakcji lokalnych
35
Quasi uszeregowalność
• Realizacje quasi-uszeregowalne
Zbiór lokalnych realizacji {s1, ..., sn} jest quasi-
uszeregowalny, jeśli każda si jest konfliktowo
uszeregowalna i istnieje całkowity porządek „<„ na zbiorze
T transakcji globalnych taki, że jeżeli T i < T j dla T i , Tj 
T, i  j, to w każdej lokalnej realizacji si, każda
podtransakcja Ti występuje całkowicie przed podtransakcją
Tj
• Quasi uszeregowalność
Zbiór lokalnych realizacji {s1, ..., sn} jest quasi-
uszeregowalny, jeśli istnieje zbiór quasi-uszeregowalny
lokalnych realizacji {s1' , ..., sn' } taki, że si jest
konfliktowo równoważna z si' dla 1  i  n . 36
Przykład (1)
D1 = {a, b} D2 = {c, d, e}
dwie transakcje lokalne T3 i T4 :
T1 = w(a) r(d) T2= r(b) r(c) w(e)
T3 = r(a) w(b) T4= w(d) r(e)
• Załóżmy następujące lokalne realizacje:
s1: w1(a) r3(a) w3(b) r2(b)
s2: r2(c) w4(d) r1(d) w2(e) r4(e)
T1->T3, T3->T2, T4->T1, T2->T4

37
Przykład (2)
• Zbiór {s1, s2} jest quasi-uszeregowalny, ponieważ jest
konfliktowo równoważnym do zbioru quasi-
uszeregowalnego {s1, s2'}, gdzie
s2' : w4(d) r1(d) r2(c) w2(e) r4(e)
• Globalna realizacja
s: w1(a) r3(a) r2(c) w4(d) r1(d) c1 w3(b) c3 r2(b) w2(e) c2 r4(e) c4
jest quasi-uszeregowalny; jednak s nie globalnie
uszeregowalna
• Ponieważ kolejność quasi-uszeregowalności jest zawsze
zgodna z kolejnością transakcji podrzędnych w różnych
lokalnych realizacjach, quasi-uszeregowalność jest
stosunkowo łatwa do osiągnięcia dla GTM
38
Osiągnięcie globalnego uszeregowania
poprzez lokalne gwarancje — rygoryzm
• GTM zakłada, że lokalne realizacje konfliktowo
uszeregowalne
• Istnieją różne scenariusze gwarantujące globalną
uszeregowalność
• Rygoryzm : lokalne TM tworzą rygorystyczne
konfliktowo uszeregowalne realizacje. Realizacja jest
rygorystyczna, jeśli spełnia następujący warunek:
oi(x) <s oj(x), i  j; oi, oj operacje w konflikcie
aborti <s oj(x) or commiti <s oj(x)
• Realizacje rygorystyczne pozwalają uniknąć wszelkiego
rodzaju konfliktów rw, wr lub ww między
niezatwierdzonymi transakcjami
39
D1 = { a, b } D2 = { c, d }
dwie transakcje lokalne T3 i T4:
T1 = w(a) w(d) T2= w(c) w(b)
T3 = r(a) r(b) T4= r(c) r(d)
• Załóżmy następujące lokalne uszeregowania:
s1: w1(a) c1 r3(a) r3(b) c3 w2(b) c2
s2: w2(c) c2 r4(c) r4(d) c4 w1(d) c1
• Obie realizacje są rygorystyczne, ale dają różne kolejność
uszeregowania
40
• Transakcje z odroczonym zatwierdzeniem : Transakcja

globalna T ma odroczone zatwierdzenie, jeśli jej operacja
zatwierdzenia jest wysyłana przez GTM do lokalnych
węzłów dopiero po potwierdzeniu lokalnych wykonań
wszystkich operacji T we wszystkich węzłach
• Twierdzenie : Jeśli s i  RG, 1  i  n, a wszystkie
transakcje globalne są odroczone, to s jest uszeregowane
globalnie
41
Możliwe rozwiązania
• Podejście oddolne : obserwacja realizacji transakcji globalnych w
każdym EDS.
Idea : kolejność wykonywania transakcji globalnych jest określana przez
ich kolejność uszeregowania w każdym EDS
Problem : jak określić kolejność uszeregowania globalnych transakcji?
• Podejście odgórne : kontrolowanie kolejności wysyłania i
wykonywania operacji transakcji globalnych
Idea : GTM określa globalną kolejność uszeregowania dla globalnych
transakcji przed przesłaniem ich do EDS. Obowiązkiem EDS jest
egzekwowanie tego porządku w lokalnych lokalizacjach
Problem : w jaki sposób porządek jest egzekwowany w lokalnych
węzłach?
42
Metoda oparta na biletach
• W jaki sposób GTM może uzyskać informacje o względnej
kolejności subtransakcji globalnych transakcji w każdym
EDS?
• W jaki sposób GTM może zagwarantować, że
podtransakcje każdej transakcji globalnej mają tę samą
względną kolejność we wszystkich uczestniczących EDS?
• Pomysł: wymusić lokalne bezpośrednie konflikty między
transakcjami globalnymi lub przekształcić konflikty
pośrednie (nieobserwowalne przez GTM) w bezpośrednie
(obserwowalne) konflikty
43
Metoda oparta na biletach
• Bilet: bilet to logiczny znacznik czasu, którego wartość jest
przechowywana jako specjalny element danych w każdym
EDS
• Każda subtransakcja jest wymagana do wystawienia
operacji Take_A_Ticket :
r(bilet) w(bilet+1) (sekcja krytyczna)
• Tylko subtransakcje transakcji globalnych muszą
przyjmować bilety
• Twierdzenie : Jeśli globalna transakcja T1 otrzyma swój
bilet przed globalną transakcją T2 na serwerze, to T1
zostanie uszeregowana przed T2 przez ten serwer
• lub bilety uzyskane przez subtransakcje określają ich
względną kolejność uszeregowania 44
Przykład (1)
D1 = { a } D2 = { b, c }
transakcję lokalną T3:
T1 = r(a) w(b) T2= w(a) r(c)
T3 = r(b) w(c)
• Załóżmy następujące lokalne realizacje:
s1: r1(a) c1 w2(a) c2 T1 T2
s2: r3(b) w1(b) c1 r2(c) c2 w3(c) c3
T2 T3 T1
realizacji nie można uszeregować globalnie
45
Przykład (2)
• Korzystając z biletów, lokalne realizacje wyglądają
następująco:
s1: r1(I1) w1(I1+1) r1(a) c1 r2(I1) w2(I1+1) w2(a) c2
s2: r3(b) r1(I2) w1(I2+1) w1(b) c1 r2(I2) w2(I2+1) r2(c) c2 w3(c) c3
• Pośredni konflikt między transakcjami globalnymi w
realizacji s2 został przekształcony w jawny; realizacja s2 nie
jest konfliktowo uszeregowalna; ponadto T1 i T2 w
globalnej realizacji bezpośrednio nie są konfliktowo
uszeregowalne. Związku z tym zarówno GTM jak i LTM
mają wiedzę o braku uszeregowalności realizacji.
T1 T2
s2: T3
46
Metoda biletu optymistycznego
• Metoda biletu optymistycznego (OTM): GTM musi
zapewnić, że transakcje podrzędne mają tę samą względną
kolejność uszeregowania w odpowiednich EDS
• Idea : polega na umożliwieniu kontynuacji transakcji
podrzędnych, ale zatwierdzeniu ich tylko wtedy, gdy ich
wartości biletów mają tę samą względną kolejność we
wszystkich uczestniczących EDS
• Wymaganie : EDS muszą obsługiwać widoczny stan
„prepare_to_commit” dla wszystkich transakcji
podrzędnych
• Stan „Prepare_to_commit” jest widoczny, jeśli aplikacja
może zdecydować, czy transakcja powinna zostać
zatwierdzona, czy przerwana
48
Metoda biletu optymistycznego
• Transakcja globalna T przebiega w następujący sposób:
– GTM ustawia limit czasu dla T
– Przesyła wszystkie transakcje podrzędne T do odpowiednich EDS
– Jeśli wejdą one w stan „p_t_c”, czekają, aż GTM zatwierdzi T
– GTM rozsyła polecenie zatwierdzenia lub przerwania
• GTM sprawdza poprawność T za pomocą grafu biletów –
graf jest testowany pod kątem cykli z udziałem T
• Problemy z OTM
– Globalne aborcje spowodowane operacjami biletowymi
– Wzrasta prawdopodobieństwo globalnych zakleszczeń
49
Spójność pamięci podręcznej i
zarządzanie współbieżnością
dla systemów udostępniania
danych
Architektury dla równoległych
rozproszonych systemów baz danych
• Trzy główne architektury:
– Systemy pamięci współdzielonej
– Współdzielone systemy dyskowe
– Bez współdzielenia
• System pamięci współdzielonej: wiele procesorów jest
podłączonych do sieci połączeniowej i może uzyskiwać
dostęp do wspólnego obszaru pamięci głównej
• System dysków współdzielonych: każdy procesor ma
prywatną pamięć i bezpośredni dostęp do wszystkich
dysków za pośrednictwem sieci połączeniowej
• System bez współdzielenia: każdy procesor ma lokalną
pamięć i miejsce na dysku, ale żadne dwa procesory nie
mogą uzyskać dostępu do tego samego obszaru pamięci,
cała komunikacja odbywa się za pośrednictwem sieci 51
połączeniowej
System pamięci współdzielonej
P P P P
Sieć połączeniowa
Globalna pamięć współdzielona
D D D
52
Współdzielony system dyskowy
M M M M
P P P P
D D D
53
System bez współdzielenia
P P P P
M M M M
D D D D
54
Charakterystyka architektur
• Pamięć współdzielona:
– jest bliższy konwencjonalnej maszynie, wiele komercyjnych
DBMS zostało przeniesionych na tę platformę
– Narzut komunikacyjny jest niski
– Rywalizacja o pamięć staje się wąskim gardłem wraz ze wzrostem
liczby procesorów
• Dysk współdzielony: podobna charakterystyka
• Problem zakłóceń: w miarę dodawania większej liczby
procesorów istniejące procesory są spowalniane z powodu
zwiększonej rywalizacji o dostęp do pamięci i
ograniczonej przepustowość sieci połączeniowej
• System z 1000 procesorów jest tylko w 4% tak wydajny
jak system z jednym procesorem
55
• Zapewnia niemal liniowe przyspieszenie, ponieważ czas
potrzebny na wykonanie operacji zmniejsza się
proporcjonalnie do wzrostu liczby procesorów i dysków
• Zapewnia niemal liniowe skalowanie, przy czym
wydajność jest utrzymywana, jeśli liczba procesorów i
dysków zostanie zwiększona proporcjonalnie do ilości
danych
• Można zbudować wydajne równoległe systemy baz
danych, korzystając z szybko rosnącej wydajności
pojedynczego procesora
56
# transakcji/sekundę # transakcji/sekundę
# procesorów Liczba procesorów

i rozmiar bazy danych
PRZYŚPIESZENIE SKALOWANIE
z ROZMIAREM BD
57
Problem współbieżności i spójności
pamięci podręcznej
• Strony pamięci z danymi mogą być replikowane
dynamicznie w więcej niż jednej pamięci podręcznej
serwera w celu wykorzystania lokalizacji dostępu
• Synchronizacja odczytów i zapisów wymaga pewnej
formy rozproszonego zarządzania blokadami, a
unieważnianie nieaktualnych kopii elementów danych lub
propagacja zaktualizowanych elementów danych musi być
komunikowana między serwerami
• Podstawowe założenie dla systemów współdzielenia
danych: każda pojedyncza transakcja jest realizowana
wyłącznie na jednym serwerze (tj. transakcja nie migruje
między serwerami w trakcie jej wykonywania)
58
Callback Locking
• Zakładamy, że zarówno zarządzanie współbieżnością, jak i
kontrola spójności pamięci podręcznej są zorientowane na
strony
• Każdy serwer ma globalnego menedżera blokad i
lokalnego menedżera blokad
• Elementy danych są przypisywane do menedżerów
globalnych w sposób statyczny (np. poprzez haszowanie),
więc każdy menedżer blokady globalnej odpowiada za
ustalony podzbiór elementów danych – mówimy, że
menedżer blokady globalnej ma uprawnienia do globalnej
blokady elementu danych
• Globalny menedżer blokady wie dla elementu danych w
każdym momencie, czy element jest zablokowany, czy nie
59
Callback Locking - zarządzanie
• Gdy transakcja żąda blokady lub chce ją zwolnić, najpierw
zwraca się do lokalnego menedżera blokady, który może
następnie skontaktować się z globalnym menedżerem
blokady
• Najprostszym sposobem jest przekazanie wszystkich żądań
zablokowania i odblokowania do globalnego menedżera
blokad, który ma globalne uprawnienia do blokowania dla
danego elementu danych
• Jeśli menedżer blokad jest upoważniony do lokalnego
zarządzania blokadą odczytu (lub blokadą zapisu), można
zaoszczędzić na wymianie komunikatów z globalnym
menedżerem blokad
60
Callback Locking – zarządzanie
• Lokalne uprawnienie do odczytu umożliwia lokalnemu
menedżerowi blokad przyznawanie lokalnych blokad
odczytu dla elementu danych
• Lokalne uprawnienia do zapisu umożliwiają lokalnemu
menedżerowi blokad przyznawanie lokalnych blokad
odczytu/zapisu elementu danych
• Uprawnienie do zapisu musi zostać zwrócone do
odpowiedniego globalnego menedżera blokad, jeśli inny
serwer chce uzyskać dostęp do elementu danych
• Upoważnienie do odczytu może być utrzymywane przez
kilka serwerów jednocześnie i musi zostać zwrócone do
odpowiedniego globalnego menedżera blokad, jeśli inny
serwer chce uzyskać dostęp do elementu danych w celu
wykonania dostępu do zapisu 61
Callback Locking – zarządzanie
• Protokół spójności pamięci podręcznej musi zapewniać:

– Wiele pamięci podręcznych może jednocześnie
przechowywać aktualne wersje strony, o ile strona jest
tylko czytana i
– Gdy strona zostanie zmodyfikowana w jednej z pamięci
podręcznych, tylko ta pamięć podręczna jest tą, która
może przechowywać kopię strony
• Komunikat wywołania zwrotnego unieważnia lokalne
uprawnienia do blokowania
62
Callback Locking
Home(x) Server A Server B Server C
r1(x)
Rlock(x)
Rlock authority(x)
r2(x)
Rlock(x)
Rlock authority(x)
c1
r3(x)
c3
w4(x)
63
Callback Locking
Home(x) Server A Server B Server C
c1
r3(x)
c3
w4(x)
Wlock(x)
Callback(x)
Callback(x)
OK
c2
OK
Wlock authority(x)
64
Odtwarzanie transakcji
rozproszonych
Cel
• Semantyka atomowości typu „wszystko albo nic” musi
zostać rozszerzona na aktualizacje transakcji na wielu
serwerach
• System rozproszony może częściowo ulec awarii
• Rozwiązaniem jest wykorzystanie specjalnego protokołu
uzgadniania między serwerami z rodziny protokołów
rozproszonego zatwierdzania
• Protokół zakłada, że istnieją pewne okoliczności, w
których serwer, który uległ awarii, musi komunikować się
z innymi serwerami podczas restartu, aby poznać decyzję
dotyczącą całego systemu o statusie zakończenia
transakcji wątpliwych (transakcje niepewne)
2
Cel
• Serwery nie są już autonomiczne w tym sensie, że nie
zawsze mogą samodzielnie odtworzyć stan bazy danych
„w doskonałej izolacji”
• Protokoły zatwierdzania przyjmują bardzo niewiele
założeń dotyczących sposobu, w jaki różne serwery
wdrażają swoje lokalne odtwarzanie
• Wymaganiem jest przestrzeganie zasad protokołu
zatwierdzania przez wszystkie strony systemu
rozproszonego
• Protokół 2PC został ustandaryzowany i jest powszechnie
akceptowany w branży oprogramowania
3
Zatwierdzenie rozproszone
• Problem:
Jak zapewnić atomowość rozproszonej transakcji?
Przykład :
Rozważmy sieć sklepów należących do supermarketu.
Załóżmy, że kierownik sieci chce przeszukać
wszystkie sklepy, znaleźć zapasy spodni w każdym z
nich i wydać instrukcje dotyczące przenoszenia
spodni ze sklepu do sklepu w celu zbilansowania
zapasów. Cała operacja jest wykonywana przez
pojedynczą globalną transakcję T, która ma
komponent Ti w każdym i-tym sklepie i komponent To
w biurze, w którym znajduje się kierownik
4
Zatwierdzenie rozproszone
Sekwencję czynności wykonywanych przez T
podsumowano poniżej:
• Komponent To jest tworzony w węźle kierownika
• To wysyła wiadomości do wszystkich sklepów, instruując
je, aby stworzyły komponenty Ti
• Każdy Ti wykonuje zapytanie w sklepie i, aby sprawdzić
liczbę spodni w magazynie i zgłasza tę liczbę do To
• To odbiera te liczby i określa, jakie przesyłki spodni są
pożądane. To wysyła wiadomości typu „sklep 10 powinien
wysłać 100 spodni do sklepu 7” do odpowiednich sklepów
• Sklepy otrzymujące dyspozycje aktualizują stany
magazynowe i realizują wysyłki
5
Nieudana koordynacja transakcji
rozproszonej (1)
T1 Committed
Active
Aborted
Crash/
recover Committed
T2
Active
Aborted
Zarówno T1, jak i T2 są gotowe Crash/

do zatwierdzenia recover
6
Nieudana koordynacja transakcji
rozproszonej (2)
T1 Committed
T1: committed;
Active T2: crashes and recovers
Aborted
Crash/
recover
T2 Committed
Active
To, czego potrzebujemy, to Aborted
nowy stan, który wprowadzi więcej
elastyczności w ten prosty diagram Crash/
stanów recover
7
Diagram stanu transakcji z trwałym
stanem wstępnego zatwierdzenia
Committed
Active Precommitted
Aborted
Crash/
recover
8
Stan wstępnego zatwierdzenia
• Transakcja zostaje wstępnie zatwierdzona w wyniku

żądania koordynatora rozproszonych transakcji (TM). Ze
stanu wstępnie zatwierdzonego transakcja może przejść do
stanu zatwierdzonego lub przerwanego. W przypadku
awarii systemu i późniejszego odtwarzania transakcja w
stanie wstępnie zatwierdzonym powraca do stanu wstępnie
zatwierdzonego.
9
Protokół zatwierdzania dwufazowego
• Zakładamy, że mechanizmy atomowości w każdej lokacji
zapewniają, że albo lokalny komponent się zatwierdza,
albo nie ma wpływu na stan bazy danych w tej lokacji –
tzn. lokalne komponenty globalnej transakcji są atomowe
• Egzekwując zasadę, że albo wszystkie komponenty
rozproszonej transakcji zatwierdzają, albo żaden,
sprawiamy, że sama rozproszona transakcja jest atomowa
10
Protokół zatwierdzania dwufazowego
• Niektóre założenia dotyczące protokołu 2PC:

– Każda węzeł rejestruje działania w tym węźle, ale nie
ma dziennika globalnego
– Jedna strona, koordynator, odgrywa szczególną rolę w
podejmowaniu decyzji, czy rozproszona transakcja
może zostać zatwierdzona
– Protokół 2PC polega na przesyłaniu określonych
komunikatów między koordynatorem a innymi
lokalizacjami. Wysyłana wiadomość jest rejestrowana
w węźle wysyłającym, aby w razie potrzeby pomóc w
odzyskaniu
11
Protokół zatwierdzenia dwufazowego
– faza 1
1. Koordynator umieszcza wpis w dzienniku <Prepare T>
w dzienniku w swoim węźle
2. Koordynator wysyła do lokalizacji każdego komponentu
wiadomość <prepare T>
3. Każda węzeł otrzymujący komunikat <prepare T>
decyduje, czy zatwierdzić, czy przerwać swój
komponent Ti. Węzeł może opóźnić odpowiedź, jeśli
komponent nie zakończył jeszcze swojej aktywności, ale
ostatecznie musi wysłać odpowiedź
4. Jeśli węzeł może zatwierdzić swój składnik Ti, musi
wejść w stan zwany wstępnie zatwierdzonym. Gdy
węzeł znajdzie się w stanie wstępnego zatwierdzenia, nie
może przerwać swojego komponentu Ti bez polecenia 12
koordynatora.
– faza 1
W celu przejścia do stanu wstępnego zatwierdzonia, węzeł
wykonuje następujące kroki:
– Wykonaj wszelkie niezbędne czynności, aby upewnić się, że
lokalny składnik Ti nie będzie musiał być przerywany, nawet
jeśli wystąpi awaria systemu, po której nastąpi odtwarzanie w
lokalizacji. Tak więc muszą być wykonane wszystkie
odpowiednie zapisy w dzienniku bazy danych, aby Ti zostało
wykonane ponownie, a nie cofnięte podczas odzyskiwania
– Umieść rekord <Ready T> w dzienniku lokalnym i opróżnij
dziennik na dysk
– Wyślij do koordynatora wiadomość <ready T>
5. Jeśli węzeł chce przerwać swój komponent Ti, rejestruje
rekord <Don’t commit T> i wysyła wiadomość <don’t
commit T> do koordynatora. Przerwanie komponentu w
tym momencie jest bezpieczne, ponieważ T z pewnością
zostanie przerwane, nawet jeśli tylko jeden komponent 13
chce przerwać
Protokół zatwierdzenia dwufazowego –
faza 2
1. Jeżeli koordynator otrzymał <ready T> ze wszystkich
składowych T, to decyduje się na zatwierdzenie T.
Koordynator:
– Zapisuje <Commit T> w dzienniku swjego węzła i
– Wysyła wiadomość <commit T> do wszystkich węzłów
zaangażowanych w T
2. Jeśli koordynator otrzymał <don’t commit T> z jednego
lub więcej węzłów, to decyduje się na przerwanie T.
Koordynator:
– Zapisuje < Abort T > w dzienniku swjego węzła i
– Wysyła wiadomość < abort T > do wszystkich węzłów
zaangażowanych w T
14
– faza 2
3. Jeśli węzeł otrzyma komunikat < commit T >,

zatwierdza komponent T w tym węźle, rejestrując <
Commit T > w dzienniku
4. Jeśli węzeł otrzyma komunikat <abort T>, przerywa
komponent T w tym węźle i zapisuje rekord dziennika
<Abort T>
15
Rodzaje awarii
• Utrata komunikatu: komunikat nie dociera do procesu
docelowego z powodu awarii sieci
• Duplikaty wiadomości : niektóre komponenty sieci mogą
zduplikować wiadomość
• Przejściowe awarie procesów: jeden lub więcej
zaangażowanych procesów, uczestników lub
koordynatorów wykazuje miękką awarię i musi zostać
ponownie uruchomiony, ale bez uszkodzenia danych w
pamięci masowej
• Pomysł : rozdzielić odpowiedzialność za obsługę różnych

klas awarii między federację transakcyjną i jej system
komunikacyjny
16
Model awarii
• 2PC nie przyjmuje żadnych założeń dotyczących
podstawowego systemu komunikacyjnego (datagramy oraz
protokoły zorientowane na sesję)
• Błędy pominięcia a błędy przekłamań (Omission vs
commission) - te późniejsze wymagałyby rozproszonych
protokołów konsensusu, znanych jako umowa bizantyjska
• Bierzemy pod uwagę tylko awarie pominięć
17
Transakcje wątpliwe
• Uczestnik, który odpowie „tak” na ankietę koordynatora w

pierwszej fazie wymiany wiadomości, może wtedy ulec
awarii.
• Uczestnik nie może już wykonywać lokalnego odtwarzania
po awarii, tak jakby w ogóle nie było transakcji
rozproszonych
• Zrestartowany uczestnik musi najpierw sprawdzić
ponownie u koordynatora, zanim będzie mógł zdecydować
o uznaniu transakcji za zatwierdzoną.
• Tak więc każdy uczestnik, który zagłosuje na „tak”, musi
być właściwie przygotowany na wykoanie obu akcji –
ponowienie lub cofnięci aktualizacji.
18
Zatwierdzenie dwufazowe (cd)
W 2PC są trzy miejsca, w których proces czeka na

wiadomość :
– uczestnik oczekuje na wiadomość < prepare T > od
koordynatora
– koordynator czeka na wiadomość < ready T > od
wszystkich uczestników
– uczestnik oczekuje na komunikat < commit T> lub <
abort T > od koordynatora
19
Zatwierdzenie dwufazowe (cd)
Akcje po przekroczeniu limitu czasu :

– ad.1. jednostronne przerwanie po time_out (uczestnik)
– ad.2. jednostronne przerwanie po time_out
(koordynator)
– ad.3. węzeł zostaje zablokowany
20
Protokoły restartu i zakończenia
• 2PC jest odporny na awarie w tym sensie, że każdy
nieudany i ponownie uruchomiony proces wznawia swoją
pracę w ostatnim zapamiętanym stanie
• 2PC nie jest odporny na awarie w tym sensie, że wszystkie
procesy gwarantują aktywny postęp w kierunku
globalnego zatwierdzenia lub wycofania
• Dwa rozszerzenia podstawowego 2PC
– Protokół restartu – określa, jak powinien postępować protokół
zakończony niepowodzeniem i restartowany
– Protokół zakończenia – określa, jak proces powinien zachowywać
się po przekroczeniu limitu czasu podczas oczekiwania na jakiś
komunikat
21
Protokoły restartu i zakończenia
• Ponieważ wszyscy uczestnicy stosują ten sam protokół,
musimy określić cztery przypadki:
1. Protokół restartu koordynatora – kontynuacja protokołu
koordynatora po restarcie koordynatora
2. Protokół zakończenia koordynatora – zachowanie koordynatora
po przekroczeniu limitu czasu
3. Protokół restartu uczestnika – kontynuacja protokołu uczestnika
po restarcie uczestnika
4. Protokół zakończenia uczestnika – zachowanie uczestnika po
przekroczeniu limitu czasu
22
Protokół zakończenia dla 2PC
• Najprostszy protokół zakończenia jest następujący:
Uczestnik P pozostaje zablokowany do czasu ponownego
nawiązania komunikacji z koordynatorem. Następnie
koordynator może przekazać P odpowiednią decyzję
Wada : P może być niepotrzebnie blokowany przez długi czas

• Uczestnicy mogą wymieniać wiadomości bezpośrednio (bez
pośrednictwa koordynatora)
• Zakładamy, że koordynator dołącza listę uczestników do
wiadomości < prepare T >, którą wysyła do każdego z nich
• Fakt, że uczestnicy nie znają się przed otrzymaniem
komunikatu nie ma znaczenia, ponieważ uczestnik może
jednostronnie zdecydować się na przerwanie transakcji
23
• Kooperacyjny protokół zakończenia:
Uczestnik P (inicjator), który przekroczył limit czasu w okresie

niepewności, wysyła wiadomość < decision request > do każdego
innego procesu Q (działającego), aby zapytać, czy Q albo zna decyzję,
albo może jednostronnie ją podjąć ponieważ nie wszedł w stan
gotowości
• Q już zdecydował o zatwierdzeniu (lub przerwaniu) – Q wysyła

zatwierdzenie lub przerwanie do P, a P odpowiednio decyduje
• Q jeszcze nie głosował – Q może jednostronnie zdecydować o
przerwaniu. Następnie wysyła <abort T> do P, a P decyduje o
przerwaniu
• Q głosował na Tak, ale nie podjął jeszcze decyzji
24
2 PC z protokołami restartu i
zakończenia
• Diagram stanu dla 2PC z protokołami restartu i
zakończenia:
– Przejścia False są wyzwalane podczas restartu po
awarii procesu. Po określeniu ostatniego stanu procesu
na podstawie wpisów w dzienniku procesu przejście
jest dokonywane bez żadnych dalszych warunków
wstępnych
– Przejścia True są wyzwalane po przekroczeniu limitu
czasu i są również wykonywane bez dalszych
warunków wstępnych
25
Diagram stanów 2PC - koordynator
initial T or F
T or F prepare_to_commit
variant
collecting
commit abort abort

commit
T or F Ack T or F
C-pending A-pending
forgotten
26
Diagram stanów 2PC - uczestnik
T or F
initial
Prepared/ Prepared/
yes no
T or F
prepared
commit/ abort/
ack ack
committed aborted
Commit/ack Abort/ack
27
Topologie komunikacji dla 2PC
• Topologia komunikacyjna protokołu to specyfikacja, kto
do kogo wysyła komunikaty
Scentralizowane 2PC
Koordynator
Uczestnicy
28
Topologie komunikacji dla 2PC
Zdecentralizowany 2PC (zmniejszona złożoność czasowa)
Liniowy 2PC (zmniejszona złożoność wiadomości)
29
Zatwierdzenie trójfazowe (3PC)
• Protokół jest nieblokujący w przypadku jeżeli nie nastąpi
całkowita awaria węzłów
• Protokół może powodować podejmowanie niespójnych
decyzji w przypadku awarii komunikacji
Zakładamy, że:
• Wszystkie węzły, które nie uległy awarii (działające) mogą
się ze sobą komunikować
• Proces, który przekroczył limit czasu oczekiwania na
wiadomość od procesu q, wie, że q nie działa i dlatego
żadne przetwarzanie nie może się tam odbywać (żaden
inny proces nie może się komunikować z q)
30
• Który z procesów zaangażowanych w transakcję pełni rolę
koordynatora?
• Wybór koordynatora zależy od:
– Komputer kliencki inicjatora transakcji: serwer aplikacji, serwer
bazy danych, ORB
– Niezawodność i szybkość uczestników – ilu uczestników obejmuje
transakcja?
– Topologia i protokół komunikacji
• Najprościej – na koordynatora wybiera się inicjatora
transakcji
• Jeśli inicjatorem jest klient, często bardziej sensowne jest
wybranie serwera danych jako koordynatora
31
Właściwość nieblokująca:
Jeśli jakikolwiek działający proces jest niepewny, żaden
proces (działający lub uszkodzony) nie mógł zdecydować
się na Zatwierdzenie
Jeśli działające węzły odkryją, że wszystkie są niepewne,

mogą podjąć decyzję o przerwaniu, wiedząc, że procesy
zakończone niepowodzeniem nie zdecydowały o
zatwierdzeniu. Gdy procesy, które zakończyły się
niepowodzeniem, zostaną przywrócone, można im
powiedzieć, aby zdecydowały się na przerwanie. W ten
sposób zapobiega się blokowaniu
• Czy 2PC przestrzega właściwości NB? NIE 32
1. Koordynator wysyła wiadomość < prepare T > do
wszystkich uczestników
2. Gdy uczestnik otrzyma wiadomość < prepare T >,
odpowiada komunikatem TAK lub NIE , w zależności
od swojego głosu. Jeśli uczestnik wyśle NIE , decyduje
o przerwaniu i zatrzymuje się
3. Koordynator zbiera głosy od wszystkich uczestników.
Jeśli któryś z nich był NIE lub jeśli koordynator
zagłosował na Nie, wówczas koordynator decyduje o
przerwaniu, wysyła < abort T > do wszystkich
uczestników, którzy głosowali na TAK i zatrzymuje się.
W przeciwnym razie koordynator wysyła < pre-commit
T > wiadomości do wszystkich uczestników
33
4. Uczestnik, który zagłosował na Tak, czeka na wiadomość
< pre-commit T > lub < abort T > od koordynatora. Jeśli
otrzyma < abort T > , uczestnik decyduje o przerwaniu i
zatrzymuje się. Jeśli otrzyma < pre-commit T >,
odpowiada komunikatem ACK do koordynatora
5. Koordynator zbiera ACK. Gdy wszystkie zostaną
odebrane, decyduje o zatwierdzeniu, wysyła < commit T >
do wszystkich uczestników i zatrzymuje się
6. Uczestnik czeka na wiadomość < commit T > od
koordynatora. Po otrzymaniu tej wiadomości decyduje się
na zatwierdzenie i zatrzymuje się
34
3PC – przekroczenie limitu czasu akcji
To, co proces powinien zrobić, gdy przekroczy limit czasu,
zależy od wiadomości, na którą czekał :
1. W kroku (2) uczestnicy czekają na wiadomość
< prepare T >
2. W kroku (3) koordynator czeka na głosy
3. W kroku (4) uczestnicy czekają na wiadomość
< pre-commit T > lub < abort T >
4. W kroku (5) koordynator czeka na potwierdzenia
5. W kroku (6) uczestnicy czekają na komunikat
< commit T >
35
3PC – przekroczenie limitu czasu akcji
• Przypadki (1) i (2) są obsługiwane dokładnie tak samo jak
w 2PC
• W przypadku (4) koordynator może podjąć decyzję o
zatwierdzeniu, podczas gdy jakiś niedziałający uczestnik
jest niepewny
• W przypadku (3) uczestnik musi komunikować się z
innymi procesami, aby podjąć spójną decyzję
• W przypadku (5) uczestnik musi komunikować się z
innymi procesami, aby podjąć spójną decyzję.
36
• Stan procesu w odniesieniu do wiadomości, którą wysłał
lub otrzymał :
– Przerwany : głosował na Nie lub otrzymał <abort T>
– Niepewny : proces jest w niepewnym okresie
– Zatwierdzalny : proces otrzymał <pre-commit T>, ale jeszcze nie
otrzymał <commit T>
– Zatwierdzony : proces otrzymał <commit T>
• Przekroczenie limitu czasu przez uczestnika w
przypadkach (3) lub (5) inicjuje protokół wyborczy
• Protokół wyborczy obejmuje wszystkie działające procesy
i skutkuje „wyborem” nowego koordynatora (stary musiał
ulec awarii, inaczej żaden uczestnik nie przekroczyłby
limitu czasu!)
37
Nowy koordynator wysyła wiadomość < state-req > do
wszystkich uczestników, którzy brali udział w wyborach.
Każdy uczestnik odpowiada na tę wiadomość wysyłając swój
stan. Koordynator zbiera te stany i postępuje zgodnie z
następującym protokołem zakończenia :
Przypadek 1: Jeśli jakiś proces zostanie przerwany, koordynator

decyduje o przerwaniu, wysyła komunikaty < abort T > do
wszystkich uczestników i zatrzymuje się.
Przypadek 2 : Jeśli jakiś proces jest zatwierdzony, koordynator

decyduje o zatwierdzeniu, wysyła komunikaty < commit T >
do wszystkich uczestników i zatrzymuje się.
38
Protokół terminacji dla 3PC
Przypadek 3: Jeśli wszystkie procesy, które zgłosiły swój
stan, są Niepewne, koordynator podejmuje decyzję o
przerwaniu, wysyła komunikaty < abort T > do
wszystkich uczestników i zatrzymuje się.
Przypadek 4: Jeśli jakiś proces jest Zatwierdzalny, ale żaden
nie jest Zatwierdzony, koordynator najpierw wysyła
komunikaty <pre-commit T> do wszystkich procesów,
które zgłosiły Niepewność, i czeka na potwierdzenia od
tych procesów. Po otrzymaniu tych potwierdzeń
koordynator decyduje o zatwierdzeniu, wysyła wiadomości
< commit T > do wszystkich uczestników i zatrzymuje się.
Uczestnik, który otrzymuje komunikat <commit T> (lub

<abort T>), wykonuje Commit (lub Abort) i zatrzymuje
39
Poprawność 3PC i jego protokołu
zakończenia
Twierdzenie : W przypadku jeżeli nie nastąpi
całkowita awaria węzłów, 3PC i jego protokół
zakończenia nigdy nie powodują blokowania
procesów
Twierdzenie : W ramach 3PC i jego protokołu

zakończenia wszystkie procesy operacyjne
podejmują tę samą decyzję
40
Algorytm drzewa 2PC
• Który z procesów zaangażowanych w transakcję pełni rolę
koordynatora?
• LAN kontra WAN
– Każdy może rozmawiać z każdym
– Inicjator nie zna wszystkich uczestników (i prawdopodobnie nie
może się z nimi komunikować bezpośrednio i skutecznie)
• Spostrzeżenie:
– Podczas wykonywania transakcji zaangażowane procesy
dynamicznie tworzą drzewo z inicjatorem transakcji jako
korzeniem; każda krawędź w drzewie odpowiada dynamicznie
ustanawianemu łączu komunikacyjnemu
41
Algorytm drzewa 2PC
• W hierarchicznym protokole zatwierdzenia przepływ
komunikatów i zapisywanie wpisów dziennika wynika z
dwóch ról: węzła pośredniego i uczestnika w odniesieniu
do wywołującego i koordynatora jego poddrzewa
Proces 0
inicjator
Proces 1 Proces 3
Proces 2 Proces 4 Proces 5
Komunikacja podczas protokołu zatwierdzenia

42
initiator Process 1 Process 2 Process 3 Process 4 Process 5
prepare
prepare
prepare
prepare
prepare
Yes
Yes
Yes
Yes
Yes
commit
commit
..........
43
Zoptymalizowane algorytmy dla
Co możemy zrobić:
1. Zmniejszenie liczby komunikatów i liczby zapisów
dziennika
2. Skrócenie „ścieżki krytycznej” od początku protokołu
zatwierdzenia do momentu zwolnienia lokalnych blokad
3. Zmniejszenie prawdopodobieństwa zablokowania
44
• Liczbę komunikatów i wymuszonych zapisów dziennika
można zmniejszyć, wprowadzając określone konwencje
dotyczące zakładanego zachowania procesu (tj. domyślnej
reakcji) w przypadku braku bardziej wyraźnych informacji
Np. jeśli uczestnik nie zapisał zatwierdzenia lub przerwania w
dzienniku i w związku z tym mógł utracić te informacje w
przypadku lokalnej awarii, ten uczestnik mógłby
domyślnie skontaktować się z koordynatorem w celu
uzyskania brakujących informacji (problem w przypadku
gdy koordynator już obciął swój dziennik i zapomniał o
transakcji)
45
• Podstawowy 2PC:
– 4N wiadomości; 2N+2 wpisy w dzienniku (koordynator -
rozpoczęcie i zatwierdzenie lub wycofanie wpisu w dzienniku)
• Gdy brakuje pewnych informacji o zachowaniu transakcji
– dwie odmiany 2PC
– Domniemane przerwanie (PA)
– Domniemane zatwierdzenie (PC)
• Domniemane przerwanie 2PC zostało uznane za metodę z
wyboru i zostało wybrane dla standardu branżowego
X/Open XA
46
Heterogeniczni koordynatorzy
zatwierdzeń
• W miarę jak sieci rosną razem, aplikacje coraz częściej
muszą uzyskiwać dostęp do serwerów i danych
znajdujących się w heterogenicznych systemach,
wykonując transakcje obejmujące wiele węzłów sieci. Te
węzły mają różne monitory TP i różne protokoły
zatwierdzania
• Jeśli każdy zarządca transakcji obsługuje standardowy i
otwarty protokół zatwierdzania, to przenośność i
interoperacyjność między nimi jest stosunkowo łatwa do
osiągnięcia
• Istnieją dwa standardowe protokoły zatwierdzania i
interfejsy programowania aplikacji:
– LU6.2 (IBM) — zawarte w CICS i CICS API
– OSI-TP - w połączeniu z X/Open DTP 47
Zarządcy transakcji zamkniętych i
otwartych
• Niektórzy zarządcy transakcji mają otwarty protokół zatwierdzenia:
zarządcy zasobów mogą uczestniczyć w podejmowaniu decyzji o
zatwierdzeniu, a formaty komunikatów i protokoły zatwierdzenia są
publiczne
CICS, Decdtm, TOPEND (NCR), Transarc TM
• Niektórzy zarządcy transakcji mają zamknięty protokół zatwierdzenia:
zarządcy zasobów nie mogą uczestniczyć w podejmowaniu decyzji o
zatwierdzeniu. Terminem tym określa się systemy TP, które posiadają
wyłącznie prywatne protokoły i w związku z tym nie mogą
współpracować z innymi systemami przetwarzania transakcji
IBM IMS, Tandem TMF
48

RBD Lectures Merged

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RBD Lectures Merged

Uploaded by

Copyright:

Available Formats

Principles of Distributed Database

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

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

◼ A number of autonomous processing elements (not

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

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

A distributed database is a collection of multiple, logically

A distributed database management system (Distributed

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

◼ A timesharing computer system

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

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

◼ Data stored at a number of sites → each site logically

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

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

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

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

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

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

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

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

On-demand, reliable services provided over the Internet in

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

❑ Distributed DBMS promises

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

 Transparent management of distributed, fragmented,

 Improved reliability/availability through distributed

 Easier and more economical system expansion

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

◼ Transparency is the separation of the higher-level

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

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

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

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

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

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

◼ Replicated components and data should make distributed

• Distributed transaction support requires implementation of

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

◼ Proximity of data to its points of use

❑ Requires some support for fragmentation and replication

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

◼ Issue is database scaling and workload scaling

◼ Adding processing and storage power

◼ Scale-out: add more servers

❑ Scale-up: increase the capacity of one server → has limits

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

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

◼ Distributed database design

◼ Distributed query processing

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

◼ Distributed concurrency control

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

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

◼ Alternative distribution approaches

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

❑ Distributed DBMS architecture

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

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

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

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

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

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

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

R1 S1 T1 from S1 31(500-100) 1200

R2 S1 T1 from S1 21(650-150) 2800