Automatische Erstellung von Soft-Indexen in PostgreSQL

Transkript

1 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Datenbanken und Informationssysteme DIPLOMARBEIT Automatische Erstellung von Soft-Indexen in PostgreSQL Karsten Schmidt Studiengang: Informatik Matrikelnummer: Technische Universität Ilmenau Ilmenau, den 10. Mai 2006 Betreuer: Prof. Dr.-Ing. habil. Kai-Uwe Sattler Inventarisierungsnummer: /IN99/2254

2 Danksagung An dieser Stelle möchte ich allen danken, die mir bei der Erstellung dieser Diplomarbeit geholfen habe. Ich danke meinem Betreuer Prof. Dr. Kai-Uwe Sattler für die Unterstützung und ständige Diskussionsbereitschaft während der Entwicklung dieses Werkes. Meinen Mitbewohnern und Freunden, im Besonderen Ralf Kästner und meiner Freundin Susanne Reitner, gebührt Dank dafür, mich immer aufgemuntert und unterstützt zu haben. Ich widme diese Arbeit meinen Eltern Klaus und Annelie Schmidt, die mir das Informatik Studium und damit auch diese Diplomarbeit erst ermöglicht haben.

3 Inhaltsverzeichnis Abbildungsverzeichnis 5 1. Einleitung Motivation Aufgabenstellung Aufbau Grundlagen der Indexauswahl und Nutzung Grundlagen zur Anfrageverarbeitung DBMS-Komponenten Operatoren Indexe Indexaufgaben Indexarten Indexnutzung Indexauswahl Kostenmodell Systemparameter Datenbankparameter und Kostenformeln Kostenberechnung Beispiel Zusammenfassung Einordnung und Abgrenzung Vorhandene Ansätze Index-Advisors QUIET Deferred Indexe Soft-Index-Einordnung Soft-Index-Komponenten Erweiterung Soft-Indexe Konzept und Anforderung Indexerzeugende Operatoren Indexbuilding-Scan Switch-Plan Kosten und Entscheidungsmodell Switch-Plan-Kosten Auswahl und Entscheidungsmodelle Regeln Karsten Schmidt, /IN99/2254

4 Inhaltsverzeichnis 5. Soft-Indexe in PostgreSQL Architektur von PostgreSQL Komponenten Baumstrukturen für die Verarbeitung Der Planner Der Executor Implementierung des Soft-Indexes Struktur der Soft-Index-Erweiterung Zusammenfassung Evaluierung Testumgebung TPC-H Datenbank-Schema Experimente Kategorie 1 - Korrektheit und Performance Kategorie 2 - Switch-Plan Anfragen Kategorie 3 - Simulation des Soft-Indexes Diskussion Zusammenfassung und Ausblick 88 A. Anhang 90 A.1. Explainausgabe für Nested-Loop-Join Anfrage auf den Relationen lineitem und orders A.2. Explainausgabe für Nested-Loop-Join Anfrage auf den Relationen part und partsupp A.3. Anfragen und Explainausgaben zum Vergleich der Festspeicherzugriffe A.3.1. Index p partkey A.3.2. deferred Index p partkey A.3.3. create Index ps partkey A.3.4. deferred Index ps partkey A.4. TPC-H Anfragen für Soft-Index-Simulation A.5. TPC-H Anfrage-Sets A.6. PostgreSQL compilieren und installieren A.6.1. Quelltext übersetzen A.6.2. Datenbank Initialisieren und Connecten A.6.3. TPC-H Datenbank installieren A.6.4. Steuerung des Switch-Plan-Operators Literaturverzeichnis 97 Karsten Schmidt, /IN99/2254

5 Abbildungsverzeichnis 2.1. Anfrageverarbeitung :1 Übersetzung der Anfrage in einen Operatorbaum Operatorbaum nach der algebraischen Optimierung Operatorbaum nach der physischen Optimierung Übersetzungsmöglichkeiten algebraischer Operatoren in physische Operatoren Bitmap-Index typisch dünn besetzter Bitmap-Index Vergleich zw. Balanciert und Nicht-Balancierten Bäumen Beispiel für ein B-Baum und ein B+ Baum verlinkte Blattseiten in einem B* Baum R-Baum mit nicht-disjunkten Knoten naiver Operatorbaum optimierter Operatorbaum indexgestützte Anfrage Sekundärspeicherzugriffe für Nested-Loop-, Merge- und Hash-Join Oracle s Index Wizard QUIET Architektur Soft-Index-Komponenten Soft-Index mit Switch-Plan Knoten und dem zugehörigen Unterbaum Soft-Index ersetzt mehrere Planoperatoren Iteratorschnittstelle des Switch-Plan-Operator Vergleich der Switch-Plan Varianten PostgreSQL - Struktur für die Anfrageverarbeitung Plan-Node Definition verkürzter PlanTree für die Beispielanfrage Quelltextstruktur des PostgreSQL-Backends Übersicht der Soft-Index-Erweiterung pg index Tabellenstruktur struct für den SeqScan Knoten struct für den IndexScan Knoten struct für den DynIndexScan Knoten Quelltextstruktur der Planner-Erweiterung Funktion cost index() Quelltextstruktur der Executor-Erweiterung struct für den DynIndexScanState Knoten Funktion ExecInitDynIndexScan() Funktion ExecProcNode() Version Funktion ExecProcNode() Version Funktion ExecEndNode() Version Karsten Schmidt, /IN99/2254

6 Abbildungsverzeichnis Funktion ExecEndNode() Version Das TPC-H Schema der Testdatenbank sequentielle Scans Zeit/Größe Index erstellen Zeit/Größe Indexbuilding-Scan vs. create Index Speicherzugriffe: CREATE INDEX vs. INDEXBUILDING SCAN Overhead des Indexbuilding-Scan bei Multi-Column Indexen Mehrere deferred Indexe gleichzeitig materialisieren Indexbuilding-Scan vs. parallel create Index Switch-Plan-Operator im UNION Statement Switch-Plan in Abhängigkeit der Subquery-Loops deferred Index l shipdate bei 600MHz deferred Index l shipdate bei 1300MHz deferred Index ps partkey bei 600MHz deferred Index ps partkey bei 1300MHz Kostenschätzung und Ausführungszeiten Diskzugriffe des Switch-Plan-Operators Diskzugriffe des Switch-Plan-Operators und Kostenschätzung Explain Ausgaben für den Nested-Loop-Anfrageteil Performance des Switch-Plan-Operators in TPC-H Anfrageserien Vergleich der Soft-Index-Testszenarien Karsten Schmidt, /IN99/2254

