Datenbank- Implementierung

Transkript

1 DB2 Crash 0 1 Crash-Kurs Datenbank- Implementierung Uni Magdeburg Gunter Saake saake@iti.cs.uni-magdeburg.de

2 DB2 Crash 0 1 Überblick 1. Architektur von Datenbanksystemen 2. Basisalgorithmen für Datenbankoperationen 3. Optimierung von Anfragen

3 DB2 Crash Architektur Schichtenmodell eines relationalen DBMS

4 DB2 Crash 1 2 Betrachtete Fragestellungen Externe Ebene Konzeptuelle Ebene Interne Ebene Anfragen Updates Optimierer Auswertung Plattenzugriff P1... DB-Operationen Einbettung Data Dictionary Pn Masken Sichtdefinition Dateiorganisation Datendefinition

5 DB2 Crash 1 3 Fünf-Schichten-Architektur basierend auf Idee von Senko 1973 Weiterentwicklung von Härder 1987 Umsetzung im Rahmen des IBM-Prototyps System R genauere Beschreibung der Transformationskomponenten schrittweise Transformation von Anfragen/Änderungen bis hin zu Zugriffen auf Speichermedien Definition der Schnittstellen zwischen Komponenten

6 DB2 Crash Schichten-Architektur: Schnittstellen I mengenorientierte Schnittstelle deklarative DML auf Tabellen, Sichten, Zeilen satzorientierte Schnittstelle Sätze, logische Dateien, logische Zugriffspfade navigierender Zugriff interne Satzschnittstelle Sätze, Zugriffspfade Manipulation von Sätzen und Zugriffspfaden

7 DB2 Crash Schichten-Architektur: Schnittstellen II Pufferschnittstelle Seiten, Seitenadressen Freigeben und Bereitstellen Datei- oder Seitenschnittstelle Hole Seite, Schreibe Seite Geräteschnittstelle Spuren, Zylinder Armbewegungen

8 DB2 Crash Schichten-Architektur: Funktionen Mengenorientierte Schnittstelle (MOS) Satzorientierte Schnittstelle (SOS) Interne Satz schnittstelle (ISS) Datensystem Zugriffssystem Speichersystem Systempuffer schnittstelle (SPS) Pufferverwaltung Datei schnittstelle (DS) Betriebssystem Übersetzung, Zugriffspfadauswahl, Zugriffskontrolle, Integritätskontrolle Data Dictionary, Currency Pointer, Sortierung, Transaktionsverwaltung Record Manager, Zugriffspfadverwaltung, Sperrverwaltung, Log/Recovery Systempufferverwaltung mit Seitenwechselstrategie Externspeicherverwaltung Geräte schnittstelle (GS)

9 DB2 Crash Schichten-Architektur: Objekte Mengenorientierte Schnittstelle (MOS) Satzorientierte Schnittstelle (SOS) Interne Satz schnittstelle (ISS) Speichersystem Systempuffer schnittstelle (SPS) Pufferverwaltung Datei schnittstelle (DS) Geräte schnittstelle (GS) Datensystem Zugriffssystem Betriebssystem Relationen Sichten externe Sätze, Scans, Index Strukturen interne Sätze, Bäume, Hashtabellen Segmente Seiten Dateien Blöcke Zylinder Spuren SQL : select... from... QBE, QUEL,... FIND NEXT satz STORE satz Speichere internen Satz s INSERT in B Baum Bereitstellen Seite j Freigeben Seite j Lies Block k Schreibe Block k Treiber

10 DB2 Crash 1 8 Erläuterungen (I) mengenorientierte Schnittstelle MOS: deklarative Datenmanipulationssprache auf Tabellen und Sichten (etwa SQL) durch Datensystem auf satzorientierte Schnittstelle SOS umgesetzt: navigierender Zugriff auf interner Darstellung der Relationen manipulierte Objekte: typisierte Datensätze und interne Relationen sowie logische Zugriffspfade (Indexe) Aufgaben des Datensystems: Übersetzung und Optimierung von SQL-Anfragen

11 DB2 Crash 1 9 Erläuterungen (II) durch Zugriffssystem auf interne Satzschnittstelle ISS umgesetzt: interne Tupel einheitlich verwalten, ohne Typisierung Speicherstrukturen der Zugriffspfade (konkrete Operationen auf B -Bäumen und Hash-Tabellen), Mehrbenutzerbetrieb mit Transaktionen

