Datenbanksysteme II Architektur und Implementierung von Datenbanksystemen

Transkript

1 Datenbanksysteme II Architektur und Implementierung von Datenbanksystemen Winter 2009/10 Melanie Herschel Willhelm-Schickard-Institut für Informatik Organisatorisches zur Übung 5-6 Übungsblätter. Bestehen der Übung: mind. 50% der Punkte für jedes Übungsblatt. Sehr gute Teilnahme wirkt sich ggf. auf Prüfungsnote aus. Bearbeitung: In 2er Gruppen Abgabe bis Mittwoch Abend vor dem nächsten Übungstermin (Datum siehe Übungsblatt). Nur Papierabgaben werden berücksichtigt. Übungstermine Vorrechnen der Aufgabe durch Studenten an der Tafel. Bespechung der häufigsten Unklarheiten. Vertiefung ausgewählter Themen. 2

2 Kapitel 3 Indizes 1.Einführende Terminologie 2.Index Datenstrukturen 3.Datei Organisationen im Vergleich 4.Indizes und Performance Tuning 3 Architektur und Implementierung von Datenbanksystemen WS 2009/10 Melanie Herschel Universität Tübingen Einführende Terminologie Dateiorganisation (file organization) DBMS denkt in Records bzw. Dateien. File and Access Methods --> Verteilung der Daten auf der Festplatte. Ziel: Schneller Zugriff auf gewünschte Daten.!Dateiorganisation: Methode für die Anordnung von Records in einer Datei auf der Festplatte. Verschiede Dateiorganisationen machen manche Operationen effizient, andere wiederum teurer. Anfrage 1 auf Mitarbeiter(Alter, Name, Gehalt) SELECT * FROM Mitarbeiter ORDER BY Alter Sortierung der Mitarbeiter Records auf der Festplatte nach Alter (sequentieller Zugriff) Eine Solche Sortierung ist allerdings teuer aufrechzuerhalten, wenn neue Daten hinzugefügt werden. Anfrage 2 auf Mitarbeiter(Alter, Name, Gehalt) SELECT * FROM Mitarbeiter WHERE Gehalt > 5000 Verwendung der gleichen Dateiorganisation wie bei Anfrage 1 --> Die Datei muss komplett gescannt werden. 4

3 Einführende Terminologie Indizierung Index: Datenstruktur, die Records so auf der Platte anordnet, dass bestimmte Anfragen hinsichtlich ihres I/Os optimiert werden. Ein Index besitzt einen Suchschlüssel (search key). Anfragen über diesen Suchschlüssel können effizient bearbeitet werden. Datei enthält Daten Records. Mehrere Indizes (mit verschiedenen Suchschlüsseln) pro Datei möglich!optimierung von Anfragen, die durch Dateiorganisation selbst nicht optimiert sind. Indizes für Anfrage 1 und Anfrage 2 Index 1 Index 2 Suchschlüssel Alter Gehalt Optimierte Anfrage SELECT * FROM Mitarbeiter ORDER BY Alter SELECT * FROM Mitarbeiter WHERE Gehalt > 5000 Repräsentation auf Platte Index Datei enthält Mitarbeiter Records Index Datei enthählt Records, die es erlauben, auf entsprechende Mitarbeiter Records zuzugreifen. 5 Einführende Terminologie Dateneintrag (data entry) Dateneintrag: bezeichnet Records, die in einer Indexdatei gespeichert sind. Dateneintrag k*: Notation für einen Dateneintrag mit Suchschlüsselwert k. k* enthält genug Informationen, um ein oder mehrere Daten Records zu lokalisieren, die k entsprechen. Ziel: effizientes Durchsuchen der Index Datei um gewünschte Dateneinträge zu finden. Diese dann verwenden, um Daten Records zu finden. Veschiedene Möglichkeiten für Inhalt eines Dateneintrags 6

4 Einführende Terminologie Clustered vs. Unclustered Indizes Definition Sind die Daten Records einer Datei auf der Festplatte nach Attribut(en) A sortiert und existiert ein Index I, dessen Suchschlüssel A ist, so ist I ein Clustered Index. Entspricht die Reihenfolge nach Suchschlüssel des Index nicht der Reihenfolge der Daten Records auf der Festplatte, so sprechen wir von einem Unclustered Index. Auswirkung auf Anfrageeffizienz Bereichsanfragen werden sehr ineffizient bearbeitet wenn der verwendete Index unclustered ist. In diesem Fall lässt die Reihenfolge der Dateneinträge im Index keine Schlüsse auf die Reihenfolge der Daten Records auf der Festplatte zu. Anfrage 3: Bereichsanfrage auf Mitarbeiter(Alter, Name, Gehalt) SELECT * FROM Mitarbeiter WHERE Alter >= 40 AND Alter <= Clustered Index über Alter: a. Anfrage an den Index, um Dateneintrag mit Alter = 40 zu finden. Dieser referenziert Datenrecord r b. Sequentieller Scan über Daten Records von r bis r, wobei Alter > 50 für r 2. Unclustered Index über Alter: a. Wie bei clustered Index b. Den Index traversieren um nach und nach Referenzen zu gesuchten Daten Records zu bekommen. Diese Daten Records sind über die ganze Datei verteilt. 7 Einführende Terminologie Clustered vs. Unclustered Indizes Clustered Indizes in DB2 Erstellen eines Clustered Index IXR über Tabelle R mit Suchschlüssel A: CREATE INDEX IXR ON R (A ASC) CLUSTER Hier ein Auszug aus dem DB2 V9.5 Handbuch: [ CLUSTER ] specifies that the index is the clustering index of the table. The cluster factor of a clustering index is maintained or improved dynamically as data is inserted into the associated table, by attempting to insert new rows physically close to the rows for which the key values of this index are in the same range. Only one clustering index may exist for a table so CLUSTER may not be specified if it was used in the definition of any existing index on the table (SQLSTATE 55012). A clustering index may not be created on a table that is defined to use append mode (SQLSTATE 428D8). 8