7 Abstract Der Durchsatz eines Datenbankmanagementsystems (DBMS) hängt von den Daten, der vorhandenen Hardware und den verwendeten Tuningmaßnahmen ab. Eine der bevorzugten Tuningmaßnahmen, zur Leistungssteigerung, ist das Indextuning. Aber gerade bei sich verändernden Datenbeständen und bei Platzbegrenzung sind dem unbegrenzten Indextuning Schranken gesetzt. Außerdem muss der Pflegeaufwand für die Aktualisierung der Indexe beachtet werden. Dazu kommt, dass die Bestimmung eines optimalen und platzbegrenzten Index-Sets für ein Anfrage-Set ein typisches NP-Problem darstellt. Es gibt heuristische Algorithmen zur Lösung des Index Selection Problem (ISP), doch diese Lösungsansätze werden kaum in das autonome Backend eines DBMS integriert. Als Ansatz zur Automatisierung des Indexmanagements, gibt es bereits die Soft-Indexe, welche durch das DBMS selbständig erstellt und verworfen werden. In dieser Arbeit wird die Idee der Soft-Indexe präsentiert und eine Erweiterung in Form eines Operators zur Indexerstellung vorgestellt. Für diesen Switch- Plan-Operator, welcher on-the-fly Indexe erstellen und benutzen kann, wird ein probates Kostenmodell, die nötigen Anpassungen des DBMS und eine Performanceanalyse vorgestellt. Performance in Database Management Systems (DBMS) majorly depends on the data, the hardware available and tuning approaches as applied to the system. Index tuning is one of the most popular approaches addressing the acceleration of query processing. Dynamic data sets and memory limits, however, constrain the success of index tuning methods. Moreover, maintenance costs arise from the necessity to keep indices up to date. Also, given a set of queries, determining an optimal and limited corresponding index set is known to be NP-complete. Heuristic algorithms solving the Index Selection Problem (ISP) exist, but are hardly found to be integrated into the autonomous backend of DBMSs. Soft Indices are an approach to the automation of index managament and are created and destroyed by the DBMS. This work presents the ideas behind soft indices and introduces a novel index building operator which creates and utilizes soft indices on-the-fly. A probate cost model for this so-called Switch-Plan operator will be proposed. It will be shown how the new operator can be integrated into an existing DBMS, and its performance will be evaluated. Karsten Schmidt, /IN99/2254

8 1. Einleitung 1.1. Motivation Wissen ist Macht - (17 Jh. Bacon Phil.). Schon im 17 Jh. wollte der Philosoph Francis Bacon königliche Gesetzestexte sammeln. Was ihm damals vom König verboten wurde, setzt sich in heutiger Zeit immer mehr durch. Der Bedarf an zu sammelnden Daten kennt anscheinend keine Grenzen mehr. Egal ob zur späteren Verarbeitung und Auswertung oder zum reinen Archivieren, das sich anhäufende Datenvolumen wird stetig größer. Die Verwaltung solcher riesigen Datenbestände wird immer schwieriger, genau wie das schnelle Finden von relevanten Informationen. Computergestützte Datenbanken bis hin zu sogenannten Datawarehouses (DWH), welche große Datenmengen effektiv verwalten, sind die Businesslösungen zur Datenhaltung, Verarbeitung und Analyse. Hier ist das relationale Datenmodell in Form von relationalen Datenbankmanagementsystemen (RDBMS) am weitesten verbreitet. Die Daten werden in zweidimensionalen Tabellen (Relationen) repräsentiert und über Schlüssel verknüpft. Speziell Datawarehouses wurden auf Basis solcher Datenbankmanagementsysteme (DBMS) entwickelt, um Daten zu sammeln und zu Analysezwecken zu verarbeiten. Dem entgegen stehen die transaktionsorientierten Systeme, zur effektiven Verarbeitung von Datenmanipulationen. Die Forderungen an heutige Datenbankmanagementsysteme sind ein hoher Durchsatz an Transaktionen und gleichzeitig niedrige Anwortzeiten für gestellte Anfragen. Es gibt viele Ansätze zur Steigerung der Leistung, dabei steht massives Hardwareaufrüsten konzeptionellen Ideen entgegen. Optimal ist die Kombination von beiden. Für das konzeptionielle Datenbanktuning ist es wichtig, ein Wissen über die Daten, die verwendeten Applikationen und die gestellten Anfragen zu besitzen. Da sich aber alle diese Parameter während der Benutzung eines optimierten Systems verändern können, sollte es möglich sein, auf solche Veränderung in kürzester Zeit effektiv zu reagieren. In dieser Arbeit geht es um die Möglichkeiten des Datenbankentunings und im Speziellen um das Indextuning. Indexe sind redundante Informationen über den Datenbestand und dessen physische Verteilung und werden zum schnellen Zugriff auf die Daten eingesetzt. Es obliegt dem Datenbankverwalter, anfrageunterstüzende Indexe zu definieren und zu erstellen. Das kostet nicht nur Zeit und Arbeit, sondern erfordert ein intensives Verständnis für die Arbeitsweise des DBMS, sowie Kenntnisse über die Datenbeschaffenheit und die zu erwartenden Anfragen. In kleineren Datenbanken ist eine manuelle Optimierung durchaus möglich, doch in größeren Systemen, wie z.b. SAP mit mehreren hundert Relationen (Tabellen) und mehreren gleichzeitig laufenden Anfragen, wird automatisierte Hilfe benötigt. Hilfe bieten Analyse-Tools zum Finden von durchsatzsteigernden Indexen. Diese Index- Wizards analysieren eine definierte Menge von Anfragen. Nach der Analyse geben sie einen Vorschlag für ein optimales Index-Set, basierend auf den Anfragen, wieder. Aus den Vorschlägen erstellte Indexe müssen, genau wie alle bestehenden Indexe, gepflegt werden. Das bedeutet bei Änderungen des Datenbestands muss auch die redundante Information des Indexes aktualisiert werden. Dies kostet Zeit und kann dazu führen, dass die Wartungskosten (Zeit) für einen Index den Gewinn (Zeitersparnis) bei der Verarbeitung der Anfrage überschreiten. Dazu kommt, dass der Index Platz verbraucht und bei Ressourcenknappheit eine Untermenge der empfohlenen Indexe auszuwählen wäre. Das sind nur einige Probleme, die Karsten Schmidt, /IN99/2254