12 DB2 Crash 1 10 Erläuterungen III durch Speichersystem Datenstrukturen und Operationen der ISS auf interne Seiten eines virtuellen linearen Adressraums umsetzen Manipulation des Adressraums durch Operationen der Systempufferschnittstelle SPS Typische Objekte: interne Seiten, Seitenadressen Typische Operationen: Freigeben und Bereitstellen von Seiten, Seitenwechselstrategien, Sperrverwaltung, Schreiben des Log-Buchs durch Pufferverwaltung interne Seiten auf Blöcke der Dateischnittstelle DS abbilden Umsetzung der DS-Operationen auf Geräteschnittstelle erfolgt durch BS

13 DB2 Crash Basisalgorithmen Datenbankparameter Komplexität von Grundalgorithmen Unäre Operationen (Scan, Selektion, Projektion) Binäre Operationen: Mengenoperationen Berechnung von Verbunden

14 DB2 Crash 2 2 Datenbankparameter Komplexitätsbetrachtungen (maximal O(n 2 ) als Forderung) Aufwandsabschätzungen (konkret) Datenbankparameter als Grundlage müssen im Katalog des Datenbanksystems gespeichert werden

15 DB2 Crash 2 3 Datenbankparameter (II) n r : Anzahl Tupel in Relation r b r : Anzahl von Blöcken (Seiten), die Tupel aus r beinhalten s r : (mittlere) Größe von Tupeln aus r (s für size) f r : Blockungsfaktor (Tupel aus r pro Block) mit bs Blockgröße f r = bs s r, Tupel einer Relation kompakt in Blöcken: nr b r = f r

16 DB2 Crash 2 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) = n r 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) = n r V (A, r) Weiterhin: Verzweigungsgrad bei B-Baum-Indexen, Höhe des Baums, Anzahl von Blätterknoten

17 DB2 Crash 2 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)

18 DB2 Crash 2 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

19 DB2 Crash 2 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

20 DB2 Crash 2 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

21 DB2 Crash 2 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);

22 DB2 Crash 2 10 Vergleich der Techniken für Joins s s s r r r Nested-Loops-Join Merge-Join Hash-Join

23 DB2 Crash 2 11 Aggregation & Gruppierung Anfragen: select A, count(*) from T group by A Algebraoperator: γ count(*),a (r(t)) Implementierungsvarianten: Nested Loops Sortierung Hashing

24 DB2 Crash Optimierung Grundprinzipien, motivierende Beispiele Phasen der Anfrageverarbeitung Übersetzung von SQL in Relationenalgebra Logische Optimierung (algebraisch, Tableau) Interne Optimierung Kostenbasierte Auswahl

25 DB2 Crash 3 2 Grundprinzipien Basissprachen SQL Relationenkalküle hier: Relationenalgebra Ziel der Optimierung möglichst schnelle Anfragebearbeitung möglichst wenig Seitenzugriffe bei der Anfragebearbeitung möglichst in allen Operationen so wenig wie möglich Seiten (Tupel) berücksichtigen

26 DB2 Crash 3 3 Teilziele einer Optimierung 1. Selektionen so früh wie möglich 2. Basisoperationen zusammengefassen und ohne Zwischenspeicherung realisieren 3. Redundante Operationen, Idempotenzen oder leere Zwischenrelationen entfernen 4. Zusammenfassen gleicher Teilausdrücke: Wiederverwendung von Zwischenergebnissen

27 DB2 Crash 3 4 Beispiel KUNDE { KName, Kadr, Kto } AUFTRAG { KName, Ware, Menge } select KUNDE.KName, Kto from KUNDE, AUFTRAG where KUNDE.KName = AUFTRAG.KName and Ware = Kaffee Relation KUNDE: 100 Tupel; eine Seite: 5 Tupel Relation AUFTRAG: Tupel; eine Seite: 10 Tupel 50 der Aufträge betreffen Kaffee Tupel der Form (KName, Kto): 50 auf eine Seite 3 Zeilen von KUNDE AUFTRAG auf eine Seite Puffer für jede Relation Größe 1, keine Spannsätze

28 DB2 Crash 3 5 Direkte Auswertung 1. R 1 := KUNDE AUFTRAG Seitenzugriffe: l : (100/ /10) = s : ( )/3 = (ca.) 2. R 2 := σ SEL (R 1 ) l : (ca.) s : 50/3 = 17 (ca.) 3. ERG := π PROJ (R 2 ) l : 17 s : 1 Insgesamt ca Seitenzugriffe und ca Seiten zur Zwischenspeicherung