5 Einführende Terminologie Primär- und Sekundärindizes Enthält der Suchschlüssel eines Index den Primärschlüssel einer Tabelle, so ist dieser ein Primärindex. Sonst sprechen wir von Sekundärindex. Zwei Dateneinträge sind Duplikate wenn sie den gleichen Suchschlüsselwert haben. Ein Primärindex enthält garantiert keine Duplikate. Ein Sekundärindex enthält im Allgemeinen Duplikate. Wenn wir wissen, dass der Suchschlüssel keine Duplikate enthält (d.h., er enthält einen Schlüsselkandidaten), so sprechen wir von einem Unique Index. Charakterisieren Sie die Indexdateien nach (i) Suchschlüssel k, (ii) Art Dateneintrag, (iii) Clustered Eigenschaft, (iii) Primärindex Eigenschaft A B C D rid1 1 1 a 50 rid2 2 2 c 60 rid3 3 1 b 50 Daten Records, Reihenfolge wie auf Platte A B C D 1 1 a c b 50 Index Datei 1 k rid_list 1 {rid1, rid3} 2 {rid2} Index Datei 2 k rid a rid1 b rid3 c rid2 Index Datei 3 9 Index Datenstrukturen Überblick Indexstruktur, bestehend aus Indexeinträgen Index Datei Dateneinträge (sequence set) Daten Records Daten Datei Wofür war doch gleich der Index? Wir erstellen einen Index, um effizient Daten Records auffinden zu können, indem wir 1 2 Die Indexstruktur effizient nach relevanten Dateneinträgen durchsuchen, und Die gefundenen Dateneinträge nutzen, um die gesuchten Daten Records zu finden. Punkt 2 ist (nun) klar, aber... Wie sind die Dateneinträge im Index organisiert, um Punkt 1 zu lösen?! Spezielle Indexstrukturen, z.b. Hash-basierte Indexstrukturen (siehe Kapitel 5) Baum-basierte Indexstrukturen (siehe Kapitel 4) Die Wahl der Indexstruktur ist unabhängig von der Wahl der Art der gespeicherten Dateneinträge (Art 1-3) 10

6 Kapitel 3 Indizes 1.Einführende Terminologie 2.Index Datenstrukturen 3.Datei Organisationen im Vergleich 4.Indizes und Performance Tuning 11 Architektur und Implementierung von Datenbanksystemen WS 2009/10 Melanie Herschel Universität Tübingen Index Datenstrukturen Hash-basierte Indexstrukturen Sortiert Dateneinträge basierend auf dem Hashwert von k in eine Indexstruktur ein. Basierend auf dem Hashwert erlaubt die Indexstruktur auch ein effizientes Auffinden des entsprechenden Dateneintrags (1-2 Disk I/Os) Intuition: Dateneinträge werden in Buckets einsortiert (1 Bucket pro Hashwert). Ein Bucket besteht aus einer Primärseite und wenn nötig aus weiteren Seiten. Seiten in einem Bucket sind als Kette verlinkt. Suchschlüssel k h(k) = x h(k) =y h h(k) =z 12

7 Index Datenstrukturen Beispiel Hash-basierter Indexstrukturen Hash-basierter Index für Anfrage 1 Suchschlüssel = Alter Hashfunktion h(alter): trunc-decimal(alter/10) Index der Art (1) Hash-basierter Index für Anfrage 2 Suchschlüssel = Gehalt Hashfunktion h(gehalt): trunc-decimal(gehalt/1000) Index der Art (2) Name Alter Gehalt Smith Basu Bristow Cass Tracy Jones Ashby Daniels Relationale Tabelle Mitarbeiter 14 Index Datenstrukturen Baum-basierte Indexstrukturen Dateneinträge sind nach Schlüsselwert sortiert und in einer doppelt verlinkten Struktur gespeichert. Die Seiten, die die Dateneinträge beinhalten sind die Blattknoten eines Baum-basierten Index. Indexeinträge werden in einer hierarchischen Suchstruktur verwaltet, um die Suche einer Seite zu steuern. Wesentliche Felder in einem Indexeintrag sind: min_key und max_key: zwei Suschschlüsselwerte. kind_kleiner: Zeiger zu einem Indexeintrag, der in der hierarchischen Struktur ein Kind des aktuellen Eintrags ist (Kindseite). Folgt man diesem Pfad, gelangt man ausschließlich zu Dateneinträgen, deren Suchschlüssel k < min_key sind. kind_zwischen: Zeiger auf eine Kindseite, über die man Dateneinträge findet, deren Suchschlüssel k zwischen min_key und max_key liegt, also min_key <= k < max_key. kind_größer: Zeiger auf eine Kindseite, über die man Dateneinträge mit k >= max_key erreicht. 15

