2 Distribution Design

Principles of Distributed Database
Systems
TS. Phan Thị Hà_PTIT
© 2020, M.T. Özsu & P. Valduriez: TS.

1
Phan Thị HÀ_PTIT
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
2
Phan Thị HÀ_PTIT
Outline
❑ Fragmentation
❑ Data distribution
❑ Combined approaches

3
Phan Thị HÀ_PTIT
Distribution Design

4
Phan Thị HÀ_PTIT
Outline
❑ Fragmentation
❑

5
Phan Thị HÀ_PTIT
Fragmentation
◼ Can't we just distribute relations?

◼ What is a reasonable unit of distribution?
❑ relation
◼ views are subsets of relations ➔ locality
◼ extra communication
❑ fragments of relations (sub-relations)
◼ concurrent execution of a number of transactions that access
different portions of a relation
◼ views that cannot be defined on a single fragment will require extra
processing
◼ semantic data control (especially integrity enforcement) more
difficult

6
Phan Thị HÀ_PTIT
Example Database

7
Phan Thị HÀ_PTIT
Fragmentation Alternatives – Horizontal
PROJ1 : projects with budgets

less than $200,000
PROJ2 : projects with budgets
greater than or equal
to $200,000

8
Phan Thị HÀ_PTIT
Fragmentation Alternatives – Vertical
PROJ1: information about

project budgets
PROJ2: information about
project names and
locations

9
Phan Thị HÀ_PTIT
Correctness of Fragmentation
◼ Completeness
❑ Decomposition of relation R into fragments R1, R2, ..., Rn is
complete if and only if each data item in R can also be found in
some Ri
◼ Reconstruction
❑ If relation R is decomposed into fragments R1, R2, ..., Rn, then
there should exist some relational operator ∇ such that
R = ∇1≤i≤nRi
◼ Disjointness
❑ If relation R is decomposed into fragments R1, R2, ..., Rn, and
data item di is in Rj, then di should not be in any other fragment
Rk (k ≠ j ).

10
Phan Thị HÀ_PTIT
Allocation Alternatives
◼ Non-replicated
❑ partitioned : each fragment resides at only one site
◼ Replicated
❑ fully replicated : each fragment at each site
❑ partially replicated : each fragment at some of the sites
◼ Rule of thumb:
If read-only queries << 1, replication is advantageous,

update queries
otherwise replication may cause problems

11
Phan Thị HÀ_PTIT
Comparison of Replication Alternatives

12
Phan Thị HÀ_PTIT
Fragmentation
◼ Horizontal Fragmentation (HF)

❑ Primary Horizontal Fragmentation (PHF)
❑ Derived Horizontal Fragmentation (DHF)
◼ Vertical Fragmentation (VF)

◼ Hybrid Fragmentation (HF)

13
Phan Thị HÀ_PTIT
PHF – Information Requirements
◼ Database Information
❑ relationship
❑ cardinality of each relation: card(R)

14
Phan Thị HÀ_PTIT
PHF - Information Requirements
◼ Application Information
❑ simple predicates : Given R[A1, A2, …, An], a simple predicate
pj is
pj : Ai θValue
where θ  {=,<,≤,>,≥,≠}, Value  Di and Di is the domain of Ai.
For relation R we define Pr = {p1, p2, …,pm}
Example :
PNAME = "Maintenance"
BUDGET ≤ 200000
❑ minterm predicates : Given R and Pr = {p1, p2, …,pm}
define M = {m1,m2,…,mr} as
M = { mi | mi = pjPr pj* }, 1≤j≤m, 1≤i≤z
where pj* = pj or pj* = ¬(pj).

15
Phan Thị HÀ_PTIT
Example
m1: PNAME="Maintenance"  BUDGET≤200000
m2: NOT(PNAME="Maintenance")  BUDGET≤200000
m3: PNAME= "Maintenance"  NOT(BUDGET≤200000)
m4: NOT(PNAME="Maintenance")  NOT(BUDGET≤200000)