29 DB2 Crash 3 6 Optimierte Auswertung 1. R 1 := σ Ware= Kaffee (AUFTRAG) l : /10 = s : 50/10 = 5 2. R 2 := KUNDE KName=KName R 1 l : 100/5 5 = 100 s : 50/3 = ERG := π PROJ (R 2 ) l : 17 s : 1 ca Seitenzugriffe (Faktor 500 verbessert)

30 DB2 Crash 3 7 Auswertung mit Indexausnutzung Indexe I(AUFTRAG(Ware)) und I(KUNDE(KName)) 1. R 1 := σ Ware= Kaffee (AUFTRAG) über I(AUFTRAG(Ware)) l : minimal 5, maximal 50; s : 50/10 = 5 2. R 2 := sortiere R 1 nach KName l + s : 5 log 5 = 15 (ca.) 3. R 3 := KUNDE KName=KName R 2 l : 100/5 + 5 = 25; s : 50/3 = ERG := π PROJ (R 3 ) l : 17; s : 1 maximal ca. 130 und minimal ca. 85 Seitenzugriffe

31 DB2 Crash 3 8 Gegenüberstellung der Varianten Variante der Ausführung Aus- direkte wertung optimierte Auswertung Seiten für Zwischenergebnisse Lese- und Schreibzugriffe ca ca ca Auswertung min mit Index max mit Pipelining 85 bis (plus sortieren)

32 DB2 Crash 3 9 Phasen der Anfrageverarbeitung 1. Übersetzung und Sichtexpansion in Anfrageplan arithmetische Ausdrücke vereinfachen Unteranfragen auflösen Einsetzen der Sichtdefinition 2. Logische oder auch algebraische Optimierung Anfrageplan unabhängig von der konkreten Speicherungsform umformen; etwa Hineinziehen von Selektionen in andere Operationen

33 DB2 Crash 3 10 Phasen der Anfrageverarbeitung II 3. Interne Optimierung konkrete Speicherungstechniken (Indexe, Cluster) berücksichtigen Algorithmen auswählen mehrere alternative interne Pläne 4. Kostenbasierte Auswahl Statistikinformationen (Größe von Tabellen, Selektivität von Attributen) für die Auswahl eines konkreten internen Planes nutzen 5. Code-Erzeugung Umwandlung des Zugriffsplans in ausführbaren Code

34 DB2 Crash 3 11 Ablauf und Sprachen SQL Übersetzung Sichtauflösung Optimierung Code-Erzeugung Ausführung Algebra Algebra Zugriffsplan Code logische Optimierung physische Optimierung kostenbasierte Auswahl

35 DB2 Crash 3 12 Phasen der Optimierung Optimierung Algebraterm logische Optimierung physische Optimierung Algebraterm mehrere Zugriffspläne kostenbasierte Auswahl Zugriffsplan

36 DB2 Crash 3 13 Logische Optimierung heuristische Methoden etwa algebraische Optimierung für Relationenalgebra + Gruppierung,...

37 DB2 Crash 3 14 Algebraische Optimierung Termersetzung von Termen der Relationenalgebra anhand von Algebraäquivalenzen Äquivalenzen gerichtet als Ersetzungsregeln heuristische Methode: Operationen verschieben, um kleinere Zwischenergebnisse zu erhalten; Redundanzen erkennen

38 EntlAdr DB2 Crash 3 15 Unoptimierter Anfrageplan Titel Datum Autor Heuer ProjList Bücher Ausleihe Entleiher ProjList=Titel Autor Verlag ISBN EntlName

39 DB2 Crash 3 16 Anfrageplan (II) nach Verschieben der Selektionen Titel Autor Heuer Datum ENTLEIHER BÜCHER AUSLEIHE

40 $ "# DB2 Crash 3 17 '& % # %! Anfrageplan (III) mit zusätzlichen Projektionen

41 DB2 Crash 3 18 Interne Optimierung erster Schritt: Relationenalgebraoperationen in interne Operationen umsetzen weitere Operationen Tupelmengen zum Teil durch sortierte Tupellisten ersetzen statt Mengen Multimengen neben Tupeln auch TID-Listen verarbeiten Zugriffe auf Indexe

42 DB2 Crash 3 19 Auswahl von Berechnungsalgorithmen Projektion: π REL/mit AttList :REL Projektion durch Relationen-Scan (mit bezeichnet eine Projektion mit Duplikateliminierung) π REL/ohne AttList : Projektion durch Relationen-Scan ohne Duplikateliminierung π SORT/mit AttList :SORT Projektion durch Scan über einer nach AttList sortierten Relation mit Duplikateliminierung π SORT/ohne AttList : Projektion durch Scan über einer nach AttList sortierten Relation ohne Duplikateliminierung