8 Index Datenstrukturen Beispiel einer Baum-basierte Indexstruktur Name Alter Gehalt Smith Basu Bristow Cass Tracy Jones Ashby Daniels Relationale Tabelle Mitarbeiter Alter < 12 Beginn der Suche nach Alter > <= Alter < 78 Alter >= Baum basierter Index Suchschlüssel: Alter Anfrage: SELECT * FROM Mitarbeiter WHERE Alter > 24 AND Alter < Ashby Bristow Basu Daniels Jones Smith Tracy Cass Index Datenstrukturen B+ Bäume I/O Kosten in einer beliebigen Baumstruktur Jeder Knoten in der Baumstruktur wird auf einer separaten Seite gespeichert.! Anzahl I/Os während der Suche = Anzahl Knoten auf dem Pfad von der Wurzel bis zum Blattknoten + Anzahl Blattknoten, die zusätzlich zum ersten Blattknoten relevante Records enthalten (in unserem Beispiel: = 6). In der Praxis werden mehrere Indexeinträge auf eine Seite gespeichert, was die effizienz erhöht. B+ Baum Ein B+ Baum garantiert, dass alle Pfade von der Wurzel zu den Blättern gleicher Länge sind. Ein B+ Baum ist ausgeglichen (balanced) Die Höhe h eines B+ Baums ist die Länge eines Wurzel-zu-Blatt Pfades. Der fan-out f is die Durchschnittliche Anzahl Kinder pro Nicht-Blattknoten. I/O Kosten in einem B+ Baum Ein B+ Baum garantiert, dass alle Pfade von der Wurzel zu den Blättern gleicher Länge sind. Ein Baum der Höhe h und mit fan-out f hat f h Blattknote. In der Praxis ist f >= 100, d.h. ein B+ Baum der Höhe 4 enthält 100 Millionen Blattknoten. Suche nach einer Seite in unserem Beispiel mit 4 I/Os, Binärsuche bräuchte log > 25 I/Os. 17

9 Kapitel 3 Indizes 1.Einführende Terminologie 2.Index Datenstrukturen 3.Datei Organisationen im Vergleich 4.Indizes und Performance Tuning 18 Architektur und Implementierung von Datenbanksystemen WS 2009/10 Melanie Herschel Universität Tübingen Datei Organisationen im Vergleich Kandidaten Wir vergleichen die Kosten einfacher Operationen für verschiedene Dateiorganisationen: 1.Datei beliebig geordneter Mitarbeiter Records, oder Heap Datei. 2.Datei von Mitarbeiter Records sortiert nach <Alter, Gehalt> 3.Clustered B+ Baum mit Suchschlüssel <Alter, Gehalt> 4.Heap Datei mit einem unclustered B+ Baum Index über <Alter, Gehalt> 5.Heap Datei mit einem unclustered Hash Index über <Alter, Gehalt> Der Suchschlüssel ist immer <Alter, Gehalt>. Alle Selektionen einer Anfrage betrachten nur Felder des Suchschlüssels. 19

10 Datei Organisationen im Vergleich Aufgaben (Operationen) Scan (scan) Durchsuche alle Records einer Datei. Alle Seiten in der Datei müssen von der Platte in den Buffer Pool geladen werden. Es existiert ein CPU Overhead pro Record um dieses auf der Seite im Buffer Pool zu lokalisieren. Suche mit Gleichheitselektion (equality search) Finde alle Records, die eine Gleichheitsanfrage beantworten, z.b. Alter = 23 AND Gehalt = Wie beim Scan müssen Seiten, die den Suchkriterien entsprechen in den Buffer Pool geladen werden und einzelne Records auf den Seiten müssen durchsucht werden. Suche mit Bereichsselektion (range search) Finde alle Records, die eine Bereichsanfrage beantworten, z.b., Alter > 35 Einfügen eines Records in eine Datei (insert) Identifikation der Seite in der Datei, in die wir das Record einfügen Laden der Seite in den Hauptspeicher Ändern der Seite Zurückschreiben der Seite auf die Platte Je nach Dateiorganisation müssen wir eventuell auch weitere Seiten laden, ändern, und zurückschreiben. Löschen eines Records aus einer Datei (delete) Auffinden der Seite in der Datei, aus der Record gelöscht wird. Laden der Seite in den Hauptspeicher, ändern, und zurückschreiben. Je nach Dateiorganisation müssen wir eventuell auch weitere Seiten laden, ändern, und zurückschreiben. 20 Datei Organisationen im Vergleich Bewertung Wir bewerten jede Methode nach einem Kostenmodell. Die Kosten entsprechen der Laufzeit einer bestimmten Operation. Wir betrachten die in der Tabelle gelisteten Parameter in unserem Kostenmodell. Echte Systeme haben komplexere Kostenmodelle (CPU Kosten, Netzwerklatenz Kosten, sequentieller Zugriff auf Blöcke,...) Kürzel Bedeutung Typische Werte B R D C H Anzahl Daten Seiten, wenn Records lückenlos auf Seiten geschrieben werden. Anzahl Records pro Seite Durchschnittliche Zeit um eine Seite auf Platte zu schreiben bzw. von Platte zu lesen. Durchschnittliche Zeit um ein Record im Hauptspeicher zu bearbeiten (z.b. Vergleich zwischen Feldinhalt und Konstante in Prädikat) Zeit, um Hash Funktion auf ein Record anzuwenden. 15 ms 100 ns 100 ns F Fan-out

11 Datei Organisationen im Vergleich Kandidat 1: Heap Datei scan... Seiten in Heap File Buffer Pool... (1) Jede der B Seiten muss in den Hauptspeicher!B*D (2) R Records pro Seite müssen bearbeitet werden!b*r*c Gesamtkosten scan: B(D + RC) equality & range search 22 Datei Organisationen im Vergleich Kandidat 1: Heap Datei delete Sei r das zu löschende Record. insert Wir fügen ein Record am Ende der Heap Datei ein. Sei p die letzte Seite der Heap Datei. 1.Wir lesen p in Zeit D in den Hauptspeicher. 2.Wir fügen ein Record in Zeit C hinzu. 3.Wir schreiben in Zeit D die geänderte Seite wieder auf Platte.! Gesamtkosten insert: 2D + C 1.find: Wir suchen r in Heap Datei (Kosten siehe unten). 2.Wir löschen r aus der gefundenen Seite (die nun bereits im Hauptspeicher ist) in Zeit C. 3.Wir schreiben in Zeit D die geänderte Seite wieder auf Platte. Kosten für find: Ist r mit seiner rid spezifiziert, können wir mit dieser die page_id bestimmen und diese Seite direkt einlesen.! Kosten find = D Ist das zu löschende Record durch eine Gleichheits- oder Bereichsanfrage definiert, entsprechen die Suchkosten denen von equality search bzw. range search.! Gesamtkosten delete: find + C + D 23