16
Phan Thị HÀ_PTIT
❑ minterm selectivities: sel(mi)
◼ The number of tuples of the relation that would be accessed by a
user query which is specified according to a given minterm
predicate mi.
❑ access frequencies: acc(qi)
◼ The frequency with which a user application qi accesses data.
◼ Access frequency for a minterm predicate can also be defined.

17
Phan Thị HÀ_PTIT
Primary Horizontal Fragmentation
Definition :
Rj = Fj(R), 1 ≤ j ≤ w
where Fj is a selection formula, which is (preferably) a minterm
predicate.
Therefore,
A horizontal fragment Ri of relation R consists of all the tuples of R
which satisfy a minterm predicate mi.

Given a set of minterm predicates M, there are as many horizontal
fragments of relation R as there are minterm predicates.
Set of horizontal fragments also referred to as minterm fragments.

18
Phan Thị HÀ_PTIT
PHF – Algorithm
Given: A relation R, the set of simple predicates Pr

Output: The set of fragments of R = {R1, R2,…,Rw} which
obey the fragmentation rules.
Preliminaries :
❑ Pr should be complete
❑ Pr should be minimal

19
Phan Thị HÀ_PTIT
Completeness of Simple Predicates
◼ A set of simple predicates Pr is said to be complete if

and only if the accesses to the tuples of the minterm
fragments defined on Pr requires that two tuples of the
same minterm fragment have the same probability of
being accessed by any application.
◼ Example :
❑ Assume PROJ[PNO,PNAME,BUDGET,LOC] has two
applications defined on it.
❑ Find the budgets of projects at each location. (1)
❑ Find projects with budgets less than $200000. (2)

20
Phan Thị HÀ_PTIT
Completeness of Simple Predicates
According to (1),
Pr={LOC=“Montreal”,LOC=“New York”,LOC=“Paris”}
which is not complete with respect to (2).

Modify
Pr ={LOC=“Montreal”,LOC=“New York”,LOC=“Paris”,
BUDGET≤200000,BUDGET>200000}
which is complete.

21
Phan Thị HÀ_PTIT
Minimality of Simple Predicates
◼ If a predicate influences how fragmentation is performed,

(i.e., causes a fragment f to be further fragmented into,
say, fi and fj) then there should be at least one
application that accesses fi and fj differently.
◼ In other words, the simple predicate should be relevant
in determining a fragmentation.
◼ If all the predicates of a set Pr are relevant, then Pr is
minimal.
acc(mi ) acc(m j )
=
card( fi ) card( f j )

22
Phan Thị HÀ_PTIT
Minimality of Simple Predicates
Example :
Pr ={LOC=“Montreal”,LOC=“New York”, LOC=“Paris”,
BUDGET≤200000,BUDGET>200000}
is minimal (in addition to being complete). However, if we

add
PNAME = “Instrumentation”
then Pr is not minimal.

23
Phan Thị HÀ_PTIT
COM_MIN Algorithm
Given: a relation R and a set of simple predicates Pr

Output: a complete and minimal set of simple predicates
Pr' for Pr
Rule 1: a relation or fragment is partitioned into at least

two parts which are accessed differently by at
least one application.

24
Phan Thị HÀ_PTIT
COM_MIN Algorithm
 Initialization :
❑ find a pi  Pr such that pi partitions R according to Rule 1
❑ set Pr' = pi ; Pr Pr – {pi} ; F  {fi}
 Iteratively add predicates to Pr' until it is complete
❑ find a pj  Pr such that pj partitions some fk defined according to
minterm predicate over Pr' according to Rule 1
❑ set Pr' = Pr'  {pi}; Pr Pr – {pi}; F  F  {fi}
❑ if pk  Pr' which is nonrelevant then
Pr'  Pr – {pi}
F  F – {fi}

25
Phan Thị HÀ_PTIT
PHORIZONTAL Algorithm
Makes use of COM_MIN to perform fragmentation.