43 DB2 Crash 3 20 Auswahl von Berechnungsalgorithmen II Selektion: RELσ REL ϕ : Selektion durch Relationen-Scan Selektion über Index (später detailliert) Verbund: DIRECT : Verbund durch Nested-Loops DIRECT MERGE : Verbund durch Mischen MERGE (Voraussetzung: Eingaberelationen nach Verbundattribut(en) sortiert). HASH : Verbund durch Hash-Join HASH Operatoren für Vereinigung, Differenz und Durchschnitt analog zum Verbund; Vereinigung mit oder ohne Duplikateliminierung

44 DB2 Crash 3 21 Indexzugriff Zugriff über Index liefert TID-Liste Spezialfall σ IND nach A Varianten: σ IND AΘa(I(R(A))) list(tid) true (I(R(A))): alle Indexeinträge sortiert duplikatfreier Primärindex: Ergebnis bei A = a ein einzelnes Tupel Tupel direkt im Index: Ergebnis des Indexzugriffs ist sortierte Liste von Tupeln Bereichsanfrage: Prädikat a 1 A a 2

45 DB2 Crash 3 22 Indexzugriff II Index kann auch Projektion unterstützen Ergebnis von σ IND Operator nehmen true kombinierter Zugriff: π IND/mit AttList (I(R(A))) als Eingabe für πsort/- bzw. π IND/ohne AttList in π IND/- A (I(R(A))) kann auf Zugriff auf Basisrelation ganz verzichtet werden

46 DB2 Crash 3 23 Neue Operatoren Für TID-Listen: Realisierung -Operator ρ: ρ( TID-Liste für R-Tupel, r(r)) Auf TID-Listen, und Sortierung von Tupelmengen: ω Relation sortieren: ω AttList ( Tupel-Folge ) ρ(σ IND true(i(r(attlist))), r(r)) = ω AttList (r(r)) erste Variante Aufwand O( R ), zweite Variante O( R log R )

47 DB2 Crash 3 24 Beispiele für interne Zugriffspläne select * from LIEFERANT where Ware = Tee and ( LName = Tom or LName = Jerry ) and Preis < 10

48 DB2 Crash 3 25 Zwei Zugriffspläne REL Preis LIEF LIEF IND Ware Tee IND LName Tom I(LIEF(LName)) IND LName Jerry I(LIEF(LName)) I(LIEF(Ware))

49 DB2 Crash 3 26 Pipelining von Operationen REL ohne KUNDE.KName Kto KName KName KName IND ohne KName Kto REL ohne KName I(KUNDE(Ware)) IND Ware Tee AUF I(AUF(Ware)) π A (σ ϕ (r(r))) π A σ ϕ (r(r))

50 DB2 Crash 3 27 Pipelining von Operationen II Typische Verschmelzungen: Kombination von Selektion und Projektion Kombination einer Selektion mit Verbund die Integration einer Selektion in die äußere Schleife eines Nested-Loops-Verbund Integration von Selektionen in den Merge-Join Kopplung der Selektion mit der Realisierung select K.KName, Kto from KUNDE K, AUFTRAG A where K.KName = A.KName and A.Ware = Tee

51 DB2 Crash 3 28 Gemeinsame Teilanfragen Aufgabe: Erkennung gemeinsamer Teilanfragen Gleichsetzen der zugehörigen Teilbäume des Operatorbaums Probleme: unterschiedliche syntaktische Form: r 1 r 2 identisch zu r 2 r 1 Überdeckung (σ ϕ überdeckt n σ ϕ ψ )

52 DB2 Crash 3 29 Kostenbasierte Auswahl Berücksichtigung: tatsächliche Größe der Datenbankrelationen Existenz von Indexen (Primär-, Sekundär-) und ihre Größe Clustering mehrerer Relationen Selektivität eines Attributs, über das ein Index aufgebaut wurde

53 DB2 Crash 3 30 Relevante Datenbankparameter Systemparameter aus Katalog: s: Länge einer Seite (nutzbarer Seitenbereich in Byte) Größe der Datenbank: Anzahl S der belegten Seiten (wird benötigt, wenn Tupel von Relationen gestreut gespeichert werden) statistische Daten über Relationen und Indexe: T R : Anzahl der Tupel in Relation R L R : durchschn. Länge eines Tupels in R W A,R : Anzahl der verschiedenen Werte des Attributes A in R (Indexinformation oder Statistik) Statistiken Aktualisierung bei Änderungsoperation oder Aufruf entsprechender Kommandos

