Integration des RI-Baumes in das Extensible Optimizing Framework von Oracle Projektarbeit von Michael W. Passer Betreuer: Martin Pfeifle LFE Datenbanksysteme Institut für Informatik Ludwig-Maximilians-Universität München Prof. Dr. Hans-Peter Kriegel 3. Juli 2002

Gliederung 1. RI-Baum 2. Extensible Indexing Framework 3. Extensible Optimizing Framework 4. Kostenabschätzung Die Möglichkeit der Indexierung verschiedener Daten stellt ein zentrales Thema in Bezug auf Datenbanksysteme dar. Um für abgespeicherte Daten eine effiziente Anfragebearbeitung gewährleisten zu können werden für die Daten adäquate Indexe benötigt. Bekannte Datenbanksysteme, wie z.B. Oracle 8i, besitzen bereits eingebaute Indexe, die für einfache Datentypen ausreichend sind. Handelt es sich allerdings um komplexere Objekt, wie ausgedehnte Objekte, so „versagen“ diese eingebauten Indexe. Die einfachsten ausgedehnten und damit „räumlichen“ Objekte finden wir in eindimesionalen Datenräumen, nämlich Intervalle. Aus Anwendungssicht beschreiben sie z.B. temporale Daten auf einer Zeitachse. Eine zentrale Operation auf solchen Daten ist die räumliche Selektion, welche die Teilmenge aller gespeicherter Objekte ermittelt, die sich mit einer gegebenen Anfrageregion schneiden. Eine Indexstruktur, die solche Operationen effektiv und effizient unterstützt ist der RI-Baum, den ich kurz als Motivation vorstellen möchte. Um nun eine Indexstruktur auch einfach in mein bestehendes Datenbanksystem einbinden kann, um auch deklarativ auf meinen Index zugreifen zu können, bietet Oracle die Möglichkeit des Extensible Indexing Frameworks an, das ich als zweiten Punkt kurz erklären möchte. Wie wir sehen werden, stellt sich bei Indexstrukturen oft die Frage, ob es sinnvoll ist diesen Index für eine konkrete Anfrage einzusetzen. Also muß entschieden werden, wann eine Indexstruktur zum Einsatz kommt und wann nicht. Da diese Entscheidung vom in das Datenbanksystem eingebauten Optimierer getroffen wird, müssen wir diesem geeignete Kostenabschätzungsmechanismen zur Verfügung stellen. Eine Schnittstelle, dies zu tun, ist das Extensible Optimizing Framework von Oracle, das ich als nächstes darstellen werde. Ich werde den Vortrag mit einer Kostenabschätzung einer Anfrage auf dem RI-Baum abschließen. /12 2

RI-Baum  Grundlage: Binärer Intervallbaum [Edelsbrunner 1980] [Kriegel, Pötke, Seidl: Patent pending; VLDB 2000] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 A B C D 15 8 1 3 5 7 13 11 9 2 6 10 14 4 12 3a 15a 12c 5c 15a 7b 1b <KLICK>Grundlage für den Relationalen Intervall Baum bildet der Intervallbaum, von Edelsbrunner aus dem Jahre 1980. Er enthält einen binären Suchbaum, die sogenannte Primärstruktur, sowie eine Sekundärstruktur zur Speicherung der eigentlichen Intervalle. Bei der Einfügung neuer Intervalle stellen wir uns vor, dass diese von oben durch die Primärstruktur fallen <KLICK>, bis sie an einem Knoten hängen bleiben. Die Endpunkte eines registrierten Intervalls werden dort in zwei sortierten Listen verwaltet. 13d  Grundlage: Binärer Intervallbaum [Edelsbrunner 1980] /12 3

RI-Baum [Kriegel, Pötke, Seidl: Patent pending; VLDB 2000] 15 1 3 5 7 13 11 9 2 6 10 14 4 12 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 A B C root = 2h–1 D 15 8 1 3 5 7 13 11 9 2 6 10 14 4 12 3a 15a 12c 5c 15a 7b 1b Die erste Idee liegt nun darin die Primärstruktur zu virtualisieren. Wir merken uns nur den Wert der Wurzel und verzichten darauf, den Binärbaum in einer eigenen Datenstruktur zu materialisieren. Der abgedeckte Datenraum wird durch den Wert der Wurzel festgelegt <KLICK>. 13d 1 2h – 1  Grundlage: Binärer Intervallbaum [Edelsbrunner 1980]  1. Idee: Virtualisierung der Primärstruktur /12 3