Input: a relation R and a set of simple predicates Pr
Output: a set of minterm predicates M according to which
relation R is to be fragmented
 Pr'  COM_MIN (R,Pr)

 determine the set M of minterm predicates
 determine the set I of implications among pi  Pr
 eliminate the contradictory minterms from M

26
Phan Thị HÀ_PTIT
PHF – Example
◼ Two candidate relations : PAY and PROJ.

◼ Fragmentation of relation PAY
❑ Application: Check the salary info and determine raise.
❑ Employee records kept at two sites  application run at two
sites
❑ Simple predicates
p1 : SAL ≤ 30000
p2 : SAL > 30000
Pr = {p1,p2} which is complete and minimal Pr'=Pr
❑ Minterm predicates
m1 : (SAL ≤ 30000)
m2 : NOT(SAL ≤ 30000) = (SAL > 30000)

27
Phan Thị HÀ_PTIT
PHF – Example

28
Phan Thị HÀ_PTIT
PHF – Example
◼ Fragmentation of relation PROJ
❑ Applications:
◼ Find the name and budget of projects given their no.
❑ Issued at three sites
◼ Access project information according to budget
❑ one site accesses ≤200000 other accesses >200000
❑ Simple predicates
❑ For application (1)
p1 : LOC = “Montreal”
p2 : LOC = “New York”
p3 : LOC = “Paris”
❑ For application (2)
p4 : BUDGET ≤ 200000
p5 : BUDGET > 200000
❑ Pr = Pr' = {p1,p2,p3,p4,p5}
29
Phan Thị HÀ_PTIT
PHF – Example
◼ Fragmentation of relation PROJ continued

❑ Minterm fragments left after elimination
m1 : (LOC = “Montreal”)  (BUDGET ≤ 200000)
m2 : (LOC = “Montreal”)  (BUDGET > 200000)
m3 : (LOC = “New York”)  (BUDGET ≤ 200000)
m4 : (LOC = “New York”)  (BUDGET > 200000)
m5 : (LOC = “Paris”)  (BUDGET ≤ 200000)
m6 : (LOC = “Paris”)  (BUDGET > 200000)

30
Phan Thị HÀ_PTIT
PHF – Example

31
Phan Thị HÀ_PTIT
PHF – Correctness
◼ Completeness
❑ Since Pr' is complete and minimal, the selection predicates are
complete
◼ Reconstruction
❑ If relation R is fragmented into FR = {R1,R2,…,Rr}
R = Ri FR Ri
◼ Disjointness
❑ Minterm predicates that form the basis of fragmentation should
be mutually exclusive.

32
Phan Thị HÀ_PTIT
Derived Horizontal Fragmentation
◼ Defined on a member relation 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.

33
Phan Thị HÀ_PTIT
DHF – Definition
Given a link L where owner(L)=S and member(L)=R, the

derived horizontal fragments of R are defined as
Ri = R ⋉F Si, 1≤i≤w
where w is the maximum number of fragments that will be
defined on R and
Si = Fi (S)
where Fi is the formula according to which the primary

horizontal fragment Si is defined.

34
Phan Thị HÀ_PTIT
DHF – Example
Given link L1 where owner(L1)=SKILL and member(L1)=EMP

EMP1 = EMP ⋉ SKILL1
EMP2 = EMP ⋉ SKILL2
where
SKILL1 = SAL≤30000(SKILL)
SKILL2 = SAL>30000(SKILL)

35
Phan Thị HÀ_PTIT
DHF – Correctness
◼ Completeness
❑ Referential integrity
❑ Let R be the member relation of a link whose owner is relation S
which is fragmented as FS = {S1, S2, ..., Sn}. Furthermore, let A
be the join attribute between R and S. Then, for each tuple t of
R, there should be a tuple t' of S such that
t[A] = t' [A]
◼ Reconstruction
❑ Same as primary horizontal fragmentation.
◼ Disjointness
❑ Simple join graphs between the owner and the member
fragments.

36
Phan Thị HÀ_PTIT
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