9 1 Einleitung bei der Indexerstellung zu beachten sind. Aus der Dynamik und dem Platzverbrauch lassen sich die Herausforderungen für das Indextuning ableiten. In dieser Diplomarbeit wird das Konzept der Soft-Indexe vorgestellt, welches versucht, das Problem der Dynamik und zum Teil des Platzverbrauchs zu lösen. Dafür wird gezeigt, wie es mit automatisch erzeugten Soft-Indexen möglich ist, die Anfragebearbeitung zu verkürzen. Das DBMS soll hierbei selbständig entscheiden, ob es einen Indexkandidaten erstellt, indem es den Kostenunterschied für die Anfrageausführung mit und die Ausführung ohne den Index abschätzt. Es soll möglich sein, dass ein Index während der normalen Anfragebearbeitung erstellt und benutzt wird, ohne das ein Datenbankadministrator eingreifen muss. Ein wichtiges Ziel ist es, den Durchsatz des Systems zu erhöhen und nicht nur eine einzelne Anfrage zu beschleunigen. Dazu wird ein modifiziertes Kostenmodell erarbeitet sowie ein Operator der anfragebegleitend Indexe materialisiert. Dieses Kostenmodell und der neue Operator werden in das Backend des Open-Source-DBMS PostgreSQL implementiert. Anschließend soll der erwartete Vorteil des Operators durch geeignete Testszenarien evaluiert werden. Als Ergebnis wird ein Schritt zu selbst-optimierenden Datenbankmanagementsystemen erwartet Aufgabenstellung Ziel der Arbeit ist es, das Konzept des Soft-Indexes vorzustellen und einen passenden Datenbank- Operator zur Umsetzung zu entwickeln. Anschließend soll eine funktionierende Beispielimplementierung in PostgreSQL erarbeitet und getestet werden. Dabei soll auf dem Konzept der deferred Indexe, welches unter genauer erläutert wird, aufgebaut werden. Zum Abschluss müssen Regression- und Performancetests die korrekte Arbeitsweise des implementierten Operators zeigen Aufbau In diesem Kapitel wird die Problematik vorgestellt und ein Einstieg in die Welt der Datenbankoptimierung gegeben. Darauf folgt im 2. Kapitel eine Erläuterung der grundsätzlichen Datenbankmanagementkomponenten, der Indexstrukturen und des integrierten Kostenmodells. Nachdem die Grundlagen für diese Arbeit dargestellt wurden, beschäftigt sich das 3. Kapitel mit vorhandenen Ansätzen zur Lösung der Indexproblematik und zeigt auf, an welcher Stelle sich diese Arbeit einordnen lässt. Der eigentliche Hauptteil dieser Arbeit folgt in Kapitel 4 mit der Soft-Index-Theorie und dem neu entwickelten Switch-Plan-Operator, und dem Kapitel 5 mit der Umsetzung des Operators in PostgreSQL. Abschließend untersucht das 6. Kapitel die Funktionstauglichkeit der Implementierung, bevor im 7. Kapitel mit einem kurzen Fazit und Ausblick für Weiterentwicklungsmöglichkeiten die Arbeit abgeschlossen wird. Karsten Schmidt, /IN99/2254

10 2. Grundlagen der Indexauswahl und Nutzung Um den Einsatz von Indexen in einem DBMS zu verstehen, soll der Abschnitt 2.1 einen kurzen Einblick in die Arbeitsweise des DBMS geben. Dafür werden die wichtigsten Komponenten eines DBMS vorgestellt und deren Aufgaben im Hinblick auf die Indexe gezeigt. Der restliche Teil des Kapitels behandelt verschiedene Indexarten und die Nutzung der Indexe anhand eines gezeigten Kostenmodells. Die hier erarbeiteten Grundlagen und das Kostenmodell sind Ausgangspunkt für das Soft-Index-Konzept in Kapitel Grundlagen zur Anfrageverarbeitung DBMS-Komponenten Anfragen an ein DBMS werden aus Anwender-Sicht in einer Hochsprache wie SQL (Structured Query Language) gestellt. Dabei werden die Anfragen über bestimmte Keywords systematisch formuliert und vom DBMS autonom verarbeitet. Die Schritte der Verarbeitung sind in Abb. 2.1 dargestellt. Abbildung 2.1.: Anfrageverarbeitung Anhand eines Beispiels werden anschließend die einzelnen Schritte der Anfrageverarbeitung gezeigt. Hierzu werden der Parser und der Optimierer als DBMS-Komponenten sowie die Operatoren, Iteratoren und die Zugriffsmethoden als Hilfsmittel zur Anfragebearbeitung vorgestellt. Karsten Schmidt, /IN99/2254

11 2 Grundlagen der Indexauswahl und Nutzung Beispiel Zum besseren Verständnis werden die einzelnen Abarbeitungsschritte des DBMS mit Hilfe einer geeigneten Beispielanfrage gezeigt. Angenommen, es gibt 2 Relationen,,Mitarbeiter und,,abteilung in einer Datenbank: (Mitarbeiter wird durch M, und Abteilung durch A verkürzt geschrieben) M Name Geschlecht AbtID A ID Lokation AbtName Müller m 1 Schulz w 1 Feldmann m 2 Maier m 4 1 Europa Vertrieb 2 Amerika Einkauf 3 Europa Forschung 4 Asien Support Auf diesen Relationen soll eine SQL-Anfrage ausgeführt werden, die die Namen der männlichen Mitarbeiter und die zugehörigen Abteilungsnamen ausgibt, welche sich in Europa befinden. Die dazu passende SQL-Anfrage sieht folgendermaßen aus: SELECT Name,AbtName FROM Mitarbeiter AS m,abteilung AS a WHERE m.geschlecht = m AND a.lokation = Europa AND m.abtid = a.id Als Ergebnis liefert die Anfrage auf der Beispieldatenbank folgendes: Name Müller AbtName Vertrieb Parser Zu Beginn der Anfrageverarbeitung wird die syntaktische Korrektheit der Anfrage durch den Parser gewährleistet. Der Parser kann dabei einfache Ersetzungen (Auflösen von Views 1 ) vornehmen, die Anfrage gegen das Data Dictonary 2 validieren und die Existenz aller referenzierten Objekte überprüfen. In diesem Schritt wird die Anfrage gescannt und in eine interne Form übersetzt. Diese interne Form besteht aus algebraischen Ausdrücken und sieht für die Beispielanfrage folgendermaßen aus: π Name,AbtName (σ (M.Geschlecht=m A.Lokation=Europa M.AbtID=A.ID) (M A)) Der SELECT -Ausdruck findet sich in dem Projektionssymbol (π) wieder, die W HERE- Klauseln werden durch die Selektion (σ) ausgedrückt und der Verbund über die 2 Relationen - F ROM - durch das Kreuzprodukt ( ) dargestellt. Optimierer Der Optimierer benötigt zur internen Repräsentation des algebraischen Ausdrucks eine andere Darstellungsform. Deshalb wird die Anfrage von dem Parser in Form eines Operatorbaums an die nachfolgende Optimierer-Komponente übergeben. Der zur Beispielanfrage passende Operatorbaum wird in Abb. 2.2 gezeigt. Dabei stellt der Operatorbaum eine algebraische Baumstruktur dar, wobei die Knoten des Baums die Operatoren und die Blätter die Operanden repräsentieren. Der Datenfluss zwischen den Knoten 1 Views bieten eine Sicht auf die Daten und können dabei Bedingungen prüfen. 2 Diese Meta-Daten beschreiben die Struktur der hinterlegten Daten / Datenbank. Karsten Schmidt, /IN99/2254