RI-Baum root = 2h–1 [Kriegel, Pötke, Seidl: Patent pending; VLDB 2000] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 8 15 1 3 5 7 13 11 9 2 6 10 14 4 12 3a 15a 12c 5c 7b 1b 13d A B C D Die 2.Idee besteht darin,die Einträge der unteren und oberen Endpunktlisten auf zwei Relationen abzubilden. Auf die Informationen innerhalb dieser Relationen wird nun Mittels eines B+-Baumes zugegriffen.  Grundlage: Binärer Intervallbaum [Edelsbrunner 1980]  1. Idee: Virtualisierung der Primärstruktur  2. Idee: Zwei B+-Bäume speichern Intervallgrenzen node lower 4 8 13 1 3 5 id b a c d upper 7 12 15 lowerIndex upperIndex /12 3

RI-Baum - Anfragebearbeitung 1. Prozedurale Phase upper = 25 22 = lower Schnittanfrage Q  arithmetische Traversierung durch Primärstruktur  Sammeln der besuchten Knoten in transienten Tabellen  Anzahl von I/O-Zugriffen: 16 = root 24 = fork 20 28 22 26 23 25 Ein kleines Beispiel soll das verdeutlichen: Alle mit Pfeil markierten Knoten werden in transienten Tabellen gespeichert. <KLICK> wir setzen dann ein einziges SQl-Statement ab um die Ids der Intervalle zu bekommen, die unser Anfrageobjekt schneiden select id from upperIndex i, :leftNodes left where i.node = left.node and i.upper >= :Q.lower union all select id from lowerIndex i, :rightNodes right where i.node = right.node and i.lower <= :Q.upper select id from upperIndex i where i.node between :Q.lower and :Q.upper 16 20 28 26 22-25 2. Deklarative Phase – Relationale Bearbeitung durch eine (einzige) SQL-Anfrage – Anzahl von I/O-Zugriffen: O(h·logbn + r/b) /12 4

Gliederung 1. RI-Baum 2. Extensible Indexing Framework 3. Extensible Optimizing Framework 4. Kostenabschätzung Wir haben nun eine Indexstruktur für Intervalldaten kennen gelernt. Im folgenden wollen wir uns ansehen, wie einerseits die Notwendigkeit besteht für meine Intervalldaten benutzerdefinierte Operationen zur Verfügung zu stellen und ich andererseits sowohl meine Operationen, als auch meine Indexstruktur effizient in mein Datenbanksystem einbauen kann. /12 5

Extensible Indexing Framework (1) id interval 1 2 3 4 … (3, 7) (5, 6) (1, 1) (4, 5) … select db.id from intervals q, intervals db where q.id = 1 and intersects (q.interval, db.interval) Ergebnis: 1, 2, 4 Dazu wollen wir uns kurz folgendes Beispiel näher betrachten. Angenommen ich habe meine Intervalldaten in einer Tabelle abgespeichert. Dies ist sehr vereinfacht auf der linken Seite zu sehen. <KLICK> Nun möchte ich wissen, welche Intervalle von meinem ersten Intervall, also dem Intervall mit der id = 1, geschnitten werden. Diese Anfrage wird durch die auf der rechten Seite abgebildete SELECT-Anweisung erzielt. Zentraler Punkt dabei ist die Operation „intersects“, die überprüft, ob sich zwei übergebene Intervall schneiden. <KLICK> Man kann leicht sehen, dass das angefragte Intervall selbst und im weiteren die Intervall mit der id 2 und 4 als Ergebnis zurückgegeben werden. <KLICK> Welche Möglichkeiten habe ich nun, diese Operation intersects in Oracle zu implementieren? Eine Möglichkeit wäre intersects als stored procedure zur Verfügung zu stellen. Der große Nachteil daran ist aber, dass es in Oracle nicht möglich ist, stored procedures mit Indexstrukturen zu versehen. Man sieht nun also, dass die Notwendigkeit besteht, Indexstrukturen sowohl für Nicht-Standard-Datentypen, als auch für benutzerdefinierte Operationen zur Verfügung zu stellen. Um dies einfach und effizient einbauen zu können, bietet Oracle das Extensible Indexing Framework an. /12 6

