4. Datenallokation in VDBS und PDBSdbs.uni-leipzig.de/file/mrdbs-ws0910-kap4.pdf · Sl i Afil...
Transcript of 4. Datenallokation in VDBS und PDBSdbs.uni-leipzig.de/file/mrdbs-ws0910-kap4.pdf · Sl i Afil...
4. Datenallokation in VDBS und PDBSF i d All k iFragmentierung und AllokationFragmentierungsvarianten – horizontale Fragmentierungen– vertikale Fragmentierung
hybride Fragmentierung– hybride Fragmentierung
VerteilungstransparenzDatenallokation für Parallele DBSDatenallokation für Parallele DBS – Verteilgrad – Varianten der horizontalen FragmentierungVarianten der horizontalen Fragmentierung
- Round Robin- Hash-Fragmentierung - Bereichsfragmentierung: einfach, verfeinert, mehrdimensionalBereichsfragmentierung: einfach, verfeinert, mehrdimensional
– Allokation der Fragmente – Datenallokation für Shared Disk / Shared Everything
WS0910, © Prof. Dr. E. Rahm 4 - 1
Datenallokation in kommerziellen DBS (Oracle, DB2)
Bestimmung der DatenverteilungF11 Rechner 1F1
F2
F32
F42
Rechner 2F3
F43 Rechner 3
F4
F5
Fragmentierung
Partitionenglobale
Relation R Fragmente
g g– Fragmente: Einheiten der Datenverteilung– wünschenswert: (horizontale / vertikale) Teile von Relationen
Allokation von Fragmenten– bestimmt weitgehend Ausführungsort von DB-Operationen
Zielkonflikt: Minimierung der Kommunikationskosten vs Lastbalancierung
WS0910, © Prof. Dr. E. Rahm 4 - 2
– Zielkonflikt: Minimierung der Kommunikationskosten vs. Lastbalancierung– ggf. replizierte Speicherung von Fragmenten
FragmentierungGründe für (horizontale bzw. vertikale) Fragmentierung– Lastbalancierungg– Nutzung von Lokalität– Reduzierung des Verarbeitungsumfangs für Anfragen – Unterstützung von Parallelverarbeitung– Bessere Administrierbarkeit sehr großer Tabellen (Sicherung,
Reorganisation)Reorganisation)
Anforderungen– Vollständigkeit: jedes Datenelement muss in wenigstens einem FragmentVollständigkeit: jedes Datenelement muss in wenigstens einem Fragment
enthalten sein– Rekonstruierbarkeit: Verlustfreiheit der Zerlegung– (weitestgehende) Disjunktheit
WS0910, © Prof. Dr. E. Rahm 4 - 3
Horizontale Fragmentierung
Zeilenweise Aufteilung von RelationenDefinition der Fragmentierung durch Selektionsprädikate Pi auf g g pder Relation: Ri := σPi (R) (1 ≤ i ≤ n)
KNR NAME GEBDAT FilialeK2 Schulz 02 11 1976 F
KNR NAME GEBDAT FilialeK5 Weber 17.03.1942 L
KUNDE1 = σFiliale = „L“ (KUNDE)K2 Schulz 02.11.1976 F
K4 Meier 23.08.1972 B
K3 Müller 04.07.1987 B
K1 Scholz 24 04 1959 F
KNR NAME GEBDAT FilialeK2 Schulz 02.11.1976 FK1 Scholz 24.04.1959 FK1 Scholz 24.04.1959 F
K5 Weber 17.03.1942 L
KNR NAME GEBDAT Filiale
KUNDE2 = σFiliale = „F“ (KUNDE)
KNR NAME GEBDAT FilialeK4 Meier 23.08.1972 BK3 Müller 04.07.1987 B
KUNDE3 = σFiliale = „B“ (KUNDE)
Globale Relation KUNDE
WS0910, © Prof. Dr. E. Rahm 4 - 4
Horizontale Fragmentierung (2)
Fragmentierungsprädikate sind so zu wählen, damit gilt– Vollständigkeit: jedes Tupel ist einem Fragment eindeutig zugeordnetg j p g g g– Fragmente sind disjunkt: Ri ∩ Rj = {} (i ≠ j))– Verlustfreiheit (Relation ist Vereinigung aller Fragmente):
R R (1 i )R = ∪ Ri (1 ≤ i ≤ n)
Vorteile– Anfragen können ggf. auf Teilmenge der Fragmente begrenzt werden g gg g g g– optimale Parallelisierbarkeit von Anfragen auf großen Tabellen
WS0910, © Prof. Dr. E. Rahm 4 - 5
Abgeleitete horizontale FragmentierungH i l F i i T b ll S i d üb P ädikHorizontale Fragmentierung einer Tabelle S wird über Prädikate einer anderen Relation R definiert, zu der S abhängig ist i f kti l Abhä i k it ( 1) üb F d hlü li.a. funktionale Abhängigkeit (n:1) über Fremdschlüssel-Primärschlüssel-BeziehungenBeispiel: Fragmentierung von Relation KONTO analog zu KUNDEBeispiel: Fragmentierung von Relation KONTO analog zu KUNDE
KTONR KNR KTOSTAND7654 K5 63,79
Globale Relation KONTO
KUNDE Partitionierung (über FILIALE)
KTONR KNR KTOSTAND
7654 K5 63,79
KTONR KNR KTOSTAND
KONTO1: Konten zu KUNDE1 (Filiale „L“)
KUNDE-Partitionierung (über FILIALE)bestimmt KONTO-Partitionierung
1234 K2 122,342345 K4 - 12,433231 K1 1222,227654 K5 63,79
1234 K2 122,343231 K1 1222,229876 K2 55,77
KONTO2: Konten zu KUNDE2 (Filiale F“)9876 K2 55,775498 K4 - 4506,77
KTONR KNR KTOSTAND2345 K4 - 12,435498 K4 4506 77
KONTO2: Konten zu KUNDE2 (Filiale „F )
WS0910, © Prof. Dr. E. Rahm 4 - 6
5498 K4 - 4506,77
KONTO3: Konten zu KUNDE3 (Filiale „B“)
Abgeleitete horizontale Fragmentierung (2)
Semi-Join zwischen Relationen S und R S R = π S-Attribute (S R)
– asymmetrischer Operator
Seien R R R Fragmente einer horizontalen FragmentierungSeien R1, R2, ... Rn Fragmente einer horizontalen Fragmentierung von R. Eine von R abgeleitete horizontale Fragmentierung einer Tabelle S hat die Fragmente g
Si = S Ri = S σPi (R) (1 ≤ i ≤ n)
effiziente Join-Verarbeitung zwischen R und Slokale Join D rchführ ng falls Fragmente R nd S am selben Rechner– lokale Join-Durchführung falls Fragmente Ri und Si am selben Rechner
– reduzierte Datenmengen für Suche nach Verbundpartnern
Vollständigkeit?
WS0910, © Prof. Dr. E. Rahm 4 - 7
Vollständigkeit?
Vertikale FragmentierungS l i A f il R l iSpaltenweise Aufteilung von RelationenDefinition der Fragmentierung durch Projektion
KNR NAME GEBDAT FilialeK2 Schulz 02.11.1976 FK4 M i 23 08 1972 BK4 Meier 23.08.1972 BK3 Müller 04.07.1987 BK1 Scholz 24.04.1959 FK5 Weber 17.03.1942 L
Globale Relation KUNDE
KNR NAME Filiale KNR GEBDATKNR NAME FilialeK2 Schulz FK4 Meier BK3 Müller B
KNR GEBDATK2 02.11.1976K4 23.08.1972K3 04.07.1987K1 24 04 1959K1 Scholz F
K5 Weber LK1 24.04.1959K5 17.03.1942
KUNDE1 = πKNR, NAME, Filiale (KUNDE) KUNDE2 = πKNR, GEBDAT (KUNDE)
WS0910, © Prof. Dr. E. Rahm 4 - 8
Vertikale Fragmentierung (2)
Vollständigkeit: – jedes Attribut in wenigstens 1 Fragment enthalten
Verlustfreie Zerlegung:– Primärschlüssel i.a. in jedem Fragment enthalten– JOIN-Operation zur Rekonstruktion des gesamten Tupels
V t il ?Vorteile?
WS0910, © Prof. Dr. E. Rahm 4 - 9
Hybride FragmentierungK bi i h i l d ik l F iKombination von horizontaler und vertikaler Fragmentierung
KNR NAME GEBDAT FilialeK2 Schulz 02.11.1976 FK4 Meier 23.08.1972 BK3 Müller 04.07.1987 B
Globale Relation KUNDE
K1 Scholz 24.04.1959 FK5 Weber 17.03.1942 L
KNR NAME FilialeK5 Weber L
KNR NAME FilialeK2 Schulz FK4 Meier B
KNR GEBDAT K2 02.11.1976K4 23.08.1972KNR NAME Filiale
K2 Schulz F
KUNDE11 = σFiliale = „L“ (KUNDE1)
K3 Müller BK1 Scholz FK5 Weber L
K3 04.07.1987K1 24.04.1959K5 17.03.1942
KUNDE1 = π (KUNDE) KUNDE2 = π (KUNDE)
K2 Schulz FK1 Scholz F
KNR NAME Fili l
KUNDE12 = σFiliale = „F“ (KUNDE1)
KUNDE1 = πKNR, NAME, Filiale (KUNDE) KUNDE2 = πKNR, GEBDAT (KUNDE)KNR NAME FilialeK4 Meier BK3 Müller B
KUNDE13 = σFiliale = „B“ (KUNDE1)
WS0910, © Prof. Dr. E. Rahm 4 - 10
Hybride Fragmentierung (2)a) vertikale gefolgt von horizontaler Partitionierung
R21
RR
R1 R22
R23
V V
R1 R2
H HH
R1 ∪
H HHR21 R22 R23 R21 R22 R23
Fragmentierungsbaum Operatorbaum (Rekonstruktion)
b) horizontale gefolgt von vertikaler Partitionierung
R11 R12
R
R
R2
R3
WS0910, © Prof. Dr. E. Rahm 4 - 11
Verteilungstransparenz g p
Beispiel 1:KUNDE KUNDE wurde horizontal in zwei Fragmente
KUNDE 1 KUNDE 2 KUNDE 2
Knoten 1 Knoten 2 Knoten 3
KUNDE wurde horizontal in zwei Fragmente zerlegt, wobei Fragment KUNDE2 an zwei Knoten repliziert gespeichert ist
Keine Transparenz:SELECT NAME INTO $NAME FROM Knoten1@KUNDE1
Knoten 1
SELECT NAME INTO $NAME FROM Knoten1@KUNDE1WHERE KNR = $KNO
IF NOT FOUND THENSELECT NAME INTO $NAME FROM Knoten3@KUNDE2
WHERE KNR = $KNO . . .Orts- und Replikationstransparenz:
Weglassen der Ortsbezeichnungen (Knoten@)– Weglassen der Ortsbezeichnungen (Knoten@)
Orts-, und Replikations- und Fragmentierungstransparenz:SELECT NAME INTO $NAME FROM KUNDE
WS0910, © Prof. Dr. E. Rahm 4 - 12
S C N N O $N O UNWHERE KNR = $KNO
Verteilungstransparenz (2)B i i l 2Beispiel 2: Hybride Fragmentierung KUNDE1 KUNDE2
KUNDE4KUNDE3KUNDE
FILIALE = „L“
FILIALE ≠ „L“U
KUNDE1 (KNR, NAME) KUNDE2 (KNR, GEBDAT, FILIALE) KUNDE3 (KNR, NAME, FILIALE) KUNDE4 (KNR, GEBDAT)
KUNDEi sei an Knoteni gespeichert;KUNDE1 zusätzlich an Knoten 5 und KUNDE4 an Knoten 6
Orts-, Replikations- und FragmentierungstransparenzUPDATE KUNDE SET FILIALE = "L" WHERE KNR = "K3"; (*Wechsel von B nach L*)( Wechsel von B nach L )
Orts- und Replikations-, keine FragmentierungstransparenzSELECT NAME INTO $Name FROM KUNDE3 WHERE KNR = "K3";
$SELECT GEBDAT INTO $Geb FROM KUNDE4 WHERE KNR = "K3";INSERT INTO KUNDE1 (KNR, NAME) VALUES ("K3", $Name)INSERT INTO KUNDE2 (KNR, GEBDAT, FILIALE) VALUES ("K3", $Geb, "L")DELETE KUNDE3 WHERE KNR "K3"
WS0910, © Prof. Dr. E. Rahm 4 - 13
DELETE KUNDE3 WHERE KNR = "K3"; DELETE KUNDE4 WHERE KNR = "K3";
Verteilungstransparenz (3)B i i l 2 K i TBeispiel 2: Keine Transparenz
SELECT NAME INTO $Name FROM Knoten3@KUNDE3 WHERE KNR = "K3";
SELECT GEBDAT INTO $Geb FROM Knoten4@KUNDE4 WHERE KNR = "K3";
INSERT INTO Knoten1@KUNDE1 (KNR, NAME) VALUES ("K3", $Name)
$INSERT INTO Knoten5@KUNDE1 (KNR, NAME) VALUES ("K3", $Name)
INSERT INTO Knoten2@KUNDE2 (KNR, GEBDAT, FILIALE) VALUES ("K3", $Geb, "L")( , , )
DELETE Knoten3@KUNDE3 WHERE KNR = "K3";
DELETE Knoten4@KUNDE4 WHERE KNR = "K3";
DELETE Knoten6@KUNDE4 WHERE KNR = "K3";
WS0910, © Prof. Dr. E. Rahm 4 - 14
Datenallokation in PDBSä h Sh d N hizunächst: Shared Nothing
Horizontale Verteilung von Relationen über mehrere Rechner– Nutzung von Datenparallelität– Lastbalancierung
T il f b B ti d D t t ilTeilaufgaben zur Bestimmung der Datenverteilung– Festlegung des Verteilgrades einer Relation– Fragmentierung– Fragmentierung – Allokation
Bestimmung des "optimalen" Verteilgrades schwierigBestimmung des optimalen Verteilgrades schwierig– wachsende Rechneranzahl erhöht Kommunikations-Overhead und
reduziert Parallelisierungsgewinn, v.a. für kleinere Relationen– "Full Declustering" oft nicht sinnvoll– einfache Anfragen (kleine Relationen) -> wenige Partitionen
datenintensive Anfragen (große Relationen) > viele Partitionen
WS0910, © Prof. Dr. E. Rahm 4 - 15
– datenintensive Anfragen (große Relationen) -> viele Partitionen
Bestimmung des Verteilgrades einer Relation
R(p) = a + b × p +c × K
Einfaches Antwortzeitmodell (K = Kardinalität der Relation):
AntwortzeitR (p)
R(p) = a + b × p +p
t R(p
)
R (p)
c * K / p
Ant
wor
tzei
t
b * p
A
a
Optimaler Parallelitäts-/Verteilgrad pc K×=
Parallelitätsgrad p (Verteilgrad)
WS0910, © Prof. Dr. E. Rahm 4 - 16
Optimaler Parallelitäts /Verteilgrad popt b-------------=
Bestimmung des VerteilgradesB i d V il d D
60
Bestimmung des Verteilgrades D– für jeden Anfragetyp popt bestimmen
Verteilgrad D ergibt sich aus gewichtetem Mittel (=> Kompromisslösung– Verteilgrad D ergibt sich aus gewichtetem Mittel (=> Kompromisslösung für erwartetes Lastprofil)
601800
1500Relationen-Scan 40
50 Relationen-Scan
60
n s
ec)
Speedup1800
1000
Relationen-Scan Index-Scan (1 %)Index-Scan (0.1 %)
20
30
40
twor
tzei
t (
in
Index-Scan (1%)
0
500
1
10 Index-Scan (0.1 %)
16 64
An
t
528 16 32 64
01
16 6452
Verteilgrad (#Prozessoren)
Relationen-Scan:
WS0910, © Prof. Dr. E. Rahm 4 - 17
Index-Scan (1 %):
Index-Scan (0.1 %):
Fragmentierung: Round-Robin
F1 F2 Fm
Satz i -> Fragment (i mod m) + 1
Vorteile– gleichmäßige Fragmentgrößen
g ( )
gleichmäßige Fragmentgrößen – günstige Lastbalancierung bei gleichmäßiger Zugriffsverteilung (z.B.
geringer "Skew" für Relationen-Scans)
Nachteil: Verteilung von Attributwerten unbekannt– sämtliche Anfragen an allen Rechnern zu bearbeiten
WS0910, © Prof. Dr. E. Rahm 4 - 18
– besonders ineffizient für Exact-Match-Anfragen und Einzelsatzzugriffe
Hash-FragmentierungF1 F2 Fm
Satz i -> Fragment h (VAi)
H h F k i h f F i b V il ib ( B
g ( i)
Hash-Funktion h auf Fragmentierungs- bzw. Verteilattribut (z. B. Primärschlüssel) V t ilVorteile: – Einfachheit– Exact-Match-Queries auf Verteilattribut auf 1 Fragment eingrenzbar Q g g
– Equi-Joins über das Verteilattribut werden unterstützt
Nachteile:
WS0910, © Prof. Dr. E. Rahm 4 - 19
– keine Unterstützung für Bereichsanfragen (range queries) – Gefahr ungleichmäßiger Partitionsgrößen (-> Skew)
Bereichsfragmentierung
F1 F2 Fm
a-c d-g w z
Fragmentierung über Wertebereiche auf Verteilattribut (VA)S ifi i d h B i h ädik t
a-c d-g w-z
– Spezifizierung durch Bereichsprädikate – Fragmentierungsansatz verteilter DBS
Vorteile: – Exact-Match- sowie Range-Queries auf VA auf relevante Fragmente eingrenzbar – Unterstützung für Equi-Joins über das Verteilattribut – stabiler als Hash-Fragmentierung gegenüber ungleichmäßiger Werteverteilungstabiler als Hash Fragmentierung gegenüber ungleichmäßiger Werteverteilung
Nachteile:– Gefahr eingeschränkter Parallelisierung
WS0910, © Prof. Dr. E. Rahm 4 - 20
– Bestimmung der Wertebereiche
Bereichsfragmentierung: Beispiel
1 – 4001 – 96001 –einfache
Bereichsfragmentierung
Partition 1 Partition 2 Partition 25
1
4000
4001
8000
96001
100000
Bereichsfragmentierung(m=D=25)
Beispiel: Kontoaufteilung über VA Kontonummer– Exact-Match-Anfragen gehen auf 1 RechnerExact Match Anfragen gehen auf 1 Rechner – Bereichsanfragen auf VA werden auf minimale Rechnerzahl begrenzt – Relationen-Scan gehen auf alle Rechner
Aber: 1 Fragment pro Rechner (m=D) beschränkt auch Parallelisierung / Lastbalancierung für Bereichsanfragen Verbesserung durch größere Anzahl von Fragmenten (m > D) -> verfeinerte Bereichsfragmentierung
WS0910, © Prof. Dr. E. Rahm 4 - 21
Verfeinerte BereichsfragmentierungA höh F hl d l F iAnsatz: erhöhe Fragmentanzahl, so dass relevanten Fragmente im Mittel popt Rechnern zugeordnet werden können
K = Kardinalität der Tabelle– K = Kardinalität der Tabelle– s = mittlere Selektivität der Bereichsanfragen, 0 ≤ s ≤ 1– popt : optimaler Parallelitätsgrad für durchschnittliche Bereichsanfragepopt p g g– Wähle: m = popt / s (Fragmentgröße: K/m = K * s / popt
Beispiel: CARD (KONTO) = 100.000, Verteilattribut KTONR, s=0.05, popt = 10, D=25
1 – 4001 – 96001 –einfache
Bereichsfragmentierung
Partition 1 Partition 2 Partition 25
4000 8000 100000
Bereichsfragmentierung(m=D=25)
1 – 500
87501 88000
501 – 1000
88001 88500
12001 – 12500
99501 100000
verfeinerte Bereichsfragmentierung
(m=200)
WS0910, © Prof. Dr. E. Rahm 4 - 22
87501 – 88000 88001 – 88500 99501 – 100000
Mehrdimensionale BereichsfragmentierungZi l U ü E M h d B i h f fZiel: Unterstützung von Exact-Match- und Bereichsanfragen auf mehreren AttributenB i i l Z i A f tBeispiel: Zwei Anfragetypen
A: SELECT * FROM PERS WHERE NAME = :Z
B: SELECT * FROM PERS WHERE GEHALT BETWEEN [:X :Y]B: SELECT FROM PERS WHERE GEHALT BETWEEN [:X,:Y]
- Hash- und Bereichsfragmentierung können nur 1 Anfragetyp unterstützen (fürandere sind alle Rechner involviert))
- Mehrdimensionale Bereichsfragmentierung erlaubt, beide Anfragetypen aufTeilmenge der Fragmente zu beschränken
< 20K < 50K < 70K < 90 K < 120K ≥ 120K GehaltA-D 1 1 4 4 7 7E-H 1 1 4 4 7 7Name
I-L 2 2 5 5 8 8M-P 2 2 5 5 8 8Q-S 3 3 6 6 9 9
9 Rechner36 Fragmente
WS0910, © Prof. Dr. E. Rahm 4 - 23
QT-Z 3 3 6 6 9 9
Allokation von FragmentenAll k i P i i bild d h R h d dAllokation: Partitionenbildung durch Rechnerzuordnung der Fragmente (SN)
Festlegung des Verteilgrades D– Festlegung des Verteilgrades D– "gleichmäßige" Aufteilung der m Fragmente unter D Rechnern: (statische)
Lastbalancierungg– analoge Partitionierung von Indexstrukturen
B l i d Z iff hä fi k i P i iBalancierung der Zugriffshäufigkeit von Partitionen– Round Robin-Zuordnung der Fragmente
(gierige Heuristik) bei stark unterschiedlichen Fragment– (gierige Heuristik) bei stark unterschiedlichen Fragment-Zugriffshäufigkeiten:
- ordne Fragmente gemäß Zugriffshäufigkeitenl h F f il ähl d ä h F i d hö h- solange noch Fragmente aufzuteilen, wähle das nächste Fragment mit der höchsten
Zugriffsfrequenz aus- ordne es dem bis dahin am geringsten ausgelasteten Knoten (Partition) zu
WS0910, © Prof. Dr. E. Rahm 4 - 24
Allokation: Beispiel
Fragment F1 F2 F3 F4 F5 F6 F7 F8
Zugriffshäufigkeit 100 600 400 150 200 500 400 50
D=4:
Round Robin:
GreedGreedy:
WS0910, © Prof. Dr. E. Rahm 4 - 25
Datenverteilung bei SD und SEli h U hi d b SNwesentliche Unterschiede gegenüber SN
– Festlegung der Datenverteilung bezieht sich nur auf Platten, nicht auf ProzessorenProzessoren
– Datenallokation hat keinen Einfluss auf Kommunikationshäufigkeit– größere Freiheitsgrade für Verarbeitungsparallelität g g g p– Indexallokation kann unabhängig von Tabellenallokation gewählt werden
großes Lastbalancierungspotential (Parallelitätsgrad, Ausführungsort)
R1 R2 R3 R4 R5
WS0910, © Prof. Dr. E. Rahm 4 - 26
Basistabelle Indexdaten
SE/SD-Datenallokation (2)A B i d V il dAnsatz zur Bestimmung des Verteilgrades– breites Declustering zur optimalen Abdeckung von Relationen-Scans
selektivere Anfragen bzw Anfragen im Mehrbenutzerbetrieb können– selektivere Anfragen bzw. Anfragen im Mehrbenutzerbetrieb können dennoch mit geringerer Parallelität bearbeitet werden
Fragmentierung analog SN möglich, z. B. über Hash- oder Bereichspartitionierung– reduzierter Datenraum für Anfragen auf Verteilattribut
- Beispiel: Bereichspartitionierung von Relation R auf Attribut A (DR=20)
( )A: (1 - 10.000; 10.001 - 20.000; 20.001 - 30.000; ... 190.001 - 200.000)
- Anfrage Select MAX (B) FROM R WHERE A > 70 000 AND A <= 110 000WHERE A > 70.000 AND A <= 110.000
- Parallele Ausführung mit 4 (2, 1) Teilanfragen ohne Plattenengpässe
WS0910, © Prof. Dr. E. Rahm 4 - 27
Index-Partitionierung in PDBS
Index logically partitioned(p root elements)( )
logically centralized (global) index
by
other attributesindex attribute table partitioningattribute(s)
WS0910, © Prof. Dr. E. Rahm 4 - 28
Partitionierung in Oracle (SE, SD)
• Range - partition by predefined ranges of continuous values
• Hash - partition according to hashing algorithm applied by Oracle
• Composite - e.g. range-partition by key1, hash sub-partition by key2p g g p y y , p y y
• List - partition by lists of predefined discrete values
(R+H) Composite
Range Hash
WS0910, © Prof. Dr. E. Rahm 4 - 29
List (Oracle9i)
(R+H) Composite(R+L) Composite
Beispiel: Oracle Range-Partitionierung
CREATE TABLE Telefonat (Datum DATE, KdNr NUMBER, Dauer NUMBER)( )PARTITION BY RANGE(Datum)
(PARTITION vor_2006 VALUESLESS THAN TO_DATE('01-JAN-2006', 'DD-MON-YYYY'),PARTITION in 2006 VALUESPARTITION in_2006 VALUESLESS THAN TO_DATE('01-JAN-2007', 'DD-MON-YYYY'),PARTITION nach_2006 VALUES LESS THAN MAXVALUE) ;
TABLE Telefonat
2005-05-15
Datum
451
DauerKdNr
PARTITION "vor_2006"
2006 10 16
2006-01-16
2005-07-21
203
2001
2152
PARTITION "in_2006"
5022007-03-07
2006-10-16 203
PARTITION "nach_2006"
WS0910, © Prof. Dr. E. Rahm 4 - 30
Beispiel: Oracle Range-Partitionierung
CREATE TABLE events (event_id NUMBER(10), event_data BLOB)
CREATE TABLE events (event_id NUMBER(10), event_data BLOB)
Partitionen können unterschiedlichenTable Spaces zugeordnet werdenPartitionen können unterschiedlichen
Table Spaces zugeordnet werden_
PARTITION BY RANGE(event_id) (
PARTITION evts_0_100k VALUES LESS THAN (100000)
_
PARTITION BY RANGE(event_id) (
PARTITION evts_0_100k VALUES LESS THAN (100000)
Table Spaces zugeordnet werden(Parallele I/O; unabhängiges Backup; etc.)
Table Spaces zugeordnet werden(Parallele I/O; unabhängiges Backup; etc.)
( )TABLESPACE tsa,
PARTITION evts_100k_200k VALUES LESS THAN (200000)
( )TABLESPACE tsa,
PARTITION evts_100k_200k VALUES LESS THAN (200000)
EVTS 0 100KTABLESPACE tsb,
PARTITION evts_200k_300k
VALUES LESS THAN (300000)
TABLESPACE tsb,
PARTITION evts_200k_300k
VALUES LESS THAN (300000) EVTS 100K 200K
EVTS_0_100K
( )TABLESPACE tsc
);
( )TABLESPACE tsc
);
EVTS_100K_200K
EVTS 200K 300K
WS0910, © Prof. Dr. E. Rahm 4 - 31
EV S_ 00K_300K
DB2 für LUW: Datenallokation (SN)3 –stufige Vorgehensweise– DISTRIBUTE BY HASH - Tabellen-Partitionierung zwischen Knoten
PARTITION BY RANGE partitionsinterne Fragmentierung von Tabellen– PARTITION BY RANGE – partitionsinterne Fragmentierung von Tabellen– ORGANIZE BY DIMENSIONS – Clustering innerhalb von Fragmenten
(mehrdimensionales Clustering, MDC)
Node 1 Node 2 Node 3Node 1 Node 2 Node 3
Tabelle T1: Verteilung über 3 Partitionen (Hash) Distribute
TS1 TS2 TS1 TS2 TS1 TS2
Jan Feb Jan Feb Jan Feb Partition
North South North South North South North South North South North South
Jan Feb Jan Feb Jan Feb Partition
Organize
WS0910, © Prof. Dr. E. Rahm 4 - 32
East West East West East West East West East West East West
DB2: Definition Range-Partitioned TableKurze und lange Syntax
Spezialwerte MINVALUE, MAXVALUE zur Definition offener p ,Wertebereiche, z.B.
CREATE TABLE t1 … (STARTING (MINVALUE) ENDING (MAXVALUE) …
tbsp3tbsp2tbsp1
t1.p1 t1.p2 t1.p3
1 <= c1 < 34 34 <= c1 < 67 67 <= c1 <= 100
Kurzform LangformKurzformCREATE TABLE t1(c1 INT)
IN tbsp1, tbsp2, tbsp3PARTITION BY RANGE(c1)
LangformCREATE TABLE t1(c1 INT)
PARTITION BY RANGE(c1)(STARTING FROM (1) ENDING(34)IN tbsp1,
WS0910, © Prof. Dr. E. Rahm 4 - 33
(STARTING FROM (1) ENDING( 100) EVERY (33))
ENDING(67) IN tbsp2,ENDING(100) IN tbsp3)
ZusammenfassungD i i i F i All k i d FDatenpartitionierung: Fragmentierung + Allokation der Fragmente Hauptziele der Fragmentierung– Reduzierung des Verarbeitungsumfangs – Reduzierung des Kommunikationsaufwandes / Unterstützung von
Lokalität (v a wichtig in VDBS)Lokalität (v.a. wichtig in VDBS)– Unterstützung von Parallelität (v.a. wichtig für PDBS)
Parallele DBS basieren auf horizontaler Fragmentierunga a e e S bas e e au o o ta e ag e t e u g– hohe Flexibilität durch Bereichsfragmentierung und Varianten – mehrdimensionale Fragmentierung: Eingrenzung des
Verarbeitungsumfangs hinsichtlich mehrerer Attribute
Datenallokation: Zuordnung der Fragmente zu Knoten– Bestimmung von Verteilgrad und Auswahl der Knoten – wesentlich für Lastbalancierung
SE/SD: Datenallokation bezüglich Externspeicher (Platten) mit
WS0910, © Prof. Dr. E. Rahm 4 - 34
SE/SD: Datenallokation bezüglich Externspeicher (Platten) mit erhöhten Freiheitsgraden