12 2 Grundlagen der Indexauswahl und Nutzung π Name,AbtName σ (M.Geschlecht=m A.Lokation=Europa M.AbtID=A.ID) M itarbeiter(m) Abteilung(A) Abbildung 2.2.: 1:1 Übersetzung der Anfrage in einen Operatorbaum wird durch die Kanten symbolisiert. Die Abbildung zeigt, dass die Eingangsrelationen M und A der Beispielanfrage sich in den Blättern des Baums befinden. Dagegen werden die Verarbeitungsschritte (Verbund und Selektion) in den inneren Knoten des Baums abgebildet. Die Projektion des Ergebnisses, als finaler Operator in der Verarbeitungskette, geschieht zuletzt und befindet sich dementsprechend in der Wurzel des Baums. Der Optimierer arbeitet typischerweise in 3 Schritten, welche folgend einzeln dargestellt werden: algebraischer Optimierer Bei der sogenannten High-Level-Optimierung werden syntaktische Umformungen und Termersetzungen auf dem Anfrageausdruck ausgeführt. Umformungen und Ersetzungen erfolgen nach einem vorgegebenen Regelsatz und basieren auf der relationalen Algebra. Der algebraische Optimierer ist unabhängig von Datenbankinformationen wie Relationsgröße, Selektivität oder dem zugrundeliegenden Speichermodell. Mit Hilfe einer Hochsprache (z.b. SQL) oder einer deklarativen Sprache lässt sich die Arbeitsweise des algebraischen Optimierers beeinflussen. Für die Beispielanfrage werden die Selektionen nach unten verschoben, denn dadurch werden die Zwischenergebnisse verringert und ein Kreuzprodukt der Relationen M und A vermieden. Der resultierende algebraisch optimierte Operatorbaum wird in der Abb. 2.3 gezeigt. Somit bedarf es nur noch eines Verbundes der bereits selektierten Eingangsrelationen. π Name,AbtName Mitarbeiter.AbtID=Abteilung.ID σ (M.Geschlecht=m) σ (A.Lokation=Europa) M itarbeiter(m) Abteilung(A) Abbildung 2.3.: Operatorbaum nach der algebraischen Optimierung physischer Optimierer Beginnend mit dem ersten Teil der sogenannten Low-Level-Optimierung werden in diesem Schritt die konkreten Speicher- und Zugriffstechniken (Indexe, Cluster, Scans) mit Hilfe des DD (Data Dictonary) evaluiert, um sie in semantisch äquivalenten Anfrageplänen verwenden zu können. Deshalb übersetzt der physische Optimierer die algebraischen Operatoren in verschiedene Implementierungsalternativen (physische Operatoren) und gibt die entstehenden Zugriffspläne an den zweiten Teil der Low-Level- Optimierung, dem kostenbasierten Optimierer, weiter. Karsten Schmidt, /IN99/2254

13 2 Grundlagen der Indexauswahl und Nutzung Die Abbildung 2.4 zeigt den physisch optimierten Operatorbaum der Beispielanfrage. Voraussetzung für das Beispiel sind die Indexe auf dem Attribut Geschlecht der Relation Mitarbeiter und dem Attribut ID der Relation Abteilung. Aufgrund dieser Indexe können sogenannte Relationen-Scans vermieden, und statt dessen ein Verbund mit Indexnutzung angewendet werden. Die doppelten Kanten des Graphen symbolisieren das Pipelining (durchreichen) der Tupel. Dieses platzsparende Pipelining wird bis auf den rechten Teil des Verbunds überall im Operatorbaum angewendet. π Name,AbtName σ (Abteilung.Lokation=Europa) Mitarbeiter.AbtID=Abteilung.ID σ (Mitarbeiter.Geschlecht=m) σ(id=outer.id) index M itarbeiter Abteilung Abbildung 2.4.: Operatorbaum nach der physischen Optimierung kostenbasierte Optimierer Um eine Entscheidung treffen zu können, welcher der Zugriffspläne am effektivsten (preiswertesten) ist und ausgewählt werden soll, schätzt der kostenbasierte Optimierer für jeden Plan die Kosten und vergleicht diese. Die Schwierigkeiten der Optimierung liegen in der Komplexität der Anfragen und entstehen beim Schätzen der Kosten. Für komplexe Anfragen, sei es durch viele Relationen die miteinander verbunden werden müssen, gibt es zu viele verschiedene Anfragepläne, als dass alle Varianten betrachtet werden können. Deshalb grenzen heutige Verfahren frühzeitig die Suche nach dem optimalen Plan ein. Die Beschränkung des Suchraums und das Kostenschätzen haben einen gewissen Fehler zur Folge, welcher nur durch unterstützende Statistiken und Heuristiken minimiert werden kann. Executor Der durch den Optimierer erstellte Ausführungsplan QEP (Query Execution Plan) wird vom Executor abgearbeitet. Während der Abarbeitung des QEP nimmt der Executor keinen Einfluss mehr auf die Planstruktur, sondern arbeitet sie konsequent ab. Somit hängt die Performance des Executors, und damit des gesamten DBMS, fast ausschließlich von der Qualität der optimierenden Komponente ab. Nachdem der Executor die Anfrage bearbeitet hat, gibt er das Ergebnis der Anfrage an den Anwender oder die Anwendung zurück und beendet die Verarbeitungspipeline für diese Anfrage Operatoren Im Abschnitt wurden die Optimierer als Komponente zum Übersetzen des algebraischen Anfrageausdrucks in äquivalente Zugriffspläne vorgestellt. Um die Soft-Indexe später erklären zu können, werden an dieser Stelle die logischen und physischen Operatoren und deren Übersetzung behandelt. Karsten Schmidt, /IN99/2254

14 2 Grundlagen der Indexauswahl und Nutzung Nachdem der Parser die Anfrage in einen Operatorbaum übersetzt hat, müssen die Join-, Selektions- σ und Projektions- π Operatoren vom physischen Optimierer in äquivalente physische Operatoren übersetzt werden. Die physischen Operatoren stellen Implementierungen dar, um auf die Relationen der Datenbank oder auf Zwischenergebnisse, die während der Anfrageverarbeitung entstehen, zugreifen zu können. Die Scan-Methoden zum Einlesen einer Relation werden auch Zugriffsmethoden genannt. Dabei kann es zu einem logischen Operator mehrere physische Operatoren geben, siehe Übersicht 2.5 für die Selektion, die Projektion und die Verbundoperation. Im Gegensatz dazu gibt es nicht zu jedem physischen Operator einen logisch äquivalenten Operator, wie z.b. für die Sortierung und die Indexerstellung. algebraischer Operator σ p (R) π l (R) physischer Operator σ Scan (R) σ Index (R) π Scan (R) mit Duplikateliminierung π Scan (R) ohne Duplikateliminierung p (R1, R2) NestedLoop (R1, R2) NestedLoop (R2, R1) Merge (R1, R2), R1 und R2 liegen sortiert vor Index (R1, R2) auf R1.p liegt ein Index Hash (R1, R2) Abbildung 2.5.: Übersetzungsmöglichkeiten algebraischer Operatoren in physische Operatoren Während die Anfrage bearbeitet wird und die einzelnen Knoten des Operatorbaums abgearbeitet werden, fallen in den inneren Knoten Zwischenergebnisse an. Dabei entsteht ein Problem, wenn große Zwischenergebnisse, die z.b. noch durch eine Verbundoperation oder Projektion weiterverarbeitet und dabei auch verkleinert werden, zwischengespeichert werden müssten. Dieser Aufwand des Speicherns und Wiedereinlesens zur Weitergabe an den nächsthöheren Operator im Baum wird durch die sogenannten Iteratoren reduziert. Hierzu folgt ein kurzer Überblick über die Funktionsweise von Iteratoren und Iteratorbäumen. Iteratoren und Iteratorbäume Die Iteratoren in den Knoten des Operatorbaums können die Ergebnisse des eigenen Knotens direkt an den nächsten Knoten weiterleiten (pipen). Dabei werden die Tupel einzeln weitergereicht und es brauchen keine kompletten Relationen (Zwischenergebnisse) gespeichert zu werden. Das funktioniert nur mit Operatoren, die eine tupelweise Weitergabe des Ergebnisses unterstützen. Ein (reiner) Sortierungsoperator kann diese Technik nicht nutzen, da die Tupel erst sortiert werden müssen bevor sie weitergegeben werden können. Und trotzdem wird der Operator als Iterator implementiert, um konforme Schnittstellen zwischen den Knoten im Operatorbaum zu gewährleisten. Das heißt, dass nach außen hin der Sortierungsknoten wie ein Iterator arbeitet, indem er blockierend das Ergebnis berechnet und hinterher tupelweise weitergeben kann, ohne das dabei das Konzept zum pipen von Tupeln genutzt wird. Um tupelweise arbeiten zu können, unterstützen die Iteratoren 3 Grundfunktionen : ˆ open - öffnet einen Iterator und bereitet ihn zum Lesen der Tupel vor ˆ next - fordert das nächste Tupel an Karsten Schmidt, /IN99/2254

