5. Basisalgorithmen für DB-Operationen Einordnung

5. Basisalgorithmen für DB-Operationen
■
Datenbankparameter
■
Komplexität von Grundalgorithmen
■
Unäre Operationen (Scan, Selektion, Projektion)
■
Binäre Operationen: Mengenoperationen
■
Berechnung von Verbunden
VL Datenbank-Implementierungstechniken – 3–1
Einordnung
MOS
Mengenorientierte Schnittstelle
Datensystem
SOS
Satzorientierte Schnittstelle
Zugriffssystem
ISS
Interne Satzschnittstelle
Speichersystem
SPS
Systempufferschnittstelle
Pufferverwaltung
DS
Dateischnittstelle
Betriebssystem
GS
Geräteschnittstelle
VL Datenbank-Implementierungstechniken – 3–2
Datenbankparameter
■
Komplexitätsbetrachtungen (O(n2))
■
Aufwandsabschätzungen (konkret)
■
Datenbankparameter als Grundlage
■
müssen im Katalog des Datenbanksystems gespeichert
werden
VL Datenbank-Implementierungstechniken – 3–3
Datenbankparameter (II)
■ nr :
Anzahl Tupel in Relation r
■ br :
Anzahl von Blöcken (Seiten), die Tupel aus r
beinhalten
■ sr :
(mittlere) Größe von Tupeln aus r (s für size)
■ fr :
Blockungsfaktor (Tupel aus r pro Block)
fr =
bs
,
sr
mit bs Blockgröße
■
Tupel einer Relation kompakt in Blöcken:
nr
br =
fr
VL Datenbank-Implementierungstechniken – 3–4
Datenbankparameter (III)
■ V (A, r):
Anzahl verschiedener Werte für das Attribut A in
der Relation r (V für values): V (A, r) = |πA (r)|
■ A
Primärschlüssel: V (A, r) = nr
■ SC(A, r):
Selektionskardinalität (selection cardinality);
durchschnittliche Anzahl von Ergebnistupeln bei σ A=x (r)
für x ∈ πA (r)
■
Schlüsselattribut A: SC(A, r) = 1
■
Allgemein:
SC(A, r) =
nr
V (A, r)
Weiterhin: Verzweigungsgrad bei B-Baum-Indexen, Höhe
des Baums, Anzahl von Blätterknoten
VL Datenbank-Implementierungstechniken – 3–5
Komplexität von Grundalgorithmen
Grundannahmen
■
Indexe B+ -Bäume
■
dominierender Kostenfaktor: Blockzugriff
■
Zugriff auf Hintergrundspeicher auch für
Zwischenrelationen
■
Zwischenrelationen zunächst für jede Grundoperation
■
Zwischenrelationen hoffentlich zum großen Teil im Puffer
■
einige Operationen (Mengenoperationen) auf
Adreßmengen (TID-Listen)
VL Datenbank-Implementierungstechniken – 3–6
Hauptspeicheralgorithmen
wichtig für den Durchsatz des Gesamtsystems, da sie sehr
oft eingesetzt werden
■
Tupelvergleich
(Duplikate erkennen, Sortierordnung angeben, . . . )
iterativ durch Vergleich der Einzelattribute, Attribute mit
großer Selektivität zuerst
■
TID-Zugriff
TID innerhalb des Hauptspeichers: übliche
Vorgehensweise bei der Auflösung indirekter Adressen
VL Datenbank-Implementierungstechniken – 3–7
Zugriffe auf Datensätze
■
Relationen: interner Identifikator RelID
■
Indexe: interner Identifikator IndexID
◆ Primärindex, etwa I(Personen(PANr)))
bei A = a wird maximal ein Tupel pro Zugriff
◆ Sekundärindex, etwa I(Ausleihe(PANr)))
Bsp.: PANr = 4711 liefert i.a. mehrere Tupel
Indexzugriffe: Ergebnis TID-Listen
VL Datenbank-Implementierungstechniken – 3–8
Zugriffe auf Datensätze (II)
■
fetch-tupel Direktzugriff auf Tupel mittels TID-Wertes
holt Tupel in Tupel-Puffer
fetch-tupel(RelID, TID) → Tupel-Puffer
■
fetch-TID: TID zu (Primärschlüssel-)Attributwert
bestimmen
fetch-TID(IndexID, Attributwert) → TID
■
weiterhin auf Relationen und Indexen: Scans
VL Datenbank-Implementierungstechniken – 3–9
Beispiel in SQL
select *
from KUNDE
where KName =’Meier’
■
Gleichheitsanfrage über einen Schlüssel
■
put: hier Anzeige des Ergebnisses
aktuellerTID :=
fetch-TID(KUNDE-KName-Index, ‘Meyer’);
aktuellerPuffer:=
fetch-tupel(KUNDE-RelationID, aktuellerTID);
put(aktuellerPuffer);
VL Datenbank-Implementierungstechniken – 3–10
Externe Sortieralgorithmen
sort
Andreas 24
Gunter
Dieter
4
Gunter
42
Andreas 24
merge
42
Andreas 24
Berta
77
Chris
7
Andreas 21
Andreas 24
4
Chris
7
Berta
77
Berta
77
Chris
7
Elle
36
Elle
36
Tamara
99
Dieter
2
Dieter
2
Elle
36
Mario
9
Mario
9
Dieter
2
Gunter
42
Peer
43
Tamara
99
Dieter
11
Mario
9
Dieter
11
Mario
9
Peer
43
Peer
43
Tamara
99
Tamara
99
Andreas 21
Dieter
11
Peer
43
4
Elle
36
Gunter
42
merge
Dieter
Andreas 21
merge
Andreas 21
partition
Dieter
Berta
77
Chris
7
Dieter
2
Dieter
4
Dieter
11
Externes Sortieren durch Mischen; Komplexität O(n log n)
Vertauschoperationen
VL Datenbank-Implementierungstechniken – 3–11
Unäre Operationen
Scan durchläuft Tupel einer Relation
■
Relationen-Scan (full table scan) durchläuft alle Tupel
einer Relation in beliebiger Reihenfolge
Aufwand: br
■
Index-Scan nutzt Index zum Auslesen der Tupel in
Sortierreihenfolge
Aufwand: Anzahl der Tupel plus Höhe des Indexes
Vergleich
■
Relationen-Scan besser durch Ausnutzung der Blockung
■
Index-Scan besser, falls wenige Daten benötigt, aber
schlechter beim Auslesen vieler Tupel
VL Datenbank-Implementierungstechniken – 3–12
Operationen auf Scans
■
Relationen-Scan öffnen
open-rel-scan(RelationenID) → ScanID
liefert ScanID zurück, die bei folgenden Operationen zur
Identifikation genutzt wird
■
Index-Scan initialisieren
open-index-scan(IndexID, Min, Max) → ScanID
liefert ScanID zurück; Min und Max bestimmen Bereich
einer Bereichsanfrage
■
next-TID liefert nächsten TID; Scan-Cursor weitersetzen
■
end-of-scan liefert true, falls kein TID mehr im Scan
abzuarbeiten
■
close-scan schließt Scan
VL Datenbank-Implementierungstechniken – 3–13
Beispiel: Scan
select *
from Personen
where Nachname between ’Heuer’ and
’Jagellowsk’
VL Datenbank-Implementierungstechniken – 3–14
Beispiel: Relationen-Scan
aktuellerScanID := open-rel-scan(Personen-RelationID);
aktuellerTID := next-TID(aktuellerScanID);
while not end-of-scan(aktuellerScanID) do
begin
aktuellerPuffer :=
fetch-tupel(Personen-RelationID,aktuellerTID);
if aktuellerPuffer.Nachname >= ’Heuer’
and aktuellerPuffer.Nachname <= ’Jagellowsk’
then put (aktuellerPuffer);
endif;
aktuellerTID := next-TID(aktuellerScanID);
end;
close (aktuellerScanID);
VL Datenbank-Implementierungstechniken – 3–15
Beispiel: Index-Scan
aktuellerScanID :=
open-index-scan(Personen-Nachname-IndexID,
’Heuer’,’Jagellowsk’);
aktuellerTID := next-TID(aktuellerScanID);
while not end-of-scan(aktuellerScanID) do
begin
aktuellerPuffer :=
fetch-tupel(Personen-RelationID,aktuellerTID);
put(aktuellerPuffer);
aktuellerTID := next-TID(aktuellerScanID);
end;
close (aktuellerScanID);
VL Datenbank-Implementierungstechniken – 3–16
Selektion
■
exakte Suche, Bereichsselektionen, komplex
zusammengesetzte Selektionskriterien
■
zusammengesetztes Prädikat ϕ aus atomaren
Prädikaten (exakte Suche, Bereichsanfrage) mit and, or,
not
Tupelweises Vorgehen
■
Gegeben σϕ (r)
■
Relationen-Scan: für alle t ∈ r auswerten ϕ(t)
■
Aufwand O(nr ), genauer br
VL Datenbank-Implementierungstechniken – 3–17
Selektion: Konjunktive Normalform
■
Zugriffspfade bei komplexen Prädikaten einsetzen ⇒ ϕ
analysieren und geeignet umformen
■
etwa ϕ in konjunktive Normalform KNF überführen;
bestehend aus Konjunkten
■
heuristisch Konjunkt auswählten, das sich besonders gut
durch Indexe auswerten laßt (etwa bei A = c und über A
Index)
■
ausgewähltes Konjunkt auswerten; für
Ergebnis-TID-Liste andere Konjunkte tupelweise
■
oder mehrere geeignete Konjunkte auswerten und die
sich ergebenden TID-Listen schneiden
VL Datenbank-Implementierungstechniken – 3–18
Selektion: Filtermethoden
■
bei Filtermethode alle Bedingungen auf true setzen, die
nicht durch eine Zugriffsmethode unterstützt werden
■
resultierendes Prädikat: ϕ0 .
■ r 0 = σϕ0 (r)
unter Ausnutzung der Indexe auswerten
■ σϕ (r 0 )
auf dem (hoffentlich viel kleineren)
Zwischenergebnis r 0 mittels tupelweisem Vorgehen
auswerten
■
Filtermethoden nur gut, wenn ϕ0 tatsächlich
Datenvolumen reduziert (Vorsicht bei Disjunktionen)
VL Datenbank-Implementierungstechniken – 3–19
Projektion
■
Relationenalgebra: mit Duplikateliminierung
■
SQL: keine Duplikateliminierung, wenn nicht mit distinct
gefordert (modifizierter Scan)
■
mit Duplikateliminerung:
◆ sortierte Ausgabe eines Indexes hilft bei der
Duplikateliminierung
◆ Projektion auf indexierte Attribute ohne Zugriff auf
gespeicherte Tupel
VL Datenbank-Implementierungstechniken – 3–20
Projektion (II)
■
Projektion πX (r):
1. r nach X sortieren
2. t ∈ r werden in das Ergebnis aufnehmen, für die
t(X) 6= previous(t(X)) gilt
■
Zeitaufwand: O(nr log nr )
■
Falls r schon sortiert nach X : O(nr )
■
Schlüssel K ⊆ X : O(nr )
VL Datenbank-Implementierungstechniken – 3–21
Scan-Semantik
■
bei Scan-basierten (positionalen)
Änderungsoperationen: Festlegung einer
Scan-Semantik ; Wirkungsweise nachfolgender
Scan-Operationen
■
Beispiel: Löschen des aktuellen Satzes
■
Zustände: vor dem ersten Satz, auf einem Satz, in Lücke
zwischen zwei Sätzen, hinter dem letzten Satz, in leerer
Menge
■
weiterhin: Übergangsregeln für Zustände
VL Datenbank-Implementierungstechniken – 3–22
Scan-Semantik (II)
Helloween-Problem (System R):
■
SQL-Anweisung:
update employee e
set salary = salary * 1.05
■
satzorientierte Auswertung mittels Index-Scan über
Iemployee (salary) und sofortige Index-Aktualisierung
■
ohne besondere Vorkehrungen: unendliche Anzahl von
Gehaltserhöhungen
VL Datenbank-Implementierungstechniken – 3–23
Binäre Operationen: Mengenoperationen
Binäre Operationen meist auf Basis von tupelweisem
Vergleich der einzelnen Tupelmengen
■
Nested-Loops-Technik oder Schleifeniteration
◆ für jedes Tupel einer äußeren Relation s wird die
innere Relation r komplett durchlaufen
◆ Aufwand: O(ns ∗ nr )
■
Merge-Technik oder Mischmethode
◆ r und s (sortiert) schrittweise in der vorgegebenen
Tupelreihenfolge durchlaufen
◆ Aufwand: O(ns + nr )
◆ Falls Sortierung noch vorzunehmen:
Sort-Merge-Technik
◆ Aufwand nr log nr und/oder ns log ns
VL Datenbank-Implementierungstechniken – 3–24
Mengenoperationen (II)
■
Hash-Methoden
◆ kleinere der beiden Relationen in Hash-Tabelle
◆ Tupel der zweiten Relation finden ihren
Vergleichspartner mittels Hash-Funktion
◆ idealerweise Aufwand O(ns + nr )
VL Datenbank-Implementierungstechniken – 3–25
Klassen binärer Operationen
r
s
A
B
C
VL Datenbank-Implementierungstechniken – 3–26
Klassen binärer Operationen (II)
Ergebnisextensionen
A
B
C
A∪B
A∪C
B∪C
A∪B∪C
Übereinstimmung
auf allen Attributen
Differenz r − s
Übereinstimmung
auf einigen Attributen
Anti-SemiVerbund
Schnitt r ∩ s
Verbund,
SemiVerbund
Differenz s − r
Anti-SemiVerbund
Left Outer Join
symmetrische Dif- Anti-Verbund
ferenz
(r − s) ∪ (s − r)
Right Outer Join
Vereinigung r ∪ s
Full Outer Join
VL Datenbank-Implementierungstechniken – 3–27
Vereinigung mit Duplikateliminierung
Vereinigung durch Einfügen
■
Variante der Nested-Loops-Methoden
■
Kopie einer der beiden Relationen r2 unter dem Namen
r20 anlegen, dann Tupel t1 ∈ r1 in r20 einfügen
(Zeitaufwand abhängig von Organisationsform der
Kopie)
Spezialtechniken für die Vereinigung
■ r
■
und s verketten
Projektion auf alle Attribute der verketteten Relation
Zeitaufwand: O((nr + ns ) × log(nr + ns )) (wie Projektion)
VL Datenbank-Implementierungstechniken – 3–28
Vereinigung (II)
Vereinigung durch Merge-Techniken (merge-union)
1. r und s sortieren, falls nicht bereits sortiert
2. r und s mischen
■ tr ∈ r kleiner als ts ∈ s: tr in das Ergebnis, nächstes
tr ∈ r lesen
■ tr ∈ r größer als ts ∈ s: ts in das Ergebnis, nächstes
ts ∈ s lesen
■ ts = tr : tr in das Ergebnis, nächste tr ∈ r bzw. ts ∈ s
lesen
■
Zeitaufwand: O(nr × log nr + ns × log ns ) mit Sortierung,
O(nr + ns ) ohne Sortierung
VL Datenbank-Implementierungstechniken – 3–29
Berechnung von Verbunden
Varianten
■
Nested-Loops-Verbund
■
Block-Nested-Loops-Verbund
■
Merge-Join
■
Hash-Verbund
■
...
VL Datenbank-Implementierungstechniken – 3–30
Nested-Loops-Verbund
doppelte Schleife iteriert über alle t1 ∈ r und alle t2 ∈ s bei
einer Operation r ./ s
r ./ϕ s:
for each tr ∈ r do
begin
for each ts ∈ s do
begin
if ϕ(tr , ts ) then put(tr · ts ) endif
end
end
VL Datenbank-Implementierungstechniken – 3–31
Nested-Loops-Verbund mit Scan
R1ScanID := open-rel-scan(R1ID);
R1TID := next-TID(R1ScanID);
while not end-of-scan(R1ScanID) do
begin
R1Puffer := fetch-tupel(R1ID,R1TID);
R2ScanID := open-rel-scan(R2ID);
R2TID := next-TID(R2ScanID);
while not end-of-scan(R2ScanID) do
begin
.../* Scan über innere Relation */
end;
close (R2ScanID);
R1TID := next-TID(R1ScanID);
end;
close (R1ScanID);
VL Datenbank-Implementierungstechniken – 3–32
Nested-Loops-Verbund mit Scan II
/* Scan über innere Relation */
R2Puffer := fetch-tupel(R2ID,R2TID);
if R1Puffer.X = R2Puffer.Y
then insert into ERG
(R1.Puffer.A1, ..., R1.Puffer.An, R1.Puffer.X,
R2.Puffer.B1, ..., R1.Puffer.Bm);
endif;
R2TID := next-TID(R2ScanID);
Verbesserung: Nested-Loops-Verbund verbindet alle t 1 ∈ r
mit Ergebnis von σX=t1 (X) (s) (gut bei Index auf X in r2 )
VL Datenbank-Implementierungstechniken – 3–33
Block-Nested-Loops-Verbund
statt über Tupel über Blöcke iterieren
for each Block Br of r do
begin
for each Block Bs of s do
begin
for each Tupel tr ∈ Br do
begin
for each Tupel ts ∈ Bs do
begin
if ϕ(tr , ts ) then put(tr · ts ) endif
end
end
end
end
Aufwand: br ∗ bs
VL Datenbank-Implementierungstechniken – 3–34
Merge-Techniken
X := R ∩ S ; falls nicht bereits sortiert, zuerst Sortierung von
r und s nach X
1. tr (X) < ts (X), nächstes tr ∈ r lesen
2. tr (X) > ts (X), nächstes ts ∈ s lesen
3. tr (X) = ts (X), tr mit ts und allen Nachfolgern von ts , die
auf X mit ts gleich, verbinden
4. beim ersten t0s ∈ s mit t0s (X) 6= ts (X) beginnend mit
ursprünglichem ts mit den Nachfolgern t0r von tr
wiederholen, solange tr (X) = t0r (X) gilt
VL Datenbank-Implementierungstechniken – 3–35
Merge-Techniken: Aufwand
■
alle Tupel haben den selben X -Wert: O(nr × ns )
■ X
■
Schlüssel von R oder S : O(nr log nr + ns log ns )
bei vorsortierten Relationen sogar: O(nr + ns )
VL Datenbank-Implementierungstechniken – 3–36
Merge-Join mit Scan
■
Verbund-Attribute auf beiden Relationen
Schlüsseleigenschaft
■
min(X) und max(X): minimaler bzw. maximaler
gespeicherter Wert für X
VL Datenbank-Implementierungstechniken – 3–37
Merge-Join mit Scan (II)
R1ScanID := open-index-scan(R1XIndexID,
min(X), max(X));
R1TID := next-TID(R1ScanID);
R1Puffer := fetch-tupel(R1ID,R1TID);
R2ScanID := open-index-scan(R2YIndexID,
min(Y), max(Y));
R2TID := next-TID(R2ScanID);
R2Puffer := fetch-tupel(R2ID,R2TID);
while not end-of-scan(R1ScanID)
and not end-of-scan(R2ScanID) do
begin
.../* merge */
end;
close (R1ScanID);
close (R2ScanID);
VL Datenbank-Implementierungstechniken – 3–38
Merge-Join mit Scan (III)
/* merge */
if R1Puffer.X < R2Puffer.Y
then R1TID := next-TID(R1ScanID);
R1Puffer := fetch-tupel(R1ID,R1TID);
else if R1Puffer.X > R2Puffer.y
then R2TID := next-TID(R2ScanID);
R2Puffer := fetch-tupel(R2ID,R2TID);
else insert into ERG
(R1.Puffer.A1, ..., R1.Puffer.An, R1.Puffer.X,
R2.Puffer.B1, ..., R1.Puffer.Bm);
R1TID := next-TID(R1ScanID);
R1Puffer := fetch-tupel(R1ID,R1TID);
R2TID := next-TID(R2ScanID);
R2Puffer := fetch-tupel(R2ID,R2TID);
endif;
endif;
VL Datenbank-Implementierungstechniken – 3–39
Verbund durch Hashing
■
Idee:
◆ Ausnutzung des verfügbaren Hauptspeichers zur
Minimierung der Externspeicherzugriffe
◆ Finden der Verbundpartner durch Hashing
◆ Anfragen der Form r 1r.A=s.B s
VL Datenbank-Implementierungstechniken – 3–40
Classic Hashing
■
Vorbereitung: kleinere Relation wird r
■
Ablauf
1. Tupel von r mittels Scan in Hauptspeicher lesen und
mittels Hashfunktion h(r.A) in Hashtabelle H
einordnen
2. wenn H voll (oder r vollständig gelesen):
Scan über S und mit h(s.B) Verbundpartner suchen
3. falls Scan über r nicht abgeschlossen:
H neu aufbauen und erneuten Scan über S
durchführen
■
Aufwand: O(br + p ∗ bs ) mit p ist Anzahl der Scans über s
VL Datenbank-Implementierungstechniken – 3–41
Partitionierung mittels Hashfunktion
■
Tupel aus r und s über X in gemeinsame Datei mit k
Blöcken (Buckets) „gehasht“
■
Tupel in gleichen Buckets durch Verbundalgorithmus
verbinden
VL Datenbank-Implementierungstechniken – 3–42
Partitionierung mittels Hashfunktion (II)
h
0
s
join
0
...
h
1
join
1
join
2
...
r
max
...
...
2
join
max
VL Datenbank-Implementierungstechniken – 3–43
Partitionierung mittels Hashfunktion (III)
for each tr in r do
begin
i := h(tr (X));
Hir := Hir ∪ tr (X);
end;
for each ts in s do
begin
i := h(ts (X));
His := His ∪ ts (X);
end;
for each k in 0 . . . max do
Hkr ./ Hks ;
VL Datenbank-Implementierungstechniken – 3–44
Vergleich der Techniken
s
r
s
r
Nested-Loops-Join
s
r
Merge-Join
Hash-Join
VL Datenbank-Implementierungstechniken – 3–45
Aggregation & Gruppierung
■
Anfragen:
select A, count(*)
from T
group by A
■
Algebraoperator: γcount(*),A (r(t))
■
Implementierungsvarianten:
◆ Nested Loops
◆ Sortierung
◆ Hashing
VL Datenbank-Implementierungstechniken – 3–46
Basisalgorithmen für spezielle DBS
■
Verteilte DBS
◆ Datenverteilung
◆ Verbundoperationen für verteilte DBS
■
Parallele DBS
◆ Partitionierung
◆ Paralleles Sortieren
◆ Parallele Verbundoperationen
VL Datenbank-Implementierungstechniken – 3–47
VDBS: Fragmentierung & Allokation
■
Verteilung von Daten in verteilten DBS
◆ logische Ebene (prädikative Beschreibung) ;
Fragmentierung
◆ physische Ebene (Festlegung des Speicherortes;
redundant/nicht redundant) ; Allokation
VL Datenbank-Implementierungstechniken – 3–48
Fragmentierung
■
horizontal
◆ durch Selektionsprädikat: ri = σP (rg )
[
ri
◆ Gesamtrelation: rg =
i=1...n
■
vertikal
◆ durch Projektion und Einbeziehung des
Primärschlüssels in alle Partitionen:
ri = πK,Aj ...Aj+m (rg )
◆ Gesamtrelation: rg = r1 1 r2 1 · · · 1 rn
■
abgeleitet horizontal
◆ Zerlegungsinformation wird aus anderer Relation
abgeleitet
VL Datenbank-Implementierungstechniken – 3–49
Verbundoperationen
■
einfache Strategie: Verbundberechnung an einem
Knoten
ship whole: Transfer der kompletten Relation
◆ fetch as needed: satzweises Anfordern der
Verbundpartner
◆
■
Bewertung:
◆ „fetch as needed“ mit hoher Nachrichtenanzahl
◆ „ship whole“ mit höherem Datenvolumen
VL Datenbank-Implementierungstechniken – 3–50
Semi-Join
■
Idee: Anfordern der Verbundpartner in einem Schritt
■
Basis: r 1 s = r 1 (s n r) = r 1 (s 1 πA (r)) (A ist
Verbundattribut)
■
Ablauf:
1. Knoten Kr : Bestimmung von πA (r) und Übertragung
an Knoten Ks
2. Knoten Ks : Bestimmung von s0 = s 1 πA (r) = s n r
und Übertragen an Kr
3. Knoten Kr : Bestimmung von r 1 s0 = r 1 s
VL Datenbank-Implementierungstechniken – 3–51
Bitvektor-Join
■
auch Hashfilter-Join
■
Idee: Vermeidung des Übertragens der kompletten
Verbundattributwerte durch Abbildung auf Bitvektor
B[1 . . . n]
■
Abbildung:
Hashfunktion h zur Abbildung der Attributwerte auf
Wertebereich 1 . . . n
◆ Setzen des zugeordneten Bits im Vektor für
Attributwert
◆
VL Datenbank-Implementierungstechniken – 3–52
Bitvektor-Join (II)
■
Ablauf:
1. Knoten Kr : für jeden Wert v von πA (r) setze
zugehöriges Bit B[h(v)] und Übertragung des
Bitvektors B an Ks
2. Knoten Ks : Bestimmung von
r0 = {t ∈ s | B[h(t.A)] ist gesetzt } und Übertragung
an Kr
3. Knoten Kr : Bestimmung von r 1 s0 = r 1 s
VL Datenbank-Implementierungstechniken – 3–53
Bitvektor-Join (III)
■
Bewertung:
◆
◆
Einsparung von Übertragungsvolumen
Hash-Abbildung nicht injektiv → nur potentielle
Verbundpartner im Bitvektor
; ausreichend großes n und geeignete Hashfunktion
h notwendig
VL Datenbank-Implementierungstechniken – 3–54
Parallele DBS
■
Parallelisierung von Anfragen
◆ Unabhängige Parallelität
– parallele Ausführung mehrerer (verschiedener)
Operationen, z.B. verschiedene Teile eines
Mehrwegeverbundes
◆ Pipelining-Parallelität
– Pipelining von Operatoren eines Plans
◆ Intra-Operator-Parallelität
– Parallelisierung einzelner Operationen (parallele
Selektion, paralleler Join)
VL Datenbank-Implementierungstechniken – 3–55
Unabhängige Parallelität
Daten
Operation 1
P1
Daten
Operation 2
P2
Ergebnis
Ergebnisberechnung
.....
Daten
Operation n
Pn
VL Datenbank-Implementierungstechniken – 3–56
Pipelining-Parallelität
P1
Daten
P2
Operation 1
Operation 2
..
Pn
Operation n
Ergebnis
Datenströme
VL Datenbank-Implementierungstechniken – 3–57
Intra-Operator-Parallelität
Operation
P1
Daten
Splitter
Operation
P2
Mischer
Ergebnis
.....
Operation
Pn
VL Datenbank-Implementierungstechniken – 3–58
Datenpartitionierung
■
Ziel: Nutzung mehrerer Prozessoren/Disks durch
Partitionierung der zu verarbeitenden Relation r in
Fragmente r1 , . . . , rn
◆ Zerlegung einer Anfrage in parallel auszuführende
Teilanfragen/-operationen
◆ Beschleunigung der Anfrageverarbeitung, da |r i | ≤ |r|
■
Anforderungen
◆ alle Fragmente ungefähr gleich groß
◆ Fragmente unterstützen die auszuführenden
Operationen
■
Zuordnung zu Prozessoren P1 , . . . , Pn : vorab oder
dynamisch
VL Datenbank-Implementierungstechniken – 3–59
Partitionierungsstrategien
■
Round Robin-Fragmentierung
Zerlegung in M Fragmente
Satz der Relation wird Fragment (i mod M ) + 1
zugordnet
◆ günstige Lastbalancierung, falls Tupel mit gleicher
Wahrscheinlichkeit referenziert werden
◆ aber: da keine Berücksichtigung der Attributwerte bei
Verteilung ; für jede Anfrage ist Bearbeitung aller M
Fragmente notwendig
◆
◆ iter
VL Datenbank-Implementierungstechniken – 3–60
Partitionierungsstrategien (II)
■
Bereichsfragmentierung
Definition der Datenverteilung über Attributwerte
disjunkte und vollständige Unterteilung des
Wertebereichs
◆ notwendig: Kenntnis über
Werteverteilung/Wertebereich
◆ Vorteil: bei exact match queries und range queries
(bzgl. Verteilungsattribut) ist Beschränkung auf
relevante Fragmente möglich
◆ Nachteil: u.U. ungünstige Parallelisierung
(Ausnutzung nur weniger Prozessoren)
◆
◆
VL Datenbank-Implementierungstechniken – 3–61
Partitionierungsstrategien (III)
■
Hash-Fragmentierung
Verteilung auf Basis einer Hashfunktion über
Verteilungsattribut
◆ notwendig: geeignete Hashfunktion zur
Gleichverteilung
◆ Vorteil: exact-match queries bzgl. Verteilungsattribut
kann durch Hashfunktion auf relevantes Fragment
beschränkt werden
◆
VL Datenbank-Implementierungstechniken – 3–62
Partitionierungsstrategien (IV)
...
...
range
...
round robin
hash
VL Datenbank-Implementierungstechniken – 3–63
Parallelisierung unärer Operatoren
■
Selektion:
[
[
σP (ri )
ri ⇒ σP (r) =
r=
■
Projektion ohne Duplikateleminierung: dito
■
Duplikateleminierung: durch Sortierung
■
Aggregatfunktionen:
◆ min(r .Attr) = min(min(r1 .Attr), . . . , min(rn .Attr))
◆ max(r .Attr) = min(max(r1 .Attr), . . . , max(rn .Attr))
i
i
VL Datenbank-Implementierungstechniken – 3–64
Parallelisierung unärer Operatoren (II)
■
Aggregatfunktionen (falls keine Duplikateliminierung
nötig):
X
count(ri .Attr)
◆ count(r .Attr) =
i
◆
sum(r.Attr) =
X
sum(ri .Attr)
i
◆
avg(r.Attr) = sum(r.Attr) / count(r.Attr)
VL Datenbank-Implementierungstechniken – 3–65
Paralleles Sortierung
■
Klassifikation bzgl. der Anzahl der Ein- und
Ausgabeströme:
◆ 1:1, 1:viele, viele:1, viele:viele
■
Anforderungen für (?:viele):
Teilergebnis an jedem Knoten ist sortiert
◆ sortiertes Gesamtergebnis durch einfaches
Aneinanderfügen der Teilergebnisse
◆
VL Datenbank-Implementierungstechniken – 3–66
Parallel Binary Merge Sort
■
Viele:1-Verfahren
■
Ablauf:
paralleles Sortieren aller Fragmente an allen
beteiligten Knoten (Quicksort, External Merge Sort)
Phase 2: Mischen der sortierten Fragmente durch andere
Knoten (Mischknoten) bis ein einzelnes sortiertes
Gesamtergebnis entstanden ist
Phase 1:
■
Mischen kann parallel und in Pipeline erfolgen
VL Datenbank-Implementierungstechniken – 3–67
Parallel Binary Merge Sort (II)
P1: 3,6
P1: 1,3,4,6
P2: 1,4
P3: 2,3
P2: 1,2,3,3,3,4,6,6
P3: 2,3,3,6
P4: 3,6
P4: 1,1,1,2,2,3,3,3,4,4,5,6,6,7,8,9
P5: 1,5
P6: 1,7
P7: 2,8
P5: 1,1,5,7
P6: 1,1,2,4,5,7,8,9
P7: 2,4,8,9
P8: 4,9
VL Datenbank-Implementierungstechniken – 3–68
Block Bitonic Sort
1. Sort-Split-Ship
(a) Sortierung der Fragmente an jedem beteiligten
Knoten
(b) Aufteilung der sortieren Fragmente in jeweils zwei
Subfragmente gleicher Größe
■ jeder Wert des einen Subfragmentes (unteres
Subfragment) ≤ alle Werte des oberen
Subfragments
(c) jedes Subfragment wird zu anderen Knoten
übertragen
VL Datenbank-Implementierungstechniken – 3–69
Block Bitonic Sort (II)
2. 2-Way-Merge Split
(a) bei Eintreffen von zwei Subfragmenten:
2-Wege-Mischen zur Erzeugung eines sortierten
Fragments
(b) Splitten des Fragments und Weiterleiten
entsprechend 1(b) bis
(1) jeder Knoten Pi besitzt sortiertes Fragment und
(2) jeder Wert an Pi ≤ jeder Wert an Pj für i ≤ j
■
eindeutige Festlegung der Übertragungsziele notwendig
(siehe Beispiel)
■
Anzahl der Schritte:
1
2
log 2n(log 2n + 1) für n Knoten
VL Datenbank-Implementierungstechniken – 3–70
Block Bitonic Sort (III)
P1: 3,4,1,6
P2: 6,3,2,3
P3: 1,7,1,5
P4: 2,8,4,9
P1 L: 1,3
H: 4,6
P1 L: 1,3
H: 3,6
P1 L: 1,2
H: 3,3
P1 L: 1,2
H: 8,9
P1 L: 1,2
H: 2,3
P1 L: 1,1
P2 H: 3,6
L: 2,3
P2 L: 2,3
H: 4,6
P2 L: 3,4
H: 6,6
P2 L: 3,3
H: 5,7
P2 L: 1,1
H: 3,3
P2 L: 2,3
P3 H: 5,7
L: 1,1
P3 H: 5,7
L: 2,4
P3 H: 8,9
L: 5,7
P3 L: 2,3
H: 4,4
P3 L: 4,4
H: 8,9
P3 L: 4,4
P4 L: 2,4
P4 H: 8,9
P4 H: 2,4
P4 L: 1,1
P4 L: 5,6
P4 L: 6,7
H: 8,9
L: 1,1
L: 1,1
H: 6,6
H: 6,7
H: 1,2
H: 3,3
H: 5,6
H: 8,9
VL Datenbank-Implementierungstechniken – 3–71
Parallele Verbundberechnung
■
Dynamische Replikation
◆ Replikation der kleineren Relation r an jeden Knoten
◆ Ausführung des Verbundes durch Join-Prozessor
◆ Gesamtergebnis durch Vereinigung der lokalen
Join-Ergebnisse
■
Dynamische Partitionierung
◆ partitionierte Umverteilung der Tupel an jeweils einen
Knoten
◆ Verteilungsfunktion: Hashfunktion h oder
Bereichsartitionierung
VL Datenbank-Implementierungstechniken – 3–72
Dynamische Replikation
1. Koordinator: Initiiere Join auf allen Knoten Ri und Rj
(i = 1 . . . n, j = 1 . . . m)
2. Scan-Phase: parallel an jedem S -Knoten:
lies lokale Partition sj und sende sie an jeden Knoten Ri
3. Join-Phase: parallel an jedem R-Knoten mit Partition r i :
[
■ s :=
sj
■
■
Berechne ti := r1 s (impliziert Lesen von ri )
Sende ti an Koordinator
4. Koordinator: Empfange und mische alle ti
VL Datenbank-Implementierungstechniken – 3–73
Dynamische Replikation (II)
r1
r2
rn
Join-Knoten
(R-Knoten)
S-Datenknoten
s1
sm
VL Datenbank-Implementierungstechniken – 3–74
Dynamische Partitionierung
1. Koordinator: Initiiere Join auf allen R-, S - und
Join-Knoten
2. Scan-Phase
■ parallel auf jedem R-Knoten:
lies lokale Partition ri und sende jedes Tupel an
zuständigen Join-Knoten
■ parallel auf jedem S -Knoten:
lies lokale Partition si und sende jedes Tupel an
zuständigen Join-Knoten
VL Datenbank-Implementierungstechniken – 3–75
Dynamische Partitionierung (II)
3. Join-Phase: parallel auf jedem Join-Knoten k(k = 1 . . . p)
[
■ rk0 :=
rik (Menge der von Join-Knoten k
empfangenen r-Tupel)
[
■ s0k :=
sik (Menge der von Join-Knoten k
empfangenen s-Tupel)
■ berechne tk := rk0 1 s0k
■ Sende tk an Koordinator
4. Koordinator: Empfange und mische alle tk
VL Datenbank-Implementierungstechniken – 3–76
Dynamische Partitionierung (III)
Join-Knoten
r1
r2
rn
R-Datenknoten
s1
sm
S-Datenknoten
VL Datenbank-Implementierungstechniken – 3–77
Simple Hash Join
■
Erweiterung des Hash-Verbundes
■
Ablauf:
1. Partitionierung der kleineren Relation r unter
Verwendung einer Hashfunktion h1 (A) → Senden des
iten Fragments an Prozessor Pi
2. an jedem Prozessor Pi :
erzeuge Hashtabelle Hi unter Verwendung von h2 (A)
→ Tupel mit gleichen Werten von A in gleiche Buckets
3. Partitioniere s unter Anwendung von h1 und sende
ites Fragment von s an Pi
4. an jedem Prozessor Pi :
Tupel von si lesen und unter Anwendung von h2 (s.A)
auf Verbundpartner aus ri prüfen
VL Datenbank-Implementierungstechniken – 3–78
Simple Hash Join: Überlaufbehandlung
■
Bereich der Hashwerte vorab auswählen und nur
betroffene Tupel in Hashtabelle einfügen
■
verbleibende Tupel in temporärer Relation sichern (für r
und s)
■
anschließend: rekursive Behandlung der temporären
Relationen
■
Verbundkandidaten können nur in temporären
Relationen sein!
VL Datenbank-Implementierungstechniken – 3–79
GRACE Hash Join
■
Ziel: Vermeidung von Überläufen
■
Idee: Vorab-Partitionierung der Relation und Ausführung
des Simple Hash Joins
■
Ablauf:
1. Partitionierungsphase
◆ r und s in N Fragmente partitionieren und auf Disk
sichern
◆ N so wählen, dass jedes Fragment in
Hauptspeicher passt
◆ Verbundpartner von ri nur in si !
2. Fragment-Join-Phase
◆ Verbund ri 1 si für 1 ≤ i ≤ N parallel berechnen
VL Datenbank-Implementierungstechniken – 3–80
Hybrid Hash Join
■
Verbesserung des GRACE Hash Joins
■
Ausnutzung des Hauptspeichers während der
Partitionierungsphase
◆ Allokation der Hashtabelle für s1 während des Lesens
und Partitionierens von s
■
kombiniert Vorteile von Simple Hash Join und GRACE
Hash Join
Fall 1: großer Hauptspeicher ; N = 1
identisch zu Simple Hash Join
Fall 2: kleiner Hauptspeicher ; großes N
Vorteil gegenüber GRACE Hash Join durch initiale
Hashtabelle
VL Datenbank-Implementierungstechniken – 3–81