Extensible Indexing Framework (1) id interval 1 2 3 4 … (3, 7) (5, 6) (1, 1) (4, 5) select db.id from intervals q, intervals db where q.id = 1 and intersects (q.interval, db.interval) Ergebnis: 1, 2, 4 Dazu wollen wir uns kurz folgendes Beispiel näher betrachten. Angenommen ich habe meine Intervalldaten in einer Tabelle abgespeichert. Dies ist sehr vereinfacht auf der linken Seite zu sehen. <KLICK> Nun möchte ich wissen, welche Intervalle von meinem ersten Intervall, also dem Intervall mit der id = 1, geschnitten werden. Diese Anfrage wird durch die auf der rechten Seite abgebildete SELECT-Anweisung erzielt. Zentraler Punkt dabei ist die Operation „intersects“, die überprüft, ob sich zwei übergebene Intervall schneiden. <KLICK> Man kann leicht sehen, dass das angefragte Intervall selbst und im weiteren die Intervall mit der id 2 und 4 als Ergebnis zurückgegeben werden. <KLICK> Welche Möglichkeiten habe ich nun, diese Operation intersects in Oracle zu implementieren? Eine Möglichkeit wäre intersects als stored procedure zur Verfügung zu stellen. Der große Nachteil daran ist aber, dass es in Oracle nicht möglich ist, stored procedures mit Indexstrukturen zu versehen. Man sieht nun also, dass die Notwendigkeit besteht, Indexstrukturen sowohl für Nicht-Standard-Datentypen, als auch für benutzerdefinierte Operationen zur Verfügung zu stellen. Um dies einfach und effizient einbauen zu können, bietet Oracle das Extensible Indexing Framework an. Möglichkeit der Implementierung in Oracle: intersects() als stored procedure aber: keine Indexunterstützung bei der Auswertung von stored procedures Notwendigkeit für: Extensible Indexing Framework /12 6

Extensible Indexing Framework (2) Integration von benutzerdefinierten – domain-spezifischen Operatoren (z.B. intersects()) – Indexstrukturen (z.B. RI-Baum) Realisierung der Integration bei Oracle 8i – Implementierung eines Interfaces durch den Benutzer Mit dem Extensible Indexing Framework habe ich als Benutzer die Möglichkeit benutzerdefinierte domain-spezifische Operatoren (wie z.B. mein intersects) und den dazugehörigen Index (hier der RI-Baum) zu integrieren. <KLICK> Die Realisierung dieser Integration erfolgt in Oracle 8i über eine Implementierung eines Interfaces durch den Benutzer. Dieses hat einen vorgegebenen Aufbau mit verschiedenen Prozeduren, die allesamt mit ODCI (also Oracle Data Cartidge Interface) beginnen und eine Implementierung meiner Indexstruktur darstellen. Die Implementierung stellt dann ein Paket dar, das auch als Data Cartrigde bezeichnet wird. Meine Opertoren werden funktional implementiert und können nun an meine Indexstruktur gebunden werden. <KLICK> Als Beispiel soll die Implementierung des RI-Baums als Data Cartridge dienen, der im Zuge eine Projektarbeit von Matthias Hampel erstellt wurde. Beispiel: – RI-Baum Data Cartridge (Projektarbeit von Matthias Hampel) /12 7

Gliederung 1. RI-Baum 2. Extensible Indexing Framework 3. Extensible Optimizing Framework 4. Kostenabschätzung Wie bereits erwähnt wird die Entscheidung darüber, ob eine Indexstruktur verwendet wird oder nicht, vom Optimierer gefällt. Auch hier gibt es eine effektive Möglichkeit den Optimierer bei dieser Entscheidung zu helfen… das Extensible Optimizing Framework. /12 8

Extensible Optimizing Framework (1) id RI-Baum interval 1 2 3 4 … (3, 7) (5, 6) (1, 1) (4, 5) select db.id from intervals q, intervals db where q.id = 1 and intersects (q.interval, db.interval) and db.id = 4 Ergebnis: 4 1. id über B+ - Baum 2. intersects() funktional Wir sehen hier wiederum das Beispiel von vorhin, in etwas abgeänderter Form. Neu hinzugekommen ist die Zeile db.intervals.lower = 4. Ich möchte damit meine Anfrage weiter einschränken, indem ich nur jene Intervalle ausgeben möchte, die Intervall 1 <KLICK> schneiden und deren linker Eckpunkt bei dem Wert 4 liegt. <KLICK> Als Ergebnis bekomme ich also das Interval mit der id 4. Der Unterschied in der Ergebnismenge dieser beiden SQL-Anweisungen ist die Selektivität. Hier wird nur ein Wert zurückgegeben, vorher waren es drei. <KLICK> Obwohl es sich hier um ein sehr vereinfachtes Beispiel handelt, sieht man schon , dass ein großer Unterschied besteht, wieviele Daten bei einer Anfrage zurückgegeben werden. Als Basis für die Entscheidung des Optimieres, ob es nun sinnvoll ist einen Index zu benutzen, dient einerseits die Selektivität, als auch die Kosten, die eine Anfrage tatsächlich kostet. Hier wird von Oracle zwischen CPU, I/O und Netzwerk-Kosten unterschieden. Wie bereits erwähnt werden Operationen funktional implementiert und im folgenden an die benutzerdefinierte Indexstruktur gebunden. Anhängig von der Selektivität ist es unter Umständen sinnvoll zwischen diesen Varianten zu unterscheiden… (Tabelle erklären) … /12 9