15 2 Grundlagen der Indexauswahl und Nutzung ˆ close - schließt den Iterator, wenn keine weiteren Tupel gefordert werden Durch die Verwendung der Iteratoren werden die einzelnen Tupel wie auf einer Kette durch den Baum gereicht. Jeder Operator wartet bis sein aktuelles Ausgabetupel angefordert wird, bevor er das nächste Ausgabetupel aus seinen Eingangstupeln berechnet. Zugriffsmethoden Unter den Zugriffsmethoden werden die physischen Zugriffe auf die Basisrelationen (Tabellen) der Anfrage verstanden. Im Operatorbaum werden die Basisrelationen als Operanden in den Blättern abgebildet. Dabei unterteilen sich die Zugriffsmethoden in 3 Bereiche: die Scan- Methoden, die Mengen-Operatoren und die Verbund-Methoden. Die Scan-Methoden arbeiten auf einer Relation, entweder als sequentieller Scan oder als Index-Scan. Angewendet werden die Scans bei der Selektion σ und der Projektion π. 1. Bei einem sequentiellen Scan werden alle Diskseiten des Files, in dem die Relation gespeichert ist, eingelesen und verarbeitet. 2. Dagegen wird bei einem Index-Scan immer erst im Index nach der referenzierten Diskseite der Basisrelation gesucht und diese Diskseite anschließend gelesen. Deshalb wird dieses Zugriffsverfahren auch als willkürlicher Zugriff auf die Diskseiten bezeichnet, denn es gibt keinen physisch geordneten Zugriff, sondern einen logisch geordneten. An dieser Stelle fällt auf, dass bei einer Anfrage der Form SELECT F ROM R W HERE ϕ wobei das ϕ das Ergebnis einschränkt, die beiden Scan-Methoden unterschiedlichen Aufwand betreiben müssen. Genauer wird dieser Sachverhalt im Abschnitt 2.4 erläutert. Hinweis: Der Soft-Index-Operator in Kapitel 4 baut auf beiden Scan-Methoden auf. Die Verbund-Methoden (auch Joins genannt) verknüpfen 2 Relationen 3 miteinander und erzeugen eine Ausgaberelation. Dabei werden Tupel der Eingaberelationen verbunden, wenn das Joinprädikat auf die beteiligten Tupel passt. Das Joinprädikat steht für die logische Verknüpfung der Relationen auf Attributebene. So verbindet z.b. ein Prädikat W HERE R.A = S.B auf den Relationen R und S alle Tupelpaare, in denen der Wert des Attributs A (A R) und der Wert des Attributs B (B S) gleich sind. Das Kreuzprodukt stellt eine besondere Form dar, bei der das Verbundprädikat true ist und somit alle möglichen Tupelpaarungen gebildet werden müssen. Abhängig von der Verbundart sind verschiedene Verbund-Methoden anwendbar. Für einen Gleichheitsverbund (Equi-Join) können die Nested-Loop-Joins, die Index-Nested-Loop-Joins, die Merge-Joins und die Hash- Joins verwendet werden. Dagegen kann bei einem Ungleichheitsverbund (Non-Equi- Join) nicht auf einen Hash-Join zurückgegriffen werden. Anderereits unterstützt nur der Nested-Loop-Join uneingeschränkt den Intervallverbund und macht ihn so zur universellsten Join-Methode. Hierzu eine kurze Übersicht über die Funktionsweisen der einzelnen Verbund-Methoden: 3 Bei Joins über mehr als 2 Relationen, lässt sich der Verbund auf Joins mit 2 Relationen zurückzuführen, indem das Ergebnis eines Joins mit der nächsten Relation verbunden wird usw. Karsten Schmidt, /IN99/2254

16 2 Grundlagen der Indexauswahl und Nutzung ˆ Um 2 Relationen miteinander zu verbinden, bietet sich als erstes die Nested- Loop-Join (geschachtelte Schleifen) Variante an. Dabei durchläuft die äußere Schleife alle Seiten b der äußeren Relation R, und für jede Seite b R R erfolgt ein vollständiger, seitenweiser sequentieller Scan der inneren Relation S. Für jede Seite aus R und S werden alle Tupelkombinationen gebildet und bei Erfüllen der Joinbedingung, zusammengesetzt und zurückgegeben. Dieser Algorithmus kann verbessert werden, indem die Tupel blockweise verglichen werden. ˆ Ein Index-Nested-Loop-Join kann angewendet werden, wenn mindestens ein Joinattribut von einer oder beiden Eingangsrelationen indiziert vorliegt. Dafür wird die indizierte Relation zur inneren Relation S deklariert, und für jedes Tupel aus R wird nach Verbundpartnern (Jointupel) in S unter Benutzung des Indexes gesucht. Dadurch wird nicht mehr das vollständige kartesische Produkt verglichen, sondern nur Teile aus der inneren Relation S. Es gibt auch Situationen, in denen die indizierte Relation als äußere Relation R benutzt wird, z.b. wenn die 2. Relation komplett in den Arbeitsspeicher passt und somit nur einmal per sequentiellen Scan gelesen werden muss. ˆ Für den Gleichheitsverbund oder den natürlichen Verbund kann der Merge-Join oder Sort-Merge-Join angewendet werden. Dabei ist es nötig, dass im Falle des Merge-Joins die beteiligten Relationen vorsortiert vorliegen. Ist das nicht der Fall, muss vorab die nicht sortierte(n) Relation(en) nach dem Verbundattribut X sortiert werden (Sort-Merge-Join). Das Mischen (Merge) der Relationen R und S funktioniert folgendermaßen: Beide Relationen werden parallel und in der gleichen Richtung durchlaufen. Falls das Tupel t R aus R, für die Joinbedingung X, kleiner ist als das Tupel t S aus S, so wird das nächste Tupel t R aus R gelesen. Das gleiche gilt auch für die Relation S, wenn t S (X) < t R (X) wird das nächste Tupel t S aus S gelesen. Wenn t R (X) = t S (X) werden die Tupel verbunden, das gilt auch für alle Nachfolger aus t R und t S mit dem selben Wert t R (X). Zusätzlich gilt für den (Sort-)Merge-Join, dass wenn mindestens eine der Relationen sortiert vorliegt, er sich als sehr effizient erweist. Die Anzahl der Vergleichsoperationen (Joinpaare) hängt von der Datenverteilung der jeweiligen Joinattribute ab. Genauer wird das im Kostenmodell (Abschnitt 2.4) beschrieben. ˆ Wiederum nur für den Gleichheitsverbund geeignet sind die Hash-Joins. Der Hash-Join verwendet eine dynamisch aufgebaute Hashtabelle zum schnellen Finden von Joinpartnern. Dafür wird die kleinere Relation mit Hilfe einer Hashfunktion in eine Hashtabelle geschrieben, und die 2. Relation sucht für jedes Tupel mit der gleichen Hashfunktion nach einem Joinpartner im entsprechenden Hash- Bucket. Falls die kleinere Relation nicht komplett in den Arbeitsspeicher passt, wird sie in Partitionen unterteilt und für jede Partition der Hash-Join durchgeführt. Zu den Mengen-Operatoren zählen das Produkt, die Differenz, die Vereinigung und der Durchschnitt. Alle diese Operatoren sind auf Verbundoperationen (Verbund-Methoden) zurückzuführen und setzen das gleiche Schema der Eingaberelationen voraus. Quelle : [Sch04] Karsten Schmidt, /IN99/2254

