datenbankanwendung - wintersemester 2014/15...entwurfstheorie mehrwertige abh angigkeiten...
TRANSCRIPT
DatenbankanwendungWintersemester 2014/15
Prof. Dr.-Ing. Sebastian MichelTU Kaiserslautern
Entwurfstheorie Mehrwertige Abhangigkeiten
Mehrwertige Abhangigkeiten
Bislang:
Funktionale Abhangigkeiten der Form
• Auspragung R
• Seien α ⊆ R und β ⊆ R• α→ β genau dann, wenn ∀r, s ∈ R gilt: r.α = s.α⇒ r.β = s.β
• D.h. die α-Werte bestimmen die β-Werte funktional (=eindeutig)
Nun: Mehrwertige Abhangigkeiten (multivalued dependencies)
Notation: α→→βFalls einem Attributwert α eine Menge von β-Werten zugeordnet werden.
Genaue Defintion folgt (gleich).
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 2 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Mehrwertige Abhangigkeiten: Beispiel
Fahigkeiten
PersNr Sprache ProgSprache
3002 griechisch C
3002 lateinisch Pascal
3002 griechisch Pascal
3002 lateinisch C
3005 deutsch Ada
Mehrwertige Abhangigkeiten dieser Relation:
• {PersNr} →→ {Sprache} und
• {PersNr} →→ {ProgSprache}MVDs fuhren zu Redundanz und Anomalien
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 3 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Mehrwertige Abhangigkeiten
R
A B C
a b c
a bb cc
a b cc
a bb c
• A→→B• A→→C
Bei zwei Tupeln mit gleichen α-Werten kann man die β-Werte vertauschenund die resultierenden Tupel mussen auch in der Relation sein.
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 4 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Mehrwertige Abhangigkeiten: Definition 1
Rα︷ ︸︸ ︷
A1, ..., Ai
β︷ ︸︸ ︷Ai+1, ..., Aj
γ︷ ︸︸ ︷Aj+1, ..., An
t1 a1, ..., ai ai+1, ..., aj aj+1, ..., ant2 a1, ..., ai bi+1, ..., bj bj+1, ..., bnt3 a1, ..., ai ai+1, ..., aj bj+1, ..., bnt4 a1, ..., ai bi+1, ..., bj aj+1, ..., an
α→→β gilt genau dann, wenn fur jede Auspragung von R gilt:
• wenn es zwei Tupel t1 und t2 mit gleichen α-Werten gibt, dann musses auch zwei Tupel t3 und t4 geben mit
• t1.α = t2.α = t3.α = t4.α (alle α-Werte gleich)• t3.β = t1.β,t4.β = t2.β (β-Paare gleich)• t3.γ = t2.γ, t4.γ = t1.γ (γ-Paare vertauscht)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 5 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Veranschaulichung: Spezialfall
Veranschaulichung fur MVD α→→β:
Wenn α, β, γ jeweils nur aus einem Attribut A,B, und C bestehen:
Wenn {b1, ..., bi} und {c1, ..., cj} die B bzw. C-Werte fur einenbestimmen A-Wert a sind, dann muss die Relation auch die folgenden(i ∗ j) Tupel enhalten:
{a} × {b1, ..., bi} × {c1, ..., cj}
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 6 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Mehrwertige Abhangigkeiten: Definition 2• Eine mehrwertige Abhangigkeit (multivalued dependency, MVD)α→→β besagt, dass einem Attribut α in R eine Menge vonβ-Werten zugeordnet werden.
• Wenn die MVD α→→β in R erfullt, dann kann es als Erweiterung zuFDs α, β, c geben mit
|πβ(σα=c(R))| > 1
• Diese Zuordnung ist unabhangig von den restlichen Attributen in R
Mit anderen Worten:
• α bestimmt nicht nur einen einzelnen Wert (ein singleton)
• genau das ist ja bei einer normalen FD α→ β der Fall!
• sondern eine Menge von Werten
• diese Wertemenge ist unabhangig von den anderen Attributen inγ = R− α− β
Naturlich: Jede FD ist auch eine MVD (aber nicht umgekehrt)Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 7 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Beispiel
Fahigkeiten
PersNr Sprache ProgSprache
3002 griechisch C
3002 lateinisch Pascal
3002 griechisch Pascal
3002 lateinisch C
3005 deutsch Ada
πPersNr,Sprache
Sprachen
PersNr Sprache
3002 griechisch
3002 lateinisch
3005 deutsch
πPersNr,ProgSprache
ProgSprachen
PersNr ProgSprache
3002 C
3002 Pascal
3005 Ada
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 8 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Verlustlose Zerlegung bei MVDs: hinreichende +notwendige Bedingung
Die Zerlegung von R in R1 und R2 ist verlustlos genau dann, wenn
• R = R1 ∪R2
• und mindestens eine von zwei MVDs gilt:• R1 ∩R2 →→R1 oder• R1 ∩R2 →→R2
Fur unser Beispiel gilt:
• {PersNr, Sprache, ProgrSprache} = {PersNr, Sprache} ∪ {PersNr,ProgSprache}
• {PersNr} →→ {Sprache}• {PersNr} →→ {ProgSprache}
D.h. es gelten sogar beide MVDs!
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 9 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
MVDs in Paaren
• es gilt zusatzlich: wenn α→→β, dann gilt immer• α→→γ• mit γ = R− α− β
• D.h. MVDs treten immer als Paare auf
• wir konnten MVDs deshalb auch so notieren: α→→β|γ
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 10 / 53
Entwurfstheorie Mehrwertige Abhangigkeiten
Triviale MVDs ...
• .... sind solche, die von jeder Relationenauspragung R von R erfulltwerden.
• α ∪ β ⊆ R• Eine MVD α→→β ist trivial genau dann, wenn
1. β ⊆ α oder2. β = R− α
• Nur die Bedingung 1 galt auch fur normale FDs.
• Beispiel fur Bedingung 2:• R = {PersNr, Sprache}• α = {PersNr}• β = {Sprache}• R− α = {PersNr, Sprache} − {PersNr} = {Sprache} = β ⇒
MVD ist trivial!
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 11 / 53
Entwurfstheorie Vierte Normalform
Vierte Normalform
Eine Relation R ist in 4NF, wenn fur jede MVD α→→β eine derfolgenden Bedingungen gilt:
• Die MVD ist trivial oder
• α ist Superschlussel von R
• D.h. 4NF ist sehr ahnlich zu BCNF!
• Unterschied:• MVDs statt FDs• Definition von “trivial” wurde erweitert.
• 4NF erfullt ⇒ BCNF erfullt, da jede FD eine MVD ist.
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 12 / 53
Entwurfstheorie Vierte Normalform
Dekomposition in 4NF
Starte mit der Menge Z := {R}
Solange es noch ein Relationenschema Ri in Z gibt, dass nicht in 4NF ist,mache folgendes:
• Es gibt also eine fur Ri geltende nicht-triviale MVD (α→→β), fur diegilt:
• α ∩ β = ∅• ¬(α→ Ri)
• Finde eine solche MVD
• Zerlege Ri in Ri1 := α ∪ β und Ri2 := Ri − β• Entferne Ri aus Z und fuge Ri1 und Ri2 ein, alsoZ := (Z −Ri) ∪ {Ri1} ∪ {Ri2}
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 13 / 53
Entwurfstheorie Zusammenfassung
Alle Normalformen auf einen Blick• Die Verlustlosigkeit ist fur alle Zerlegungsalgorithmen in alle
Normalformen garantiert.• Die Abhangigkeitserhaltung kann nur bis zur dritten Normalform
garantiert werden.
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 14 / 53
Entwurfstheorie Zusammenfassung
Zusammenfassung Entwurfstheorie
• Ziel: Bewertung der Gute einer Relation; Vermeidung von Anomaliendurch Zerlegung in “bessere” Relationen
• Betrachtung von funktionalen Abhangigkeiten zur Identifikation vonRedundanz
• Korrektheit von Zerlegung definiert als verlustlos undabhangigkeitsbewahrend.
• 1NF, 2NF, 3NF, BCNF und 4NF betrachtet.
• Algorithmen zur Zerlegung/Synthese
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 15 / 53
Anfrageverarbeitung Ubersicht
Ubersicht und Ausblick
• Bislang bekannt, aus VL Informationssysteme: Optimierung anhandvon Regeln auf logischer Ebene
• D.h. gegeben ein Anfrageplan, wie kann dieser optimiert werden(durch “Verschieben” von Operatoren)
Ausblick auf kommende Vorlesungen
• Physische Datenorganisation
• Zugriffskosten
• Implementierung der Operatoren
• Kostenschatzung
• Kostenbasierte Anfrageoptimierung
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 16 / 53
Anfrageverarbeitung Ubersicht
Ubersicht Anfrageverarbeitung
result
plan
query
runtime system
compile time system
• Eingabe: Anfrage als Text (String)
• Kompilierzeitsystem (compile time system)ubersetzt und optimiert die Anfrage
• Zwischenprodukt: Anfrage als Anfrageplan(query plan)
• Laufzeitsystem (runtime system) fuhrt dieAnfrage aus
• Ausgabe: Ergebnisse der Anfrage
Ubersicht, Buch “Working Draft” von Guido Moerkotte (Uni Mannheim):
http://pi3.informatik.uni-mannheim.de/~moer/querycompiler.pdf
Vielen Dank an Thomas Neumann (TU Munchen) fur die Bereitstellung einiger
im Folgenden benutzten Folien zu Anfrageverarbeitung/Anfrageoptimierung.
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 17 / 53
Anfrageverarbeitung Ubersicht
Ubersicht Compile Time System
execution plan
query
code generation
rewrite II
plan generation
rewrite I
factorization
normalization
semantic analysis
parsing1. Parsen: Erzeugung Abstract Syntax Tree
(AST)
2. Schema lookup, Typinferenz
3. Normalisierung, Faktorisierung etc.
4. Auflosen von Sichten, Entschachteln etc.
5. Erzeugung des Ausfuhrungsplans (executionplan)
6. Weitere Optimierung des Plans
7. Erzeugung von ausfuhrbarem Codes
rewrite I, plan generation und rewrite II sind Teile des Anfrageoptimierers
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 18 / 53
Anfrageverarbeitung Ubersicht
Einfaches Beispiel: Eingabe
select name, salaryfrom employee, departmentwhere dep=did
and location=”Munchen”and area=”Research”
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 19 / 53
Anfrageverarbeitung Ubersicht
Beispiel: Parsen der Eingabe
Erstellt einen Abstract Syntax Tree (AST)
SelectFromWhere
Projection From Where
Identifier name
Identifier salary
Identifier employee
Identifier department
BinaryExpression eq
Identifier area
String "Research"
BinaryExpression eq
Identifier location
String "München"
BinaryExpression eq
Identifier dep
Identifier did
BinaryExpression and
BinaryExpression and
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 20 / 53
Anfrageverarbeitung Ubersicht
Beispiel: Semantische Analyse
SFW
Projection From Where
Attrib. e.name
Attrib. e.salary
Rel. e:employee
Rel. d:department
Expression eq
Attrib. e.area
Const "Research"
Expression eq
Attrib. d.location
Const "München"
Expression eq
Attrib. e.dep
Attrib. d.did
Expression and
Expression and
Typen sind hier im Beispiel nicht erwahnt. Ergebnis ist vom Typbag < string, number >
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 21 / 53
Anfrageverarbeitung Ubersicht
Beispiel: Rewrite I
Auflosen von Sichten, Entschachteln, Optimierung
SFW
Projection From Where
Attrib. e.name
Attrib. e.salary
Rel. e:person
Rel. d:department
Expression eq
Attrib. e.area
Const "Research"
Expression eq
Attrib. d.location
Const "München"
Expression eq
Attrib. e.dep
Attrib. d.did
Expression and
Expression eq Attrib. e.kind Const "emp"
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 22 / 53
Anfrageverarbeitung Ubersicht
Beispiel: Plan Generierung
Findet die beste Strategie zur Ausfuhrung. Erstellt einen physischen Plan.
σlocation=′′Munchen′′
1dep=did
departmentperson
σkind=′′emp′′
σarea=′′Research′′
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 23 / 53
Anfrageverarbeitung Ubersicht
z.B. Auswahl Join Implementierung
R S
AR.A=S.B
R S
HashJoinR.A=S.B
R S
MergeJoinR.A=S.B
[SortR.A] [SortS.B]
R
S
IndexJoinR.A=S.B
[HashS.B | TreeS.B]
R
S
NestedLoopR.A=S.B
[Bucket]
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 24 / 53
Anfrageverarbeitung Ubersicht
Beispiel: Code GenerierungProduziert einen ausfuhrbaren Plan
<
@c1 string 0
@c2 string 0
@c3 string 0
@kind string 0
@name string 0
@salary float64
@dep int32
@area string 0
@did int32
@location string 0
@t1 uint32 local
@t2 string 0 local
@t3 bool local
>
[main
load_string "emp" @c1
load_string "M\u00fcnchen" @c2
load_string "Research" @c3
first_notnull_bool
<#1 BlockwiseNestedLoopJoin
memSize 1048576
[combiner
unpack_int32 @dep
eq_int32 @dep @did @t3
return_if_ne_bool @t3
unpack_string @name
unpack_float64 @salary
]
[storer
check_pack 4
pack_int32 @dep
pack_string @name
check_pack 8
pack_float64 @salary
load_uint32 0 @t1
hash_int32 @dep @t1 @t1
return_uint32 @t1
]
[hasher
load_uint32 0 @t1
hash_int32 @did @t1 @t1
return_uint32 @t1
]
<#2 Tablescan
segment 1 0 4
[loader
unpack_string @kind
unpack_string @name
unpack_float64 @salary
unpack_int32 @dep
unpack_string @area
eq_string @kind @c1 @t3
return_if_ne_bool @t3
eq_string @area @c3 @t3
return_if_ne_bool @t3
]
>
<#3 Tablescan
segment 1 0 5
[loader
unpack_int32 @did
unpack_string @location
eq_string @location @c2 @t3
return_if_ne_bool @t3
]
>
> @t3
jf_bool 6 @t3
print_string 0 @name
cast_float64_string @salary @t2
print_string 10 @t2
println
next_notnull_bool #1 @t3
jt_bool -6 @t3
]
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 25 / 53
Anfrageverarbeitung Postgresql Einschub
In dieser Vorlesung wird Postgresql verwendet/betrachtet
• “The world’s most advanced opensource database”
• Einfach zu Installieren
• Gute SQL Unterstutzung
• Transaktionen
• Gute Dokumentation (es gibt auchBucher dazu)
http://www.postgresql.org/
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 26 / 53
Anfrageverarbeitung Postgresql Einschub
Beispieldatenbanken zum “Uben”
Installieren Sie eine aktuelle Version Postgresql. Folgende Daten stellenwir Ihnen als Postgresql-Dump bereit:
1. Die “Universitats Datenbank”
2. Eine bereits generierte Version des TPC-H Benchmark-Datensatzeswww.tpc.org/tpch/
konnen Sie hier herunterladen:
http://wwwlgis.informatik.uni-kl.de/extra/vl/dbaw1415/
Login wird benotigt:
• Benutzername: dbaw1415
• Passwort1:
1Wird/Wurde in der VL bekannt gegebenProf. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 27 / 53
Anfrageverarbeitung Postgresql Einschub
PSQL: Command Line Interface
• Anfragen ausfuhren, Schema anlegen, Daten aus CVS Dateien laden,Skripte ausfuhren, . . . siehe Befehlsubersicht via \?
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 28 / 53
Anfrageverarbeitung Postgresql Einschub
Beispiel: Datenbank erzeugen und Dump einspielen
Datenbank erzeugen
• In GUI oder via command line:
createdb university
Daten einspielen
• Mit GUI
• oder via command line (und psql Kommando):
psql university < uni db.dmp
• Achtung: es gibt auch backup/restore. “Dumps” sind reine SQLStatements und Daten, werden erzeugt mit pg dump databasename
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 29 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3
User Interface: Download unter http://www.pgadmin.org/
Features
• Query Builder
• Sehr anschauliche Darstellung von Ausfuhrungplanen (explain plan)
• Komfortable Administration (Benutzer, Rechteverwaltung, . . .)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 30 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3 (2)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 31 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3: query builder (1)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 32 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3: query builder (2)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 33 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3: query builder (3)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 34 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3: query builder (4)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 35 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3: query builder (5)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 36 / 53
Anfrageverarbeitung Postgresql Einschub
PGAdmin3: query builder (6)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 37 / 53
Anfrageverarbeitung Postgresql Einschub
Postgresql/PGAdmin3: Explain Plan (1)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 38 / 53
Anfrageverarbeitung Postgresql Einschub
Postgresql/PGAdmin3: Explain Plan (2)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 39 / 53
Anfrageverarbeitung Physische Optimierung / Implementierung
Realisierung von Operatoren und Physische Optimierung
Bislang
• Logische Algebraoperatoren
• Beschreiben was berechnet wird (z.B. Join), aber nicht wie(Algorithmus).
Jetzt: Physische Optimierung
• Welche Implementierungen gibt es fur verschiedene Operatoren?
• Im obigen Beispiel (explain plan) haben wir bereits zweiverschiedene Implementierungen eines Joins gesehen.
• Iteratorkonzept (Open, Next, Close, . . .)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 40 / 53
Anfrageverarbeitung Iterator Konzept
Anwendungsprogramm
Iterator
open next close size cost
Iterator
open next ...
Iterator
open next ...
Iterator
open next ...
R1 R2
R3 R4Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 41 / 53
Anfrageverarbeitung Iterator Konzept
Iterator
• Open: Konstruktor, initialisiert, offnet die Eingabe
• Next: Liefert das nachste Ergebnis
• Close: Schließt die Eingabe
• Cost und Size: Geben Informationen uber die geschatzten (!) Kosten
Empfehlenswert: Ubersichtsartikel von G. Graefe: Query EvaluationTechniques for Large Databases, ACM Computing Surveys, 1993, volume25, number 2, pages 73-170.
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 42 / 53
Anfrageverarbeitung Iterator Konzept
Pull-basierte Verarbeitung
• Operatoren werden in Form von Iteratoren implementiert
• Datenfluss hierbei ist “von unten nach oben”
• Konsument-Produzent Verhaltnis
• Der konsumierende Iterator bezieht Tupel von seinen Eingaben, dieebenfalls Iteratoren sind, durch deren next() Schnittstelle
• Im Allgemeinen werden Zwischenergebnisse nicht explizitmaterialisiert.
Anmerkung: Push-basierte Verarbeitung
Es gibt insbesondere bei Systemen zur Datenstromverarbeitung diesogenannte Push-basierte Verarbeitung. Dort registrieren sich“Konsumenten” an Datenquellen oder anderen Operatoren. Falls dieseneue Daten haben, werden die Daten an die Konsumenten weiter gereicht(aktiv).
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 43 / 53
Anfrageverarbeitung Iterator Konzept
Blockierende Operatoren
Idealerweise
• Operatoren blockieren den Datenfluss nicht
• D.h. beim Aufruf von next() werden darunter liegende Operatorenangefragt via next und das Ergebnis direkt weiter geleitet. Nur wenigeTupel werden dabei gelesen.
• Erlaubt Pipelining
• Im Gegensatz dazu: Operatoren, die den Datenfluss “blockieren”,sogenannte Pipeline-Breaker
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 44 / 53
Anfrageverarbeitung Iterator Konzept
Pipelining vs. Pipeline-Breaker
R S
...
...
...
T
...
...
...
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 45 / 53
Anfrageverarbeitung Iterator Konzept
Pipelining vs. Pipeline-Breaker
R S
...
...
...
T
...
...
...
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 46 / 53
Anfrageverarbeitung Iterator Konzept
Pipeline-Breaker
• Sortieren
• Duplikate eliminieren (unique, distinct)
• Aggregation: min, max, avg, . . .
• Joins (je nach Implementierung)
• Union (je nach Implementierung)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 47 / 53
Anfrageverarbeitung Iterator Konzept
Implementierung von Operatoren
• Bei der Erzeugung eines physischen Anfrageplans muss entschiedenwerden wie genau die Anfrage ausgefuhrt werden soll
• Welche Implementierungen gibt es fur die diversen Operatoren?
• Welche Implementierung ist effizienter?
• Und wie kann dies uberhaupt berechnet/vorhergesagt werden?(Kostenmodelle)
• Gibt es Indexstrukturen, die ausgenutzt werden konnen?
• ...
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 48 / 53
Anfrageverarbeitung Festplatten Zugriffe
Aufbau einer (klassischen) Festplatte
Arm-drehpunkt
Zugriffs-
kamm
Draufsichtb.
Arm Kopf Spindel
Zylinder
Sektor Track
Kopf
Arm
Seitenansichta.
Platte
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 49 / 53
Anfrageverarbeitung Festplatten Zugriffe
Was kostet wieviel?
• L1 cache reference 0.5 ns
• L2 cache reference 7 ns
• Main memory reference 100 ns
• Compress 1K bytes with Zippy 10,000 ns
• Send 2K bytes over 1 Gbps network 20,000 ns
• Read 1 MB sequentially from memory 250,000 ns
• Round trip within same datacenter 500,000 ns
• Disk seek 10,000,000 ns
• Read 1 MB sequentially from network 10,000,000 ns
• Read 1 MB sequentially from disk 30,000,000 ns
• Send packet CA → Netherlands → CA 150,000,000 ns
Numbers by Jeff Dean (Google)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 50 / 53
Anfrageverarbeitung Festplatten Zugriffe
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 51 / 53
Anfrageverarbeitung Festplatten Zugriffe
Aufbau Festplatte (Tracks, Sektoren, Zonen)
• Track: Teil eines Zylinders auf einer Platte
• Sektor: Teil eines Tracks. Anzahl Sektoren pro Track ursprunglichgleich fur alle Tracks
• Aber, auf Zylinder/Tracks weiter “außen” passen mehr Sektoren.Daher, aktuelle Hardware, variable Anzahl von Tracks: außere Trackshaben mehr Sektoren als innere Tracks; Zylinder sind in Zonenunterteilt.
Blocke
• Aka. Sektoren, Aka. physical Record. Kleinste Transfereinheit beiBlock-Storage-Devices. Seit wenigen Jahren typischerweise 4KB odersonst (historisch) 512 Byte groß.
• Achtung, es gibt auch Unterschiede zu Blocken bzw. Seiten desDateisystems.
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 52 / 53
Anfrageverarbeitung Festplatten Zugriffe
Beispiel
Die Festplatte SAMSUNG HD103SJ, die in meinem Desktop im Buroeingebaut ist hat laut (Linux tool) hdparm -i (oder hdparm -I fur mehrDetails):
• 1953525168 Sektoren
• a 512 Bytes.
Das macht: 1 TBAusgabe (Auszug) von hdparm -I /dev/sda
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 53 / 53