Extensible Optimizing Framework (1) select db.id from intervals q, intervals db where q.id = 1 and intersects (q.interval, db.interval) and db.id = 4 B+ id RI-Baum interval 1 2 3 4 … (3, 7) (5, 6) (1, 1) (4, 5) db.id <> 4 Ergebnis: 1, 2 1. intersects() über RI - Baum 2. id funktional Wir sehen hier wiederum das Beispiel von vorhin, in etwas abgeänderter Form. Neu hinzugekommen ist die Zeile db.intervals.lower = 4. Ich möchte damit meine Anfrage weiter einschränken, indem ich nur jene Intervalle ausgeben möchte, die Intervall 1 <KLICK> schneiden und deren linker Eckpunkt bei dem Wert 4 liegt. <KLICK> Als Ergebnis bekomme ich also das Interval mit der id 4. Der Unterschied in der Ergebnismenge dieser beiden SQL-Anweisungen ist die Selektivität. Hier wird nur ein Wert zurückgegeben, vorher waren es drei. <KLICK> Obwohl es sich hier um ein sehr vereinfachtes Beispiel handelt, sieht man schon , dass ein großer Unterschied besteht, wieviele Daten bei einer Anfrage zurückgegeben werden. Als Basis für die Entscheidung des Optimieres, ob es nun sinnvoll ist einen Index zu benutzen, dient einerseits die Selektivität, als auch die Kosten, die eine Anfrage tatsächlich kostet. Hier wird von Oracle zwischen CPU, I/O und Netzwerk-Kosten unterschieden. Wie bereits erwähnt werden Operationen funktional implementiert und im folgenden an die benutzerdefinierte Indexstruktur gebunden. Anhängig von der Selektivität ist es unter Umständen sinnvoll zwischen diesen Varianten zu unterscheiden… (Tabelle erklären) … /12 9

Extensible Optimizing Framework (1) select db.id from intervals q, intervals db where q.id = 1 and intersects (q.interval, db.interval) and db.id = 4 B+ id RI-Baum interval 1 2 3 4 … (3, 7) (5, 6) (1, 1) (4, 5) db.id <> 4 Ergebnis: 1, 2 1. intersects() über RI - Baum 2. id funktional Wir sehen hier wiederum das Beispiel von vorhin, in etwas abgeänderter Form. Neu hinzugekommen ist die Zeile db.intervals.lower = 4. Ich möchte damit meine Anfrage weiter einschränken, indem ich nur jene Intervalle ausgeben möchte, die Intervall 1 <KLICK> schneiden und deren linker Eckpunkt bei dem Wert 4 liegt. <KLICK> Als Ergebnis bekomme ich also das Interval mit der id 4. Der Unterschied in der Ergebnismenge dieser beiden SQL-Anweisungen ist die Selektivität. Hier wird nur ein Wert zurückgegeben, vorher waren es drei. <KLICK> Obwohl es sich hier um ein sehr vereinfachtes Beispiel handelt, sieht man schon , dass ein großer Unterschied besteht, wieviele Daten bei einer Anfrage zurückgegeben werden. Als Basis für die Entscheidung des Optimieres, ob es nun sinnvoll ist einen Index zu benutzen, dient einerseits die Selektivität, als auch die Kosten, die eine Anfrage tatsächlich kostet. Hier wird von Oracle zwischen CPU, I/O und Netzwerk-Kosten unterschieden. Wie bereits erwähnt werden Operationen funktional implementiert und im folgenden an die benutzerdefinierte Indexstruktur gebunden. Anhängig von der Selektivität ist es unter Umständen sinnvoll zwischen diesen Varianten zu unterscheiden… (Tabelle erklären) … Entscheidungskriterien für optimale Zugriffsvariante: Selektivität Kosten (CPU, I/O, Netzwerk) Notwendigkeit für: Extensible Optimizing Framework /12 9

Extensible Optimizing Framework (2) bietet Interface zur Integration einer benutzdefinierten Indexstruktur in den CBO sammelt Statistiken und benutzt diese für Selektivitäts- und Kostenabschätzung bei der Anfrageoptimierung Ablauf der Optimierung einer SQL-Anfrage: Ablauf der Optimierung einer SQL-Anfrage: /12 10

Gliederung 1. RI-Baum 2. Extensible Indexing Framework 3. Extensible Optimizing Framework 4. Kostenabschätzung /12 11

Kostenabschätzung I/O-Komplexität des RI-Baumes: [Kriegel, Pfeifle, Pötke, Seidl: SSDBM 2002] I/O-Komplexität des RI-Baumes: Kosten der Indexnavigation (B+ - Baum - Directory) abhängig von Datenmenge und Datenraum Kosten des Indexscans (B+ - Baum - Blätter) abhängig von Selektivität wichtig für: Erstellung des Ausführungsplans Kostenabschätzung /12 12

Vielen Dank für die Aufmerksamkeit ! /12