17 2 Grundlagen der Indexauswahl und Nutzung Zusammenfassung In diesem Abschnitt wurden die wichtigsten Komponenten eines DBMS und deren Verarbeitungsreihenfolge vorgestellt. Die Beispielanfrage wurde vom Parser in einen algebraischen Ausdruck übersetzt und anschließend vom Optimierer zu einem QEP, passend für den Executor, übersetzt und optimiert. Dabei wurde ersichtlich, welchen Anteil die Anfrageplanung im Kontext von Datenbankmanagementsystemen einnimmt. Genauer wird die Anfrageplanung im Abschnitt 2.4 mit einer Einführung in die Kostenberechnung für Anfragepläne untersucht. Damit wird gleichzeitig die Grundlage für das Kapitel 4 Soft-Indexe geschaffen. Karsten Schmidt, /IN99/2254

18 2 Grundlagen der Indexauswahl und Nutzung 2.2. Indexe Indexaufgaben Der Durchsatz 4 der Datenbank soll, durch den Index-Einsatz in einem DBMS, erhöht werden. Dabei nutzt der Datenbankserver die Indexe aus, um Anfragen zu beantworten und zu bearbeiten. Allein für das lineare Durchsuchen (Full-Table-Scan) einer 10GB großen Relation würde es bei einer Lesegeschwindigkeit von 20MB/s über 8 Minuten dauern, die gesamte Relation abzusuchen. Typischerweise sind nur ein geringer Teil der Daten für eine Anfrage interessant, und mit Hilfe von Indexstrukturen muss auch nur dieser Bruchteil der Relation gelesen werden. Indexe einer Datenbank sind vergleichbar mit dem Stichwortverzeichnis eines Buches. Der Index (Stichwortverzeichnis) erleichtert es dem Leser, die gewünschten Informationen zu finden, indem er direkt zu der referenzierten Seite springen kann. Dieses Prinzip entspricht im Datenbankkontext der Indexnutzung. Wenn es geeignete Indexe mit direkten Sprungadressen gibt, ist es nicht nötig, dass das DBMS die gesamte Relation durchsucht. Weiterhin bieten Indexe Vorteile beim Joinen, Aggregieren und für die Überprüfung von Selektionsbedingungen. Abhängig von der Art des Indexes ergeben sich unter Umständen auch Vorteile für Bereichsanfragen und für geschachtelte Anfragen. Es gibt aber auch Nachteile bei der Verwendung von Indexen in einem DBMS. Zum einen werden Indexe im persistenten Speicher abgelegt und verbrauchen Platz, und zum anderen müssen sie durch das DBMS gepflegt werden. Sobald sich der Datenbestand durch Update-, Delete- oder Insert- 5 Anfragen ändert, müssen relevante Indexe aktualisiert werden. In transaktionslastigen DBMS-Umgebungen kann sich dieser Pflegebedarf durchaus negativ auswirken, wenn die für Abfragen typische Performancesteigerung durch einen höheren Pflegeaufwand des Indexes egalisiert wird. Dem entgegen stehen die DBMS, welche vorrangig für Abfragen und Analysen des Datenbestandes genutzt werden. Durch die verhältnismäßig geringe Anzahl an Datenänderungen kann der Pflege- und Platzbedarf als Kostenfaktor für die Anfrageverarbeitung deutlich geringer eingestuft werden. Das Szenario einer reinen Abfrage- Datenbank stellen zumeist die Datawarehouses dar. Diese Datensammelstellen bekommen fast ausschließlich Informationen hinzugefügt und unterliegen nur geringen Modifikationen bestehender Daten. Reale Anwendungen erreichen heutzutage Datenbestände im Terrabyte Bereich. Hier kann kein onlinefähiges Tool in vertretbarer Zeit den Datenbestand nach einem bestimmten Schlüssel parsen und filtern. Deshalb werden Indexe als Hilfsstrukturen zum schnellen direkten Zugriff eingesetzt. Während der Anfragebearbeitung erkennt das DBMS selbständig ob es die Datenbasis scannen soll oder ob die Benutzung eines vorhandenen Indexes schneller ist. Somit bilden Indexe eine parallele Schnittstelle zu den Daten und enthalten ausschließlich redundante Informationen. Sie bringen deshalb keinen Informationsgewinn und müssen zusätzlich aus Konsistenzgründen aktuell gehalten werden Indexarten Entsprechend der Verwendung, der Datenverteilung und des Datentyps der zu indizierenden Tupel gibt es verschiedene Indexarten. Denn es eignet sich nicht jede Indexart für jeden 4 Darunter wird die Anzahl an Transaktionen/Anfragen welche in einer bestimmten Zeit bearbeitet werden können verstanden. 5 Die Befehle Update, Delete und Insert gehören zu der DML - Data Modification Language und werden zum verändern der Daten benötigt. Karsten Schmidt, /IN99/2254