37
Phan Thị HÀ_PTIT
Vertical Fragmentation
◼ Overlapping fragments
❑ grouping
◼ Non-overlapping fragments
❑ splitting
We do not consider the replicated key attributes to be

overlapping.
Advantage:
Easier to enforce functional dependencies
(for integrity checking etc.)

38
Phan Thị HÀ_PTIT
VF – Information Requirements
❑ 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,…, qq} that will run on the relation
R[A1, A2,…, An],
 1 if attribute Aj is referenced by query qi

use(qi,Aj) = 
 0 otherwise
use(qi,•) can be defined accordingly

39
Phan Thị HÀ_PTIT
VF – Definition of use(qi,Aj)
Consider the following 4 queries for relation PROJ

q1: SELECT BUDGET q2: SELECT PNAME,BUDGET
FROM PROJ FROM PROJ
WHERE PNO=Value
q3: SELECT PNAME q4: SELECT SUM(BUDGET)
FROM PROJ FROM PROJ
WHERE LOC=Value WHERE LOC=Value

40
Phan Thị HÀ_PTIT
VF – Affinity Measure aff(Ai,Aj)
The attribute affinity measure between two attributes Ai and Aj

of a relation R[A1, A2, …, An] with respect to the set of
applications Q = (q1, q2, …, qq) is defined as follows :
aff (Ai, Aj) =  (query access)

all queries that access A and A
i j

access
query access = access frequency of a query 
execution
all sites

41
Phan Thị HÀ_PTIT
VF – Calculation of aff(Ai, Aj)
Assume each query in the previous example accesses the attributes once
during each execution.
S1 S2 S3
Also assume the access frequencies q1 15 20 10
q2 5 0 0
q3 25 25 25
q4 3 0 0
Then
aff(A1, A3) = 15*1 + 20*1+10*1
= 45
and the attribute affinity matrix AA is
(Let A1=PNO, A2=PNAME, A3=BUDGET,
A4=LOC)

42
Phan Thị HÀ_PTIT
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.
AM =  (affinity of Ai and Aj with their neighbors)
i j

43
Phan Thị HÀ_PTIT
Bond Energy Algorithm
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.

44
Phan Thị HÀ_PTIT
Bond Energy Algorithm
“Best” placement? Define contribution of a placement:
cont(Ai, Ak, Aj) = 2bond(Ai, Ak)+2bond(Ak, Al) –2bond(Ai, Aj)
where
n
bond(Ax,Ay) = 
z =1
aff(A ,A )aff(A ,A )
z x z y

45
Phan Thị HÀ_PTIT
BEA – Example
Consider the following AA matrix and the corresponding CA matrix where
PNO and PNAME have been placed. Place BUDGET:
Ordering (0-3-1) :
cont(A0,BUDGET,PNO) = 2bond(A0, BUDGET)+2bond(BUDGET, PNO)
–2bond(A0 , PNO)
= 8820
Ordering (1-3-2) :
cont(PNO,BUDGET,PNAME) = 10150
Ordering (2-3-4) :
cont (PNAME,BUDGET,LOC) = 1780

46
Phan Thị HÀ_PTIT
BEA – Example
◼ Therefore, the CA matrix has the form
◼ When LOC is placed, the final form of the CA matrix

(after row organization) is

47
Phan Thị HÀ_PTIT
VF – Algorithm
How can you divide a set of clustered attributes {A1, A2,

…, An} into two (or more) sets {A1, A2, …, Ai} and {Ai, …,
An} such that there are no (or minimal) applications that
access both (or more than one) of the sets.

48
Phan Thị HÀ_PTIT
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

49
Phan Thị HÀ_PTIT
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)

50
Phan Thị HÀ_PTIT
VF – Correctness
A relation R, defined over attribute set A and key K,

generates the vertical partitioning FR = {R1, R2, …, Rr}.
◼ Completeness
❑ The following should be true for A:
A =  ARi
◼ Reconstruction
❑ Reconstruction can be achieved by
R = ⋈K Ri, Ri  FR
◼ Disjointness
❑ TID's are not considered to be overlapping since they are
maintained by the system
❑ Duplicated keys are not considered to be overlapping
51
Phan Thị HÀ_PTIT
Hybrid Fragmentation

