Preview of “03 indexing” - uni-tuebingen.de · 2018. 3. 9. · Struktur gespeichert. Die Seiten, die die Dateneinträge beinhalten sind die Blattknoten eines Baum-basierten Index

Datenbanksysteme IIArchitektur und Implementierung von Datenbanksystemen

Winter 2009/10

Melanie HerschelWillhelm-Schickard-Institut für Informatik

Architektur und Implementierung von Datenbanksystemen | WS 2009/10 | Melanie Herschel | Universität Tübingen

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

Architektur und Implementierung von Datenbanksystemen | WS 2009/10Melanie Herschel | Universität Tübingen

Kapitel 3Indizes

1.Einführende Terminologie

2.Index Datenstrukturen

3.Datei Organisationen im Vergleich

4.Indizes und Performance Tuning

3


Einführende TerminologieDateiorganisation (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 MitarbeiterORDER 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 MitarbeiterWHERE Gehalt > 5000

Verwendung der gleichen Dateiorganisation wie bei Anfrage 1 --> Die Datei muss komplett gescannt werden.

4


Einführende TerminologieIndizierung

• 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 RecordsIndex Datei enthählt Records, die es erlauben, auf entsprechende Mitarbeiter Records zuzugreifen.

5


Einführende TerminologieDateneintrag (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


Einführende TerminologieClustered 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 MitarbeiterWHERE Alter >= 40 AND Alter <= 50

1. Clustered Index über Alter: a. Anfrage an den Index, um Dateneintrag mit Alter = 40 zu finden. Dieser referenziert Datenrecord rb. Sequentieller Scan über Daten Records von r bis r’, wobei Alter > 50 für r’

2. Unclustered Index über Alter:a. Wie bei clustered Indexb. 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 TerminologieClustered 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 associatedtable, 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


Einführende TerminologiePrimä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 D1 1 a 502 2 c 603 1 b 50

rid1rid2rid3

Daten Records,Reihenfolge wie auf Platte

A B C D1 1 a 502 2 c 603 1 b 500

k rid_list1 {rid1, rid3}2 {rid2}

k rida rid1b rid3c rid2

Index Datei 1Index Datei 2 Index Datei 3

9


Index DatenstrukturenÜberblick

Wofür war doch gleich der Index?

• Wir erstellen einen Index, um effizient Daten Records auffinden zu können, indem wir

Die Indexstruktur effizient nach relevanten Dateneinträgen durchsuchen, und

Die gefundenen Dateneinträge nutzen, um die gesuchten Daten Records zu finden.

1

2

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)

2

Dateneinträge (sequence set)

DatenRecords

Indexstruktur, bestehend aus Indexeinträgen

1

Index Datei

Daten Datei

10


Kapitel 3Indizes





11


Index DatenstrukturenHash-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.

hSuchschlüssel k

h(k) = x

h(k) =y

h(k) =z

12


Hash-basierter Index für Anfrage 2

•Suchschlüssel = Gehalt•Hashfunktion h(Gehalt):

trunc-decimal(Gehalt/1000)• Index der Art (2)

Hash-basierter Index für Anfrage 1

•Suchschlüssel = Alter•Hashfunktion h(Alter):

trunc-decimal(Alter/10) • Index der Art (1)

Index DatenstrukturenBeispiel Hash-basierter Indexstrukturen

Name Alter Gehalt

Smith 44 3000

Basu 33 4003

Bristow 29 2007

Cass 50 5004

Tracy 45 5004

Jones 40 6003

Ashby 25 3000

Daniels 35 6005

Relationale Tabelle Mitarbeiter

14


Index DatenstrukturenBaum-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


Index DatenstrukturenBeispiel einer Baum-basierte Indexstruktur

Name Alter Gehalt

Smith 44 3000

Basu 33 4003

Bristow 29 2007

Cass 50 5004

Tracy 45 5004

Jones 40 6003

Ashby 25 3000

Daniels 35 6005

Ashby 25 3000

Bristow 29 2007

Basu 33 4003

Daniels 35 6005

Jones 40 6003

Smith 44 3000

Tracy 45 5004

Cass 50 5004 ......

Relationale Tabelle Mitarbeiter

Baum basierter IndexSuchschlüssel: AlterAnfrage: SELECT * FROM MitarbeiterWHERE Alter > 24 AND Alter < 50

Beginn der Suche nachAlter > 24

12 78

3 9 19 56 86 94

35 44... ... ... ... ... ...

Alter < 12

12 <= Alter < 78

Alter >= 78

16


Index DatenstrukturenB+ 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: 4 + 2 = 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 fh 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 log2 100.000.000 > 25 I/Os.

17


Kapitel 3Indizes





18


Datei Organisationen im VergleichKandidaten

• 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


Datei Organisationen im VergleichAufgaben (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 = 5000.

• 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 VergleichBewertung

• 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 Anzahl Daten Seiten, wenn Records lückenlos auf Seiten geschrieben werden.

R Anzahl Records pro Seite

D Durchschnittliche Zeit um eine Seite auf Platte zu schreiben bzw. von Platte zu lesen.

15 ms

CDurchschnittliche Zeit um ein Record im Hauptspeicher zu bearbeiten (z.B. Vergleich zwischen Feldinhalt und Konstante in Prädikat)

100 ns

H Zeit, um Hash Funktion auf ein Record anzuwenden.

100 ns

F Fan-out 100

21


(1) Jede der B Seiten muss in den Hauptspeicher!B*D

Datei Organisationen im VergleichKandidat 1: Heap Datei

......

Buffer Pool

Seiten in Heap File

(2) R Records pro Seite müssen bearbeitet werden!B*R*C

Gesamtkosten scan: B(D + RC)

equality & range search

22

scan


insertWir 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

Datei Organisationen im VergleichKandidat 1: Heap Datei

deleteSei r das zu löschende Record.

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


Datei Organisationen im VergleichKandidat 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



insert

Ashby 25 3000

Bristow 29 2007

Basu 33 4003

Daniels 35 6005

Jones 40 6003

Smith 44 3000

Tracy 45 5004

Cass 50 5004 ......

Sortierte Datei (Schlüssel = <Alter, Gehalt>

Ashby 37 4000Füge Record ein:

......

1 Finde Seite

2 Finde Position des Record auf Seite

3 Füge Record ein und verschiebe alle darauf Folgenden Records um eine Position.

Ashby 25 3000

Bristow 29 2007

Basu 33 4003

Daniels 35 6005

Jones 40 6003

Tracy 45 5004

Cass 50 5004

Ashby 37 4000

Smith 44 3000

25



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 VergleichKandidat 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



insert

12 78

3 9 19 56 86 94

35 44... ... ... ... ... ...

Alter < 12

12 <= Alter < 78

Alter >= 78

Ashby 25 3000

Bristow 29 2007

Basu 33 4003

Daniels 35 6005

Jones 40 6003

Smith 44 3000

Tracy 45 5004

Cass 50 5004

......

Seiten zu 67% gefüllt

Ashby 37 4000Füge Record ein:

1 Finde Seite

3Füge Record ein (Verschieben auf Folgeseitenwegen Seitenfüllgrads nur selten nötig)2

Finde Positiondes Record auf Seite

Ashby 37 4000

28



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


Datei Organisationen im VergleichKandidat 4: Heap Datei mit Unclustered B+ Baumindex

Dateneinträge

DatenRecords

Indexstruktur, bestehend aus Indexeinträgen

•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

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 (0.15 + R) + 2.005 BRC

30



equality search

range search

31


insert


Dateneinträge

DatenRecords1 Einfügen in Heap Datei

2D + C

2Finden des entsprechenden BlattknotensD logF 0.15 B + C log2 6.7R

3

Einfügen des Dateneintrags &auf Platte zurückschreibenD

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

! Gesamtkosten insert: 3D + C + D logF 0.15 B + C log2 6.7R

32


Datei Organisationen im VergleichKandidat 5: Heap Datei mit Unclustered Hash Index

hSuchschlüssel kh(k) = x

h(k) =y

h(k) =z

Seiten in einem Bucket zu 80% gefüllt

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) = 0.125 B.

• Anzahl Dateneinträge pro Indexseite = 10 (0.8 R) = 8R

scan

33


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


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


insert


Dateneinträge

DatenRecords1 Einfügen in Heap Datei

2D + C

2Finden des entsprechenden BlattknotensD logF 0.15 B + C log2 6.7R

3

Einfügen des Dateneintrags &auf Platte zurückschreibenD

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

! Gesamtkosten insert: 3D + C + D logF 0.15 B + C log2 6.7R

36


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

∀


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 VergleichZusammenfassung

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 BD log2 B

+#matching pagessearch + 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



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



Beispiel: Performance einer Bereichsanfrage bei wachsender Dateigröße.

0.01

0.1

1

10

100

1000

10000

10 100 1000 10000 100000

Zei

t (s

) bei

D =

0.0

15 s

Anzahl Seiten (B)

Heap File Sorted File

41



Beispiel: Performance einer Löschoperation bei wachsender Dateigröße, gegeben die zu löschende rid.

0.01

0.1

1

10

100

1000

10000

10 100 1000 10000 100000

Zei

t (s

) bei

D =

0.0

15 s

Anzahl Seiten (B)

Heap File Sorted File

42


Kapitel 3Indizes





43


Indizes und Performance Tuning

Wir haben soeben gesehen, dass keine Indexstruktur für alle Arten von Operationen geeignet ist.

!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).

Anfrage, die von effizienter Gleichheitssuche profitiert.

SELECT *FROM RWHERE C = 42

!Hash-basierter Index

Anfrage, die von effizienter Bereichssuche profitiert.

SELECT *FROM RWHERE A > 0 AND A < 100

!Baum-basierter Index

Anfrage, die von einer Sortierung der Records nach A profitiert.


!Clustered Index (sequentieller Zugriff)

44


Indizes und Performance TuningWorkload

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

Gewichtung 1 10 x pro Minute 100 x pro Minute !Baum-basierter Index

Gewichtung 2 10000 x pro Minute 1 x pro Minute !Hash-basierter Index

45


Indizes und Performance TuningStatistiken

•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

!Baum-basierter Index / Clustered IndexVerteilung 2

C = 42 in 95% aller Records

Nur 5 % aller Werte in A fallenzwischen 0 und 100

Verteilung 1C gleichverteiltvon 0 bis 100

A entspricht Altersverteilung !Hash-basierter Index

46


Indizes und Performance TuningDesignbeispiele für Clustered Indizes

Anfrage 1

SELECT M.AbteilungsNRFROM Mitarbeiter MWHERE 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 MWHERE M.Alter > 10GROUP 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


Indizes und Performance TuningDesignbeispiele für Clustered Indizes

Anfrage 3 (hohe Selektivität)

SELECT M.AbteilungsNR, COUNT(*)FROM Mitarbeiter MWHERE M.Alter > 60GROUP BY M.AbteilungsNR

Anfrage 4 (Selektion auf Schlüsselattribut)

SELECT M.AbteilungsNRFROM Mitarbeiter MWHERE M.PNR = 552

Wahl eines Index für Anfrage 3

Wahl eines Index für Anfrage 4

48


Indizes und Performance TuningZusammengesetzte 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.

•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.

Gleichheitsanfrage (Suchschlüssel = <Alter, Gehalt>)

SELECT * FROM MitarbeiterWHERE Alter = 30 AND Gehalt = 3000

Bereichsanfragen wenn Suchschlüssel <Alter, Gehalt>

SELECT * FROM MitarbeiterWHERE Alter = 20

SELECT * FROM MitarbeiterWHERE Alter < 20 AND Gehalt > 4000

50



Name Alter Gehalt

Bob 12 10

Cal 11 80

Joe 12 20

Sue 13 75

Daten Records

Welcher Index ist für die Anfrage Gehalt > 40 geeignet?

<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

<Alter>

<11, rid2>

<12, rid1>

<12, rid3>

<13, rid4>

<Gehalt>

<10, rid1>

<20, rid3>

<75, rid4>

<80, rid2>

Einfache Suchschlüssel

51



•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-IndexExistiert 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-IndexGegeben 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



•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 TuningDesignbeispiele für Indizes mit Zusammengesetztem Suchschlüssel

Anfrage 1

SELECT M.PNRFROM Mitarbeiter MWHERE M.Alter BETWEEN 20 AND 30AND M.Gehalt BETWEEN 3000 AND 5000

Anfrage 2

SELECT M.PNRFROM Mitarbeiter MWHERE M.Alter = 25AND 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



Anfrage 3

SELECT AVG(M.Gehalt)FROM Mitarbeiter MWHERE M.Alter = 25AND M.Gehalt BETWEEN 3000 AND 5000

Anfrage 4

SELECT M.AbteilungsNR, COUNT(*)FROM Mitarbeiter MWHERE M.Gehalt = 10000GROUP 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 = 10000 teuer.

• Analoge Diskussion für Index über Gehalt.

• Zusammengesetzter Index <Gehalt, AbteilungsNR>?

• Alle Dateneinträge mit Gehalt = 10000 im Index nebeneinander.

• Alle Dateneinträge mit Gehalt = 10000 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



Anfrage 5

SELECT M.AbteilungsNR, COUNT(*)FROM Mitarbeiter MWHERE M.Gehalt > 10000GROUP BY M.AbteilungsNR

Anfrage 6

SELECT M.AbteilungsNR, MIN(M.Gehalt)FROM Mitarbeiter MGROUP BY M.AbteilungsNR

Wahl eines Index für Anfrage 6Wahl eines Index für Anfrage 5

56


Indizes und Performance TuningToolbasierters 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

Introduction

Torsten Grust

Architecture of aDBMS

OrganizationalMatters

1.10

These Slides. . .

• . . . prepared/updated throughout the semester — watch outfor bugs and please let me know. Thanks.

• Posted to course web home on the day before the lecture —bring a printout and take notes.

Example

Open Issues/Questions

Take notes.

Code Snippets, Algorithms

IBMDB2 Specifics

If possible and insightful, discuss how IBMDB2 does things.




•Workload mit Ausführungsfrequenz (Gewicht einer Anfrage) werden spezifiziert.

58

Introduction

Torsten Grust



1.10

These Slides. . .



Example


Take notes.


IBMDB2 Specifics





•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

Introduction

Torsten Grust



1.10

These Slides. . .



Example


Take notes.


IBMDB2 Specifics



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

Documents

Preview of “03 indexing” - uni-tuebingen.de · 2018. 3. 9. · Struktur gespeichert. Die Seiten, die die Dateneinträge beinhalten sind die Blattknoten eines Baum-basierten Index