19 2 Grundlagen der Indexauswahl und Nutzung Datentyp. Dazu soll dieser Abschnitt eine Übersicht über die in heutigen DBMS Systemen am häufigsten eingesetzten Indexarten geben. Bitmap-Index Die Bitmap-Indexe (BI) repräsentieren die Attributwerte des Indexes in Bit-Listen (Bitmaps). Für jeden Attributwert wird ein Array von Bits reserviert. Dabei entspricht die Länge des Arrays der Zeilenanzahl der zugehörigen Relation. Das Bit in dem Array, welches den Wert des Tupelattributs repräsentiert, wird auf 1 gesetzt und alle anderen Bits in der Zeile auf 0. (NULL-Werte werden durch ein eigenes Bit dargestellt). Person Marcus Dieter Maria Claus Claudia Geschlecht m m w m w = Person m w Marcus 1 0 Dieter 1 0 Maria 0 1 Claus 1 0 Claudia 0 1 Abbildung 2.6.: einfacher Bitmap-Index In der Abbildung 2.6 wird beispielhaft ein Bitmap-Index für das Attribut Geschlecht gezeigt. Dabei werden alle möglichen Attributwerte m und w in eigenen Bitmaps dargestellt (rechts). Der Vorteil der Bitmaps liegt in dem geringen Speicherplatzverbrauch und der Möglichkeit zur einfachen Filterung nach bestimmten Attributwert(en). Weiterhin können die Bitmaps mit einander per AND und OR verknüpft werden. Durch die logischen Operationen ist ein Bitmap-Index effektiv beim Joinen und beim Prüfen auf Selektionsbedingungen einsetzbar. Die Effektivität der Bitmap-Indexe hängt von der Ausprägung des Attributs ab. Denn da für jeden Wert eine Bitmap reserviert werden muss, steigt mit der Anzahl verschiedener Attributwerte auch die Anzahl der Bitmaps. Diese Bitmaps verbrauchen Speicherplatz, können nicht effizient verändert werden und sind, wie die Abbildung 2.7 zeigt, zumeist dünn besetzt. Das heißt, bei einem Index mit mehr als 2 Bitmaps für ein Attribut überwiegt der Anteil an Nullwerten. ID BM 1 BM 2 BM 3 BM Abbildung 2.7.: typisch dünn besetzter Bitmap-Index Es gibt einige Techniken, die versuchen diese Probleme der Bitmap-Indexe zu kompensieren. Dazu zählen die Mehrkomponenten-Indexe, die Runlength-Compression und Bereichskodiertenoder Intervallkodierten-Bitmap-Indexe. Für weitere Informationen und Optimierungsmöglichkeiten der Bitmap-Indexe sei auf die Literatur verwiesen. Zusammenfassend sind Bitmap-Indexe für Punktanfragen und bei mehrdimensionaler Benutzung vorteilhaft. Schwächen dagegen gibt es beim Pflegeaufwand und den Kosten zur Berechnung der Kodierung/Dekodierung. Dazu kommt, dass Bitmap-Indexe bei zunehmender Kardinalität der Attribute an Komplexität gewinnen und an Performance verlieren. Karsten Schmidt, /IN99/2254

20 2 Grundlagen der Indexauswahl und Nutzung Abbildung 2.8.: Vergleich zw. Balanciert und Nicht-Balancierten Bäumen Baumbasierte Indexstrukturen Alle auf einer Baumstruktur basierenden Indexe sind vom Aufbau her ähnlich. Die meisten Varianten basieren auf den B-Bäumen und sind von diesen abgeleitet. Der B-Baum selber ist eine Verallgemeinerung des binären balancierten Suchbaums [BM]. Diese Strukturen eignen sich insbesondere zum Zugriff auf Basisrelationen in einem DBMS und werden im Folgenden genauer betrachtet. Für schnelle Zugriffe sorgt die Eigenschaft, dass ein B-Baum balanciert ist. Das bedeutet, die Tiefe (auch Höhe) bzw. Pfadlänge des Baums ist von der Wurzel zu allen Blättern gleich. Damit gibt es keine langen und kurzen, sondern nur gleichlange Suchpfade. (siehe Abb. 2.8) Darüber hinaus gibt es domänenspezifische Baumstrukturen, wie den R-Baum oder den KdB-Baum, um noch 2 weitere Varianten aufzuzeigen. B-Bäume Quelle : [HR01] Neben dem einfachen B-Baum (siehe Abb.2.9 links), welcher die Daten direkt in den Knoten und Blättern speichert, gibt es noch den B+ Baum. Der B+ Baum (siehe Abb. 2.9 rechts) beinhaltet in den inneren Knoten ausschließlich Zeiger zu tiefer gelegenen Knoten oder Blättern, die zum Routen benutzt werden. Dafür liegen die Daten (bzw. Zeiger zu den Datenzeilen) ausschließlich in den Blattknoten. Es ist sehr aufwendig, von einem Blatt zum nächsten Blatt (durch Ordnungsrelation das logisch nächste Blatt) zu kommen, da der Baum hierfür aufwärts und wieder abwärts traversiert werden muss. Zur Lösung dieses Problems gibt es noch den B* Baum (siehe Abb.2.10), welcher die Blattknoten untereinander mit Zeigern verknüpft. Dadurch sind Bereichssuchen beginnend am oberen oder unteren Ende des Bereichs mit einem sequentiellen Zugriff möglich. Für ein DBMS gilt der B* Baum-Index als universeller Standardtyp und ist ordnungs- und verteilungsabhängig. Das bedeutet, die zu indizierenden Werte müssen bezüglich einer Ordnungsfunktion z.b.,,< oder,,>, einer Reihenfolge unterliegen. Die Verteilungsabhängigkeit bezieht sich darauf, wie effektiv ein B* Baum arbeitet. Eine genauere Analyse der B-Baumstruktur umfasst das Kapital 2.4 auf Seite 26. Aufbau Eigenschaften des B-Baum der Ordnung k (nach Beyer/McCreight 1972): Karsten Schmidt, /IN99/2254

21 2 Grundlagen der Indexauswahl und Nutzung Abbildung 2.9.: Beispiel für ein B-Baum und ein B+ Baum Abbildung 2.10.: verlinkte Blattseiten in einem B* Baum ˆ Die Wurzel hat mindestens 2 Kind-Knoten oder ist selber einziger Blattknoten. ˆ Je Knoten gibt es maximal 2k Elemente und mindestens k Elemente, außer in der Wurzel. ˆ Bis auf die Wurzel und die Blätter hat jeder Knoten mindestens k Kind-Knoten oder Blattknoten. ˆ Alle Blätter befinden sich auf einer Ebene. ˆ Jeder innere Knoten mit n Kind-Knoten besitzt n 1 Elemente. ˆ Maximal log k (Elemente) Zugriffe sind nötig, also O(log k (n)) (Pfad) für das Suchen, das Löschen und das Einfügen in einem B-Baum für n Elemente. ˆ Der B-Baum ist balanciert (beim Löschen und Einfügen evtl. rebalancieren nötig). ˆ Er garantiert einen Füllfaktor von mind. 50%. Quelle : [KE01, Seite 207f] Speziell für Datawarehouses lohnt es sich, einen hohen Füllfaktor anzugeben/zu fordern, da es hier nicht nötig ist, Platz für Indexänderungen zu reservieren. Zum einen reduziert das den Platzverbrauch des Indexes, und zum anderen benötigen die Zugriffe minimale Pfadund Lesekosten. Falls ein B-Baum basierter Index in einer sich ständig ändernden Datenbank zum Einsatz kommt, ist es vorteilhaft, freie Kapazitäten im Baum zu haben. Damit wird die Häufigkeit für Split- und Merge-Operationen, sobald eine Seite überläuft 6 oder unterläuft 7, verringert. 6 Blattseite beim Einfügen von neuen Elementen überfüllt 7 Blattseite fällt unter die 50% Füllmarke beim Entfernen von Elementen Karsten Schmidt, /IN99/2254