52
Phan Thị HÀ_PTIT
Reconstruction of HF

53
Phan Thị HÀ_PTIT
Outline
❑
❑ Data distribution
❑

54
Phan Thị HÀ_PTIT
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)

55
Phan Thị HÀ_PTIT
Information Requirements
◼ Database information
❑ selectivity of fragments
❑ size of a fragment
◼ Application information
❑ access types and numbers
❑ access localities
◼ Communication network information
❑ unit cost of storing data at a site
❑ unit cost of processing at a site
◼ Computer system information
❑ bandwidth
❑ latency
❑ communication overhead
56
Phan Thị HÀ_PTIT
Allocation
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

57
Phan Thị HÀ_PTIT
Allocation Model
General Form
min(Total Cost)
subject to
response time constraint
storage constraint
processing constraint
Decision Variable
1 if fragment Fi is stored at site Sj
xij =
0 otherwise

58
Phan Thị HÀ_PTIT
Allocation Model
◼ Total Cost
 query processing cost +

all queries
  cost of storing a fragment at a site

all sites all fragments
◼ Storage Cost (of fragment Fj at Sk)

(unit storage cost at Sk)  (size of Fj)  xjk
◼ Query Processing Cost (for one query)

processing component + transmission component
59
Phan Thị HÀ_PTIT
Allocation Model
◼ Query Processing Cost
Processing component
access cost + integrity enforcement cost + concurrency control cost
❑ Access cost
  (no. of update accesses+ no. of read accesses) 

xij  local processing cost at a site
❑ Integrity enforcement and concurrency control costs

◼ Can be similarly calculated

60
Phan Thị HÀ_PTIT
Allocation Model
◼ Query Processing Cost

Transmission component
cost of processing updates + cost of processing retrievals
❑ Cost of updates
  update message cost +

  acknowledgment cost
❑ Retrieval Cost
 min all sites (cost of retrieval command +

all fragments cost of sending back the result)

61
Phan Thị HÀ_PTIT
Allocation Model
◼ Constraints
❑ Response Time
execution time of query ≤ max. allowable response time for that query
❑ Storage Constraint (for a site)
 storage requirement of a fragment at that site 

storage capacity at that site
all fragments
❑ Processing constraint (for a site)
 processing load of a query at that site 

all queries processing capacity of that site

62
Phan Thị HÀ_PTIT
Allocation Model
◼ Solution Methods
❑ FAP is NP-complete
❑ DAP also NP-complete
◼ Heuristics based on
❑ single commodity warehouse location (for FAP)
❑ knapsack problem
❑ branch and bound techniques
❑ network flow

63
Phan Thị HÀ_PTIT
Allocation Model
◼ Attempts to reduce the solution space

❑ assume all candidate partitionings known; select the “best”
partitioning
❑ ignore replication at first
❑ sliding window on fragments

64
Phan Thị HÀ_PTIT
Outline
❑
❑ Combined approaches

65
Phan Thị HÀ_PTIT
Combining Fragmentation & Allocation
Partition the data to dictate where it is located

◼ Workload-agnostic techniques
❑ Round-robin partitioning
❑ Hash partitioning
❑ Range partitioning
◼ Workload-aware techniques
❑ Graph-based approach

66
Phan Thị HÀ_PTIT
Round-robin Partitioning

67
Phan Thị HÀ_PTIT
Hash Partitioning

68
Phan Thị HÀ_PTIT
Range Partitioning

69
Phan Thị HÀ_PTIT
Workload-Aware Partitioning
◼ Examplar: Schism
❑ Graph G=(V,E) where
◼ vertex vi ∈ V represents a tuple in database,
◼ edge e=(vi,vj) ∈ E represents a query that accesses both tuples vi
and vj;
◼ each edge has weight counting the no. of queries that access both
tuples
❑ Perform vertex disjoint graph partitioning
◼ Each vertex is assigned to a separate partition