12 Datei Organisationen im Vergleich Kandidat 2: Sortierte Datei scan Wie bei unsortierter Heap Datei müssen alle Seiten betrachtet werden. Interessant ist hier, dass die Daten in sortierter Reihenfolge betrachtet werden (geeignet für ORDER BY Anfragen) Gesamtkosten scan: B (D + RC) equality search Wenn Selektionskriterien dem Suchschlüssel <Alter, Gehalt> entsprechen (d.h., wir haben mindestens eine Selektion auf dem ersten Feld des Schlüssels): Finde die erste Seite, die dem Selektionskriterium entspricht (falls es eine gibt) mit binärer Suche in log2b Schritten. Jeder Schritt benötigt ein Disk I/O und zwei Vergleiche. Wurde die richtige Seite gefunden, finde mit binärer Suche das erste qualifizierende Record. Die Kosten dafür sind C log2r. Entsprechen mehrere Tupel dem Suchkriterium, müssen die Kosten für deren Bearbeitung auch in betracht gezogen werden. Da die Daten sortiert sind können wir vom ersten Record aus die Records der Seite traversieren, bis das Kriterium nicht mehr erfüllt ist.! Gesamtkosten equality search: D log2b + Clog2 R Entsprechen Selektionskriterien nicht dem Suchschlüssel, sind die Gesamtkosten wir bei unsortierten Dateien. range search Diskussion analog zu equality selection.! Gesamtkosten range search: D log2b + C log2r (bei Selektion dem Suchschlüssen entsprechend). 24 Datei Organisationen im Vergleich Kandidat 2: Sortierte Datei insert Füge Record ein: Ashby Finde Position des Record auf Seite... Ashby Bristow Basu Daniels Jones Smith Tracy Cass Sortierte Datei (Schlüssel = <Alter, Gehalt> 1 Finde Seite 3 Füge Record ein und verschiebe alle darauf Folgenden Records um eine Position.... Ashby Bristow Basu Daniels Ashby Jones Smith Tracy Cass

13 Datei Organisationen im Vergleich Kandidat 2: Sortierte Datei insert (ctd) Im Durchschnitt nehmen wir an, dass die eingefügten Records in der Mitte der Datei eingefügt werden. In diesem Fall lesen wir die nachfolgende Hälfte der Datei in den Hauptspeicher und schreiben diese nach Hinzufügen des Records wieder auf die Platte.! Gesamtkosten insert: find + 2 (0.5B (D + RC)) delete Der Prozess ist ähnlich zum insert Prozess: Wir suchen das zu löschende Record. Wir löschen das Record. Wir verschieben alle darauf folgende Records um die entstandene Lücke zu schließen. Unter den gleichen Annahmen wie bei insert sind die Gesamtkosten gleich den Gesamtkosten von insert.! Gesamtkosten delete: find + 2 (0.5B (D + RC)) 26 Datei Organisationen im Vergleich Kandidat 3: Clustered B+ Baum scan Empirische Studien haben ergeben, dass in clustered B+ Bäumen Seiten im Durchschnitt zu 67% gefüllt sind. Daher ist die Anzahl Daten Seiten ca. 1.5B, wenn wir die gleiche Menge an Daten wie bisher speichern.! Gesamtkosten scan: 1.5 B (D + RC) equality search Entsprechen Selektionskriterien dem Suchschlüssel, so gilt Folgendes: Wir können das entsprechende Record in logf1.5 B Schritten ermitteln. Die Wurzelseite des B+ Baums wird üblicherweise im Bufferpool gehalten. In diesem Fall sparen wir uns eine I/O Operation (Gesamtkosten ignorieren diese Optimierung). Jeder Schritt benötigt ein Platten I/O und zwei Vergleiche. Ist die richtige Seite gefunden, kann das gesuchte Record wieder mit Binärsuche in C log2 R gefunden werden.!gesamtkosten equality search: D logf 1.5B + C log2 R Entspricht mehr als ein Tupel dem Suchkriterium, befinden sich diese garantiert in der direkten Nachbarschaft des zuerst gefundenen Records. In diesem Fall entsprechen die Gesamtkosten den Gesamtkosten um das erste Record zu finden, plus die Kosten um sequentiell alle weiteren Records zu lesen. range search Diskussion analog zur Diskussion von equality search, wenn mehrere Tupel dem Suchkriterium entsprechen. 27

14 Datei Organisationen im Vergleich Kandidat 3: Clustered B+ Baum insert Füge Record ein: Ashby Alter < <= Alter < 78 Alter >= Finde Seite Seiten zu 67% gefüllt... Ashby Bristow Basu Daniels Ashby Jones Smith Tracy Cass Finde Position des Record auf Seite 3 Füge Record ein (Verschieben auf Folgeseiten wegen Seitenfüllgrads nur selten nötig) 28 Datei Organisationen im Vergleich Kandidat 3: Clustered B+ Baum insert (ctd) Kosten für Schritt 1: D logf(1.5b) Kosten für Schritt 2: C log2 R Kosten für Schritt 3: D! Gesamtkosten insert: D logf1.5b + C log2 R + D delete Der Prozess ist ähnlich zum insert Prozess: Wir suchen das zu löschende Record. Wir löschen das Record. Wir verschieben alle darauf folgende Records in aktueller Seite um die entstandene Lücke zu schließen.! Gesamtkosten delete: DlogF1.5B + Clog2R + D 29

15 Datei Organisationen im Vergleich Kandidat 4: Heap Datei mit Unclustered B+ Baumindex Anzahl Seiten hängt von der Größe eines Dateneintrags ab. Realistische Annahmen: Größe Dateneintrag = Größe Daten Record / 10 Seiten im Index zu 67% gefüllt.!#blattknoten im Index = 0,1(1.5B) = 0.15B!#Dateneinträge pro Seite = 6,7R Daten Records Indexstruktur, bestehend aus Indexeinträgen Dateneinträge scan Wir scannen die Blattknoten der Indexdatei, die Dateneinträge enthalten --> 0.15B (D+ 6.7RC) I/Os Für jeden Dateneintrag ermitteln wir das entsprechende Daten Record --> 1 I/O pro Record, Kosten insgesamt BR(D + C). Die Daten Datei scannen und sortieren wäre günstiger (4B)!! Gesamtkosten scan: 0.15B (D + 6.7RC) + BR (D + C) = BD ( R) BRC 30 Datei Organisationen im Vergleich Kandidat 4: Heap Datei mit Unclustered B+ Baumindex equality search range search 31

16 Datei Organisationen im Vergleich Kandidat 4: Heap Datei mit Unclustered B+ Baumindex insert 2 Finden des entsprechenden Blattknotens D logf 0.15 B + C log2 6.7R 3 Einfügen des Dateneintrags & auf Platte zurückschreiben D Dateneinträge 1 Einfügen in Heap Datei 2D + C Daten Records! Gesamtkosten insert: 3D + C + D logf 0.15 B + C log2 6.7R delete Finden des zu löschenden Dateneintrags in der Index-Datei und des entsprechenden Records in der Daten- Datei --> D logf 0.15B + Clog2 6.7R + D Löschen der Einträge in der Index Datei und der Heap Datei --> 2D! Gesamtkosten delete: D logf 0.15 B + C log2 6.7R + 3D 32 Datei Organisationen im Vergleich Kandidat 5: Heap Datei mit Unclustered Hash Index Suchschlüssel k h h(k) = x h(k) =y Vereinfachende Annahme: keine Overflow Ketten # Dateneinträge pro Seite im Index = 10 * # Records pro Seite in der Heap Datei Anzahl Seiten in Indexdatei bei 80% Füllgrad = 1.25 * (0.1 B) = B. Anzahl Dateneinträge pro Indexseite = 10 (0.8 R) = 8R h(k) =z Seiten in einem Bucket zu 80% gefüllt scan 33

17 Datei Organisationen im Vergleich Kandidat 5: Heap Datei mit Unclustered Hash Index equality search Sehr effizient wenn Gleichheitsprädikate auf allen Attributen des Suchschlüssels definiert sind (z.b. auf Alter und Gehalt). Identifikation der relevanten Seite im Index: H Da wir annehmen, dass keine Overflow Seiten existieren kostet das Laden des Buckets in den Hauptspeicher D. Unter der Annahme, dass wir den Dateneintrag im Durchschnitt nach Scannen der Hälfte der Indexseite finden, sind die Kosten, um den entsprechenden Dateneintrag zu finden 0.5 (8R) C = 4 RC. Wir lesen das entsprechende Daten Record in Zeit D in den Hauptspeicher.! Gesamtkosten equality search: H + 2D + 4RC Entspricht mehr als ein Tupel dem Suchkriterium, befinden sich diese nicht unbedingt nebeneinander (in der Index Datei als auch in der Daten Datei). In diesem Fall entsprechen die Gesamtkosten den Gesamtkosten um das erste Record zu finden (H + D + 4RC), plus die Kosten D für jedes weitere qualifizierende Record. range search Die Hash Struktur bietet keine Hilfe bei Bereichsanfragen. Daher muss die gesamte Heap Datei gescannt werden.! Gesamtkosten range search: B (D+RC) 34 Datei Organisationen im Vergleich Kandidat 5: Heap Datei mit Unclustered Hash Index insert Einfügen der Daten Record in die Heap Datei: 2D + C Ermitteln der entsprechenden Seite im Index: H + D Ändern der Index Seite und Zurückschreiben auf Platte: C + D! Gesamtkosten insert: 4D + H + 2C delete Suche nach Daten Record in der Heap Datei und des entsprechenden Dateneintrags im Hash Index: H + 2D + 4RC Löschen des Records und des Dateineintrags und zurückschreiben auf Platte: 2D! Gesamtkosten delete: H + 4D + 4 RC 35

18 Datei Organisationen im Vergleich Kandidat 4: Heap Datei mit Unclustered B+ Baumindex insert 2 Finden des entsprechenden Blattknotens D logf 0.15 B + C log2 6.7R 3 Einfügen des Dateneintrags & auf Platte zurückschreiben D Dateneinträge 1 Einfügen in Heap Datei 2D + C Daten Records! Gesamtkosten insert: 3D + C + D logf 0.15 B + C log2 6.7R delete Finden des zu löschenden Dateneintrags in der Index-Datei und des entsprechenden Records in der Daten- Datei --> D logf 0.15B + Clog2 6.7R + D Löschen der Einträge in der Index Datei und der Heap Datei --> 2D! Gesamtkosten delete: D logf 0.15 B + C log2 6.7R + 3D 36 Datei Organisationen im Vergleich Kandidat 5: Heap Datei mit Unclustered Hash Index equality search Sehr effizient wenn Gleichheitsprädikate auf allen Attributen des Suchschlüssels definiert sind (z.b. auf Alter und Gehalt). Identifikation der relevanten Seite im Index: H Da wir annehmen, dass keine Overflow Seiten existieren kostet das Laden des Buckets in den Hauptspeicher D. Unter der Annahme, dass wir den Dateneintrag im Durchschnitt nach Scannen der Hälfte der Indexseite finden, sind die Kosten, um den entsprechenden Dateneintrag zu finden 0.5 (8R) C = 4 RC. Wir lesen das entsprechende Daten Record in Zeit D in den Hauptspeicher.! Gesamtkosten equality search: H + 2D + 4RC Entspricht mehr als ein Tupel dem Suchkriterium, befinden sich diese nicht unbedingt nebeneinander (in der Index Datei als auch in der Daten Datei). In diesem Fall entsprechen die Gesamtkosten den Gesamtkosten um das erste Record zu finden (H + D + 4RC), plus die Kosten D für jedes weitere qualifizierende Record. range search Die Hash Struktur bietet keine Hilfe bei Bereichsanfragen. Daher muss die gesamte Heap Datei gescannt werden.! Gesamtkosten range search: B (D+RC) 37

19 Datei Organisationen im Vergleich Kandidat 5: Heap Datei mit Unclustered Hash Index insert Einfügen der Daten Record in die Heap Datei: 2D + C Ermitteln der entsprechenden Seite im Index: H + D Ändern der Index Seite und Zurückschreiben auf Platte: C + D! Gesamtkosten insert: 4D + H + 2C delete Suche nach Daten Record in der Heap Datei und des entsprechenden Dateneintrags im Hash Index: H + 2D + 4RC Löschen des Records und des Dateineintrags und zurückschreiben auf Platte: 2D! Gesamtkosten delete: H + 4D + 4 RC 38 Datei Organisationen im Vergleich Zusammenfassung File type scan equality search range search insert delete (relativ zu search) Heap BD 0,5 BD BD 2D search + D Sorted BD D log2 B D log2 B +#matching pages search + BD search + BD Clustered 1,5 BD D logf 1,5B D logf 1.5B +#matching pages search + D search + D Unclustered tree index BD (R + 0,15) D (1+logF 0,15B) D( logf 0,15B+ #matching recods ) D (3 + logf 0,15B) search + 2D Unclustered hash index BD (R + 0,125) 2D BD 4D search + 2D 39

20 Datei Organisationen im Vergleich Zusammenfassung Heap Dateien Gute Speichereffizienz Schnelle Scans und Einfügeoperationen. Langsame Such- und Löschoperationen. Sortierte Dateien Gute Speichereffizienz Schnellere Suche als bei Heap Dateien. Langsames Einfügen und Löschen von Records. Daher werden in realen DBMS Dateinen selten komplett sortiert gespeichert. Clustered B+ Baum-Indizes Geringere Speichereffizienz als Heap Dateien oder sortierte Dateien. Alle Vorteile einer Sortierten Datei plus effizientes Einfügen und Löschen. Suche schneller als bei sortierten Dateien, wobei diese in der Praxis schneller sein können, wenn eine hohe Anzahl Records sequentiell gesucht werden (Grund: sequentielles I/O). Unclustered Baum- bzw. Hash-Indizes Schnelle Suche, schnelles Löschen, schnelles Einfügen. Scans und Bereichsanfragen mit vielen übereinstimmenden Records sind langsam. Hash Indizes sind etwas schneller als Baum Indizes bei Gleichheitsanfragen, unterstützen jedoch keine Bereichsanfragen.!Keine der betrachteten Dateiorganisationen ist besser als alle anderen. Daher ist die Wahl einer geeigneten Dateiorganisation immer anwendungsabhängig. 40 Datei Organisationen im Vergleich Zusammenfassung Beispiel: Performance einer Bereichsanfrage bei wachsender Dateigröße Heap File Sorted File Zeit (s) bei D = s Anzahl Seiten (B) 41

21 Datei Organisationen im Vergleich Zusammenfassung Beispiel: Performance einer Löschoperation bei wachsender Dateigröße, gegeben die zu löschende rid Heap File Sorted File Zeit (s) bei D = s Anzahl Seiten (B) 42 Kapitel 3 Indizes 1.Einführende Terminologie 2.Index Datenstrukturen 3.Datei Organisationen im Vergleich 4.Indizes und Performance Tuning 43 Architektur und Implementierung von Datenbanksystemen WS 2009/10 Melanie Herschel Universität Tübingen

22 Indizes und Performance Tuning Wir haben soeben gesehen, dass keine Indexstruktur für alle Arten von Operationen geeignet ist. Anfrage, die von effizienter Gleichheitssuche profitiert. SELECT * FROM R WHERE C = 42!Hash-basierter Index Anfrage, die von effizienter Bereichssuche profitiert. SELECT * FROM R WHERE A > 0 AND A < 100!Baum-basierter Index Anfrage, die von einer Sortierung der Records nach A profitiert. SELECT * FROM R WHERE A > 0 AND A < 100!Clustered Index (sequentieller Zugriff)! Welcher Index bzw. welche Indizes sind für meine Anwendung geeignet? Wahl durch verschiedene Faktoren beeinflusst, unter Anderem: Art der Anfragen, die typischerweise an das DBMS gestellt werden. Verteilung der Daten in einer Relation. Um Redundanz zu vermeiden, maximal ein Clustered Index. Optimierung: Anfragen, die nur den Suchschlüssel beinhalten, können durch Seitenzugriffe auf Index bereits beantwortet werden (index-only evaluation). 44 Indizes und Performance Tuning Workload Definition Eine Workload ist definiert als eine Menge von Operationen, die typischerweise auf dem DBMS ausgefürt werden. Moderne DBMS erlauben es, Operationen in einer Workload zu gewichten, um die relative Häufigkeit der Anfragen, und somit die Relevanz deren effizienter Ausführung für die Gesamteffizienz des DBMS zu spezifizieren. Workload Workload Anfragen SELECT * FROM R WHERE C = 42 SELECT * FROM R WHERE A > 0 AND A < 100 Gewichtung 1 10 x pro Minute 100 x pro Minute!Baum-basierter Index Gewichtung x pro Minute 1 x pro Minute!Hash-basierter Index 45

23 Indizes und Performance Tuning Statistiken Die geeignete Wahl eines Index hängt auch von der Werteverteilung in Attributen ab. Moderne DBMS verwalten Statistiken über solche Werteverteilungen (in Form von Histogrammen) um unter Anderem geeignete Indizes zu identifizieren. Solche Histogramme sind ebenfalls für Anfrageoptimierung wichtig. Workload Workload Anfragen SELECT * FROM R WHERE C = 42 SELECT * FROM R WHERE A > 0 AND A < 100 Verteilung 1 C gleichverteilt von 0 bis 100 A entspricht Altersverteilung!Hash-basierter Index Verteilung 2 C = 42 in 95% aller Records Nur 5 % aller Werte in A fallen zwischen 0 und 100!Baum-basierter Index / Clustered Index 46 Indizes und Performance Tuning Designbeispiele für Clustered Indizes Anfrage 1 SELECT M.AbteilungsNR FROM Mitarbeiter M WHERE M.Alter > 40 Gegeben ein B+ Baum über Alter. Nur 10 % aller Mitarbeiter sind älter als 40 Jahre. Ist die Verwendung des Index sinnvoll? Ist der Index clustered? Nein --> Für jeden der 10% Mitarbeiter muss Dateneintrag im Index und die entsprechende Seite der Daten ermittelt werden. Das kann teurer als ein einfacher scan sein. Ja --> Finden des ersten Mitarbeiters mit Alter > 40 mit Hilfe des Index. Danach die Daten Records sequentiell lesen, daher nur ca. 10% der Kosten eines scans. Anfrage 2 SELECT M.AbteilungsNR, COUNT(*) FROM Mitarbeiter M WHERE M.Alter > 10 GROUP BY M.AbteilungsNR Gegeben ein B+ Baum über Alter. Alle Mitarbeiter sind älter als 10 Jahre. Verwenden wir den Index, so können wir Records mit Alter > 10 damit ermitteln und diese sortieren wir dann nach AbteilungsNR. In diesem Fall sollte der Index auf jeden Fall clustered sein, um sequenzielles I/O auf Daten zu nutzten. Ein scan über eine sortierte Datei wäre ähnlich effizient. Könnte ein Index über AbteilungsNR sinnvoller sein? Clustered Index: ja, da wir den Index verwenden, um ersten Mitarbeiter einer Gruppe zu finden und danach sequentiell Records (mit Alter > 10) lesen. Wenn der Index nicht clustered ist, ist potentiell ein Seiten I/O pro Mitarbeiter nötig! 47

24 Indizes und Performance Tuning Designbeispiele für Clustered Indizes Anfrage 3 (hohe Selektivität) Wahl eines Index für Anfrage 3 SELECT M.AbteilungsNR, COUNT(*) FROM Mitarbeiter M WHERE M.Alter > 60 GROUP BY M.AbteilungsNR Wahl eines Index für Anfrage 4 Anfrage 4 (Selektion auf Schlüsselattribut) SELECT M.AbteilungsNR FROM Mitarbeiter M WHERE M.PNR = Indizes und Performance Tuning Zusammengesetzte Suchschlüssel Ein zusammengesetzter Suchschlüssel ist ein Suchschlüssel über mehr als ein Attribut, z.b. über <Alter, Gehalt>. Gleichheitsanfrage über zusammengesetzte Schlüssel? Jedes Feld im Suchschlüssel ist in der Anfrage einer Konstanten gleichgesetzt. Gleichheitsanfrage (Suchschlüssel = <Alter, Gehalt>) SELECT * FROM Mitarbeiter WHERE Alter = 30 AND Gehalt = 3000 Bereichsanfrage über zusammengesetzte Schlüssel? Nicht jedes Feld im Suchschlüssel ist in der Anfrage einer Konstanten gleichgesetzt und lässt somit den Bereich für fehlende Attribute komplett offen. Prädikate der Anfrage können auch Ungleichungen enthalten. Bereichsanfragen wenn Suchschlüssel <Alter, Gehalt> SELECT * FROM Mitarbeiter WHERE Alter = 20 SELECT * FROM Mitarbeiter WHERE Alter < 20 AND Gehalt >

25 Indizes und Performance Tuning Zusammengesetzte Suchschlüssel <Alter, Gehalt> <11, 80, rid2> <12,10, rid1> <12, 20, rid3> <13, 75, rid4> <Gehalt, Alter> <10, 12, rid1> <20, 12, rid3> <75, 13, rid4> <80, 11, rid2> Zusammengesetzte Suchschlüssel Name Alter Gehalt Bob Cal Joe Sue Daten Records <Alter> <11, rid2> <12, rid1> <12, rid3> <13, rid4> <Gehalt> <10, rid1> <20, rid3> <75, rid4> <80, rid2> Einfache Suchschlüssel Welcher Index ist für die Anfrage Gehalt > 40 geeignet? 51 Indizes und Performance Tuning Zusammengesetzte Suchschlüssel Ein Index entspricht einem Selektionsbedingung wenn der Index in der Lage ist, ausschließlich die Tupel, die dem Ergebnis der Anfrage entsprechen, zurückzugeben. Für Selektionsbedingungen der Form B1 AND B2 AND... AND Bn (Konjunktion) bestimmen wir, ob ein Index einer Anfrage entspricht, wie folgt: Hash-Index Existiert für jedes Feld ki im Suchschlüssel <k1, k2,..., km> eine Gleichheitsbedingung Bi der Form ki = C, wobei C eine Konstante, so entspricht der Hash-Index der Selektionsbedingung. Baum-Index Gegeben ein Suchschlüssen <k1, k2,..., kp>, so entspricht dieser der Selektionsbedingung, wenn für jeden Teilschlüssel k1, k2,..., km, m <= p, eine Bedingung Bi (Gleichheit oder Ungleichheit) existiert. 52

26 Indizes und Performance Tuning Zusammengesetzte Suchschlüssel Vorteile Ein größeres Spektrum an Anfragen kann durch zusammengesetzte Schlüssel beatwortet werden. Der Index selbst entält mehr Daten zu einem Record, was die Chancen für eine Index- Only-Evaluation steigert. Nachteile Erhöhter Aktualisierungsaufwand, da ein Index mit zusammengesetztem Suchschlüssel aktualisiert werden muss, wenn eines der Felder im Suchschlüssel modifiziert wird. Geringere Speichereffizienz, da die Dateneinträge im Index größer sind. Bei B + -Baum-Indizes kann dies zu einer Erhöhung der Baumtiefe führen. 53 Indizes und Performance Tuning Designbeispiele für Indizes mit Zusammengesetztem Suchschlüssel Anfrage 1 SELECT M.PNR FROM Mitarbeiter M WHERE M.Alter BETWEEN 20 AND 30 AND M.Gehalt BETWEEN 3000 AND 5000 Anfrage 2 SELECT M.PNR FROM Mitarbeiter M WHERE M.Alter = 25 AND M.Gehalt BETWEEN 3000 AND 5000 Index über <Alter, Gehalt>? Hilfreich, wenn Bedingungen selektiv genug sind. Baum-Index, da Bereichsanfrage nicht von Hash- Indizes unterstützt werden. Clustered Index vermutlich besser als unclustered Index. Index über <Gehalt, Alter>? Unter der Annahme, dass beide Bedingungen eine ähnliche Selektivität haben, macht die Reihenfolge der Felder im Suchschlüssel keinen Unterschied.! Zusammengesetzter, clustered B + -Baum-Index über <Alter, Gehalt> oder über <Gehalt, Alter>. Clustered B+ Baum Index über <Alter, Gehalt>? Records sind zunächst nach Alter sortiert, d.h., alle Records mit Alter = 25 sind gruppiert. Records dieser Altersgruppe sind nach Gehalt (als zweiter Suchschlüssel) sortiert, was die Bereichsanfrage auf Gehalt unterstützt. Clustered B + -Baum-Index über <Gehalt, Alter>? Records sind zunächst nach Gehalt sortiert und zwei Records mit Alter = 25 können weit auseinanderliegen. Index hilfreich für die Bereichsanfrage über Gehalt, aber er kann nicht für das weitaus selektivere Attribut Alter verwendet werden.!zusammengesetzter, clustered B + -Baum-Index über <Alter, Gehalt>. 54

27 Indizes und Performance Tuning Designbeispiele für Indizes mit Zusammengesetztem Suchschlüssel Anfrage 3 SELECT AVG(M.Gehalt) FROM Mitarbeiter M WHERE M.Alter = 25 AND M.Gehalt BETWEEN 3000 AND 5000 Anfrage 4 SELECT M.AbteilungsNR, COUNT(*) FROM Mitarbeiter M WHERE M.Gehalt = GROUP BY M.AbteilungsNR Wie bei Anfrage 2 eignet sich hier ein clustered B + -Baum-Index über <Alter, Gehalt>. Zusätzlicher Vorteil: Index-Only Evaluation! Zusammengesetzter, clustered B + -Baum-Index über <Alter, Gehalt>. Index über AbteilungsNR? Hilft potentiell, Gruppen zu finden. Überprüfung, ob Gehalt = teuer. Analoge Diskussion für Index über Gehalt. Zusammengesetzter Index <Gehalt, AbteilungsNR>? Alle Dateneinträge mit Gehalt = im Index nebeneinander. Alle Dateneinträge mit Gehalt = sind nach AbteilungsNR sortiert, was Gruppierung und COUNT Evaluation vereinfacht. Index-Only Evaluation möglich. Analoge Diskussion für zusammengesetzten Index <AbteilungsNR, Gehalt>! Zusammengesetzter B + -Baum-Index über <Gehalt, AbteilungsNR> oder <AbteilungsNR, Gehalt>. 55 Indizes und Performance Tuning Designbeispiele für Indizes mit Zusammengesetztem Suchschlüssel Anfrage 5 SELECT M.AbteilungsNR, COUNT(*) FROM Mitarbeiter M WHERE M.Gehalt > GROUP BY M.AbteilungsNR Anfrage 6 SELECT M.AbteilungsNR, MIN(M.Gehalt) FROM Mitarbeiter M GROUP BY M.AbteilungsNR Wahl eines Index für Anfrage 5 Wahl eines Index für Anfrage 6 56

28 Indizes und Performance Tuning Toolbasierters Performance Tuning IBM DB2 Design Advisor (Wizard) Generiert automatisch Vorschläge für geeignete Indizes basierend auf einer Workload. Sowohl als Wizard als auch als Kommandozeilentool verfügbar. 57 Indizes und Performance Tuning Toolbasierters Performance Tuning IBM DB2 Design Advisor (Wizard) Workload mit Ausführungsfrequenz (Gewicht einer Anfrage) werden spezifiziert. 58

29 Indizes und Performance Tuning Toolbasierters Performance Tuning IBM DB2 Design Advisor (Wizard) Basierend auf Workload (und weiteren, nicht besprochener Optionen) wird eine Liste sinnvoller Indizes berchnet. Diese können erstellt werden, wenn sie noch nicht existieren. 59 Zusammenfassung Terminologie Überblick über Dateiorganisationen, Indizes, Dateneinträge, Clustered vs. Unclustered Indizes. Indexstrukturen Zwei wesentliche Indexstrukturen: Hash-Indizes und Baum-Indizes. Unter den Baum-Indizes sind B + -Baum-Indizes durch ihre Ausgewogenheit besonders interessant. Vergleich verschiedener Dateiorganisationen und Indizes Keine Indexstruktur und Dateiorganisation ist für alle Datenbankoperationen optimal. Indizes und Performance Tuning Bei der Definition von Indizes und Dateiorganisationen ist auf Workload und Datenverteilung zu achten. 60