22 2 Grundlagen der Indexauswahl und Nutzung Abbildung 2.11.: R-Baum mit nicht-disjunkten Knoten R-Bäume Der R-Baum z.b. wird für das Indizieren von geometrischen Objekten eingesetzt. Denn er eignet sich um mehrdimensionale Datenstrukturen abzubilden. Die Wurzel und jeder Knoten des Baums umfassen dabei alle darunterliegenden Knoten und Objektzeiger minimum bounding box. Bei d-dimensionalen Daten hat jedes Blatt außer der Wurzel [d + 1 <= x <= 2d + 1] Elemente. Für 2-dimensionale Strukturen würde in der Wurzel ein umfassendes Rechteck gespeichert werden. Genauso werden die einzelnen Objekte mit einem umfassenden Rechteck repräsentiert. Die routende Indexstruktur kann überlappende Regionen haben, und somit kann nicht immer jedes Objekt eindeutig zu einer Region zugeordnet werden. (Vgl. Abbildung 2.11) Suchoperationen müssen alle Regionen durchsuchen, die den Suchbereich streifen. Als Ausweg gibt es die Erweiterung in Form der R+ Bäume, welche nicht überlappende Regionen im Index speichern. Jedes Objekt, das mehrere Regionen streift, wird mehrfach im Index eingetragen. Dadurch verbraucht der Index mehr Speicherplatz, aber Suchoperationen erfolgen nur noch auf einem Pfad des Baums. Bedingt durch den Aufbau empfiehlt es sich, den Index bottom-up zu erstellen, da dies effizienter ist als ein top-down Aufbau. Denn die Regionsgrenzen beim bottom-up Verfahren sind näher an den Objekten, und es entstehen weniger leere Zwischenräume. Primär- und Sekundärindexe Primärindexe werden auf dem Primärschlüssel einer Relation angewendet. Der Primärschlüssel garantiert Duplikatfreiheit der Werte der entsprechenden Tupel. Deshalb ist ein Primärschlüssel (Primary Key) insbesondere für Joinoperationen geeignet und wird sehr häufig dafür verwendet. Mit einem Primärindex wird der Zugriff auf solch einen Primärschlüssel unterstützt. Somit besitzt auch der Primärindex die Eigenschaft der Duplikatfreiheit. Doch der Primärindex kann auch auf nicht Primärschlüsseln einer Relation definiert werden, solange die zu indizie- Karsten Schmidt, /IN99/2254

23 2 Grundlagen der Indexauswahl und Nutzung renden Attribute wiederum Schlüsseleigenschaft besitzen. Sekundärindexe werden für Sekundärschlüssel aufgebaut, wobei der Sekundärschlüssel einer Relation keine Schlüsseleigenschaft hat. Das bedeutet für die indizierten Attribute, dass der Sekundärindex Duplikate enthalten kann. Solch ein Sekundärindex kann auf jedem Attribut und jeder Attributkombination erstellt werden, um Joins und Selektionen zu unterstützen. 8 Clustered- und Non-Clustered-Index Die geclusterteten Indexe nutzen die sortierte Reihenfolge der Relation, auf die der Index verweist. Wenn z.b. eine Relation mit Artikeldaten fortlaufend nach Artikelnummern sortiert ist, dann ist eine Indexdatei auf dem Attribut Artikelnummer üblicherweise geclustert. Aufgrund der Reihenfolge des Indexes und der Relation unterstützen Clustered-Indexe insbesondere Bereichsanfragen. Non-Clustered-Indexe nutzen nicht die Reihenfolge der Relation aus. Sie sind anders organisiert als die Relation und verweisen somit nicht fortlaufend auf die Relationstupel. Für Punktanfragen ist der Non-Clustered-Index genauso effektiv wie ein Clustered-Index (vorausgesetzt die gewünschten Tupel liegen alle auf einer Seite im externen Speicher) Indexnutzung In einem DBMS gibt es für die physische Ebene verschiedene Ausführungsprimitiven, die den Zugriff auf Datenquellen ermöglichen. Der sequentielle Scan, auch Table-Scan oder Relationen- Scan genannt, liest eine Relation sequentiell ein. Dabei können zusätzlich Selektionsfilter für jedes Tupel prüfen, ob es zur Weiterverarbeitung verwendet werden soll. Auch kann jedes Tupelattribut projiziert werden, aber ohne das dabei Distinct-Bedingungen 9 geprüft werden können. Der Relationen-Scan ist auf jeder Relation möglich, wenngleich er nicht immer sinnvoll (der Schnellste) ist. Falls die RowID, die Zeilennummer eines Tupels, bekannt ist, kann mit Hilfe des TID-Scan direkt auf die Seite und Zeile des zu lesenden Tupels gesprungen werden. Dabei können, genau wie bei einem Relationen-Scan, Selektionsfilter und Projektion angewendet werden. Die indirekte Ausführungsprimitve Index-Scan benötigt einen zusätzlichen Index, und der Zugriff auf die Relation erfolgt indirekt über den Index. Das DBMS entscheidet selbständig, ob es die Vorteile des Indexes nutzen kann (siehe Kapitel 2.4 Kostenmodell). Zu den Vorteilen zählt die Unterstützung von Range-Queries (Bereichsanfragen). Das bedeutet, es wird nicht wie bei einem TID-Scan auf Gleichheit der Werte geprüft. Als Selektion ist die Form Anfangswert <= Key <= Endwert möglich. Dabei ist Key der Suchschlüssel des Indexes. Weiterhin unterliegen Indexe einer Ordnung und sind somit sortiert. Falls z.b. die Ausgabe der Anfrage in sortierter Form auf dem indizierten Attribut(en), durch eine OR- DER BY Klausel definiert, erfolgen soll, spart das DBMS die Sortierung der Ausgabetupel bei Nutzung der vorhandenen Sortierung des Indexes. Auch können Constraints 10 mit Hilfe eines Indexes einfacher und schneller beim Einfügen und Bearbeiten von Tupeln überprüft werden. Deutlich wird das bei einem Unique-Constraint, welches auch beim Primary Key zum Einsatz kommt und fordert, dass kein Wert mehrfach vorhanden sein darf. Hier kann ein Index-Lookup mit einigen wenigen Lesezugriffen entscheiden, ob der Key gegen ein Constraint verstößt oder nicht. Ein weiterer Vorteil der Verfügbarkeit von Indexen besteht in der Selektivitätsschätzung mit Hilfe partieller Index-Scans. Gerade beim Joinen oder beim Evaluieren von alternativen 8 Die meisten Datenbanken schränken die indizierbaren Attribute auf nicht binäre Datentypen ein. 9 Distinct bedeutet Duplikatfreiheit der Attributwerte. 10 Legen Bedingungen unter denen ein Attribut einen bestimmten Wert erhalten darf fest. Diese Constraints können auch in Abhängigkeit zu anderen Attributen definiert werden. Karsten Schmidt, /IN99/2254