70
Phan Thị HÀ_PTIT
Incorporating Replication
◼ Replicate each vertex based on the no. of transactions

accessing that tuple ➔ each transaction accesses a
separate copy

71
Phan Thị HÀ_PTIT
Dealing with graph size
◼ Each tuple a vertex ➔ graph too big ➔ directory too big

◼ SWORD
❑ Use hypergraph model
❑ Compress the directory

72
Phan Thị HÀ_PTIT
Adaptive approaches
◼ Redesign as physical (network characteristics, available

storage) and logical (workload) changes occur.
◼ Most focus on logical
◼ Most follow combined approach
◼ Three issues:
 How to detect workload changes?
 How to determine impacted data items?
 How to perform changes efficiently?

73
Phan Thị HÀ_PTIT
Detecting workload changes
◼ Not much work

◼ Periodically analyze system logs
◼ Continuously monitor workload within DBMS
❑ SWORD: no. of distributed queries
❑ E-Store: monitor system-level metrics (e.g., CPU utilization) and
tuple-level access

74
Phan Thị HÀ_PTIT
Detecting affected data items
◼ Depends on the workload change detection method

◼ If monitoring queries ➔ queries will identify data items
❑ Apollo: generalize from “similar” queries
SELECT PNAME FROM PROJ WHERE BUDGET>20000 AND
LOC=‘LONDON’

SELECT PNAME FROM PROJ WHERE BUDGET>? AND LOC=‘?’
◼ If monitoring tuple-level access (E-Store), this will tell
you

75
Phan Thị HÀ_PTIT
Performing changes
◼ Periodically compute redistribution

❑ Not efficient
◼ Incremental computation and migration
❑ Graph representation ➔ look at changes in graph
◼ SWORD and AdaptCache: Incremental graph partitioning initiates
data migration for reconfiguration
❑ E-Store: determine hot tuples for which a migration plan is
prepared determine; cold tuple reallocation as well
◼ Optimization problem; real-time heuristic solutions
❑ Database cracking: continuously reorganize data to match query
workload
◼ Incoming queries are used as advice
◼ When a node needs data for a local query, this is hint that data may
need to be moved
76
Phan Thị HÀ_PTIT

2 Distribution Design

Uploaded by

Copyright:

Available Formats

2 Distribution Design

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

2 Distribution Design

Uploaded by

Copyright:

Available Formats

Principles of Distributed Database

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

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

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

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

◼ Can't we just distribute relations?

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

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

PROJ1 : projects with budgets

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

PROJ1: information about

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

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

If read-only queries << 1, replication is advantageous,

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

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

◼ Horizontal Fragmentation (HF)

◼ Vertical Fragmentation (VF)

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

❑ cardinality of each relation: card(R)

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

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

m2: NOT(PNAME="Maintenance")  BUDGET≤200000

m3: PNAME= "Maintenance"  NOT(BUDGET≤200000)

m4: NOT(PNAME="Maintenance")  NOT(BUDGET≤200000)

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

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

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

Given: A relation R, the set of simple predicates Pr

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

◼ A set of simple predicates Pr is said to be complete if

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

which is not complete with respect to (2).

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

◼ If a predicate influences how fragmentation is performed,

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

is minimal (in addition to being complete). However, if we

then Pr is not minimal.

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

Given: a relation R and a set of simple predicates Pr

Rule 1: a relation or fragment is partitioned into at least

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

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

Makes use of COM_MIN to perform fragmentation.

 Pr'  COM_MIN (R,Pr)

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

◼ Two candidate relations : PAY and PROJ.

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

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

◼ Fragmentation of relation PROJ continued

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

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

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

◼ Defined on a member relation of a link according to a

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

Given a link L where owner(L)=S and member(L)=R, the

where Fi is the formula according to which the primary

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

Given link L1 where owner(L1)=SKILL and member(L1)=EMP

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