54 DB2 Crash 3 31 Selektivität von Attributen Anzahl der verschiedenen Werte des Attributs A in R: W A,R Gleichheit: Ungleichheit: sel(a=c, R) = 1 W A,R sel(not A=c, R) = 1 sel(a=c, R) = 1 1 W A,R Vergleich mittels <, >,...: sel(a<c, R) = sel(a>c) = 1 2

55 DB2 Crash 3 32 Selektivität von Attributen II Verfeinerung: Bereichsanfragen: sel(a c, R) = A max c A max A min sel(c u A c o, R) = Selektivitäten für Verbunde: c o c u A max A min sel (ϕ, R, S) R ϕ S R S

56 DB2 Crash 3 33 Selektivitätsabschätzung 1. Parametrisierte Funktionen Parametriserung einer Funktion, die die Datenverteilung gut widerspiegelt, möglichst genau angeben (etwa Normalverteilung) 2. Histogramme Wertebereich in Unterbereiche aufteilen und die tatsächlich in diese Unterbereiche fallenden Werte zählen 3. Stichproben Selektivität anhand einer zufälligen Stichprobe der gespeicherten Datensätze bestimmen

57 DB2 Crash 3 34 Histogramme für Attributwerte Anzahl min Attributwerte max

58 DB2 Crash 3 35 Höhenbalancierte Histogramme a) gleichverteilte Werte b) ungleichverteilte Werte

59 DB2 Crash 3 36 Kostenberechnung am Beispiel Selektionen über Relation AUFTRAG mit Attribut Ware S = (Die Datenbank belegt insgesamt 4000 Seiten) T AUFTRAG = (in der Relation AUFTRAG sind insgesamt Tupel gespeichert) s/l AUFTRAG = 10 (auf eine Seite passen durchschnittlich 10 Auftrags-Tupel) W Ware,AUFTRAG = 50. (50 verschiedene Waren als Wert des Ware-Attributs) Selektion σ ϕ mit ϕ = (Aθa ψ)

60 DB2 Crash 3 37 Kostenberechnung: Variante A Index I(R(A)) über Selektionsattribut A σ REL ψ ρ σ IND Aθa (I(R(A)), r(r)) A1 Index mit Cluster-Bildung: S R sel(aθa, R). A2 Index ohne Cluster-Bildung: T R sel(aθa, R). (Maximalwert, wenn die Tupel jeweils auf verschiedenen Seiten liegen)

61 DB2 Crash 3 38 Kostenberechnung: Variante B Index I(R(B)) mit B A σ REL Aθa ψ ρ σ IND true (I(R(B)), r(r)) B1 Index mit Cluster-Bildung: S R. B2 Index ohne Cluster-Bildung: T R. Kosten ergeben sich, da die Selektivität des Prädikates true 1 ist

62 DB2 Crash 3 39 Kostenberechnung: Variante C Relationen-Scan Annahme: alle Seiten der Datenbank werden gelesen und alle auf den Seiten vorhandenen Tupel werden gefunden Kosten: durch die Anzahl S gegeben

63 DB2 Crash 3 40 Kostenberechnung: Anfragen 1. σ Ware= Tee (r(auftrag)). Selektivität sel: σ Ware> Tee (r(auftrag)). Selektivität sel: Annahme 1 2.

64 DB2 Crash 3 41 Kosten für Ausführungsvarianten Variante Kostenformel Ware = Tee Ware > Tee A1 S R sel(aθa, R) A2 T R sel(aθa, R) B1 S R B2 T R C S

65 DB2 Crash 3 42 Optimierer-Architektur Anfrage Übersetzung logische Optimierung Anfragerepräsentation (interne Darstellung) Katalog Anfrageverarbeitung Statistiken interne Optimierung Anfragerepräsentation (interne Darstellung) Anfrageplan Übersetzungszeit Anfrageausführung Planauswertung Laufzeit Anfrageergebnis

66 DB2 Crash 3 43 Optimierer-Varianten heuristische, regelbasierte Optimierer: 1. Erzeugung einer interner Anfragerepräsentation durch logische Optimierung 2. mit interne Optimierung einen Anfrageplan erzeugen kostenbasierte (Zwei-Phasen-) Optimierer: 1. Erzeugung verschiedener Anfragerepräsentation durch logische Optimierung 2. Übergabe an interne Optimierung (Plangenerierung) 3. Kostenbewertung 4. Auswahl des besten Plans