Christian Thiel (RI
Werbung
Betreuer: Sven Helmer Vorstellung der Studienarbeit von Christian Thiel Eine objektrelationale Datenstruktur zur Verwaltung von Intervallen in relationalen Datenbanken Der RiTree-Index Motivation für objektrelationale Indexstrukturen Der allgemeine Intervallbaum Der relationale Intervallbaum (RiTree) Ergebnisse der Studienarbeit Ausblick: Der SRPS-Tree (event. Beweis des Fehlers in dyn. Version des RiTrees) Übersicht Schnittstellen Datenbankabhängig Hoher Implementierungsaufwand Transaktionsmanagement nicht unterstützt Bisher: EXTERNE Indexstrukturen zur Intervallverwaltung in Datenbank Nachteile: Motivation für objektrelationale Indexstrukturen (1) Verwaltung der Indexstruktur durch DB Portabilität durch SQL-Schnittstellen Übernimmt Transaktionsmanagement der DB Effizienz der DB ausgenutzt (z.B. B+-Baum) Vorteile: Nun: Objektrelationales Paradigma Motivation für objektrelationale Indexstrukturen (2) sortiert Intervalle anhand deren Grenzen Intervall wird höchstem Konten zugeordnet, dessen Wert zwischen Intervallgrenzen liegt Jedem Knoten werden 2 Listen zugeordnet: Listen sortieren zugewiesene Intervalle nach oberen bzw. unteren Intervallgrenzen Für schnelleres Suchen: Zusätzlicher Binärbaum, der nicht leere Knoten verlinkt Tertiäre DS: Sekundäre DS: Dreifach gegliederte Datenstruktur: Primäre DS: Binärer Suchbaum Der allgemeine Intervallbaum (1) Der allgemeine Intervallbaum (2) Sortierte Listen durch Relationen ersetzen: (node, upper) bzw. (node, lower) Relationen zusammenfassen: (node, lower, upper, id) Relationen mit (node, lower) & (node, upper) indexieren da nur nicht-leere Knoten in Relation erfasst werden ist tertiäre DS überflüssig Sekundäre & Tertiäre Datenstrukturen: nicht materialisiert Indexwerte werden „on the fly“ berechnet Umsetzung des gemeinen Intervallbaumes in das objektrelationale Paradigma Primäre Datenstruktur: Der relationale Intervallbaum (RiTree) (1) „On the fly“-Berechnung des Indexknotens für ein gegebenes Intervall (lower, upper): Der relationale Intervallbaum (RiTree) (2) Überschneidungssuche für Intervall (lower, upper) im RiTree: Der relationale Intervallbaum (RiTree) (3) Knoten auf diesem Pfad liegen ober- oder unterhalb des Suchintervalls liegt Knoten w unterhalb, sind an ihm registrierte Intervalle (l, u) relevant g.d.w. lower < u => u(w) muss durchsucht werden liegt Knoten w oberhalb, sind an ihm registrierte Intervalle (l, u) relevant g.d.w. l < upper => l(w) muss durchsucht werden Auf diesem Weg 2 Fälle: Wenn w < lower gilt, muss u(w) durchsucht werden Wenn lower < w, schneidet Suchintervall alle Intervalle, die an Knoten registriert sind Das Gleiche Richtung upper…. Außerdem sind alle Intervalle an Knoten zwischen diesen Wegen relevant steige Baum hinab zum Knoten, der lower am nächsten liegt Unterhalb des Gabelknotens: Traversiere ausgehend von der Wurzel zum Gabelknoten Überschneidungssuche für Intervall (lower, upper) im RiTree: Der relationale Intervallbaum (RiTree) (4) Verteilung der Intervalldaten Punkte 0 - 100 random 100 fix 0 - 10k random 10k fix Anzahl der Indexknoten hängt stark von Datenverteilung ab Je breiter die zu verwaltenden Intervalle, desto weniger Indexknoten werden benötigt Selektivität des Indexes nicht beeinflussbar 1 10 100 1000 10000 Knotenanzahl des RiTrees bei 10000 verwalteten Intervallen Ergebnisse der Studienarbeit (1) RI_intersect Anfragetyp RI_contained 0 fix 100 fix 10k fix 0 - 100 rand 0 - 10k rand (2) 0 - 10k rand (1) Verschiedene Datenverteilungen führen zu unterschiedlichen Leistungen des Indexes Unterschiedliche Anfragetypen unterschiedlich schnell 40 30 20 10 0 70 60 50 Vergleich der Leistungen der Indexstruktur auf unterschiedlich aufgebauten Datenmengen Ergebnisse der Studienarbeit (2) Dauer (SQL=100) 0er 10er 100er 1000er 10000er 100000er 500000er Intervalle sehr breit => Alle Baumknoten relevant => schlechte Selektivität Zusätzlich Overhead durch Indexberechnung Performance des RiTrees: ca. 70% kürzere Antwortzeiten Leistung degeneriert bei großen Anfrageintervallen: 0 50 100 150 200 250 300 Durchschnittliche Antwortzeit in Abhängigkeit von der Breite der in der Anfrage verwendeten Intervalle Ergebnisse der Studienarbeit (3) Antwortzeit [ms] RI SQL 0 1000 10000 Breite der Intervalle in der Datenbank 100 100000 Gleicher Effekt bei zunehmender Breite der in der Datenstruktur verwaltenden Intervalle 160 140 120 100 80 60 40 20 0 Durchschnittliche Antwortzeit in Abhängigkeit von der Breite der durch die Datenstruktur verwalteten Intervalle Ergebnisse der Studienarbeit (4) Dauer der Anfrage [ms] SQL RI 5000 50000 Intervalle in der Indexstruktur 10000 100000 Die Leistung des RiTree - Indexes sinkt langsam mit zunehmender Anzahl zu verwaltender Intervalle Ohne die Verwendung des Indexes fällt Leistung sehr viel schneller ab 0 200 400 600 800 1000 Durchschnittliche Antwortzeit in Abhängigkeit von der Anzahl der durch die Datenstruktur verwalteten Intervalle Ergebnisse der Studienarbeit (5) D au er d er A n frag e [m s] RI SQL Indexstruktur gute „worstcase“-Performance Performance unabhängig von Datenverteilung Ziele: Aufwendigere Abhilfe: SRPS-Tree „worstcase“- Performance Selektivität & Leistung des Indexes hängt von Datenverteilung ab – nicht beeinflussbar Schlechte Nachteile des RiTrees: Ausblick: Der SRPS-Tree 1 2 3 Wohin mit (4,7)? 1 2 3 5 Hier hin: (4,7) 4 6 Bisher: statischer Baum Frage: Was tun, wenn einzufügendes Intervall aus dem Wertebereich fällt? Antwort: Baum dyn. Anpassen! Methode im dyn. RiTree: Neue Wurzel erschaffen! Beweis des Fehlers in dyn. Version des RiTrees 7 1 „leerer“ RiTree 2 3 4 5 6 7 Wurzel = 4 Problem: Suchalgorithmus findet u.U. nicht mehr alle relevanten Intervalle Beispiel: Beweis des Fehlers in dyn. Version des RiTrees 1 (3, 30) an Knoten 4 (aktueller Wurzelknoten) eingefügt. 2 3 Intervall (3,30) einfügen: 4 5 (3, 30) 6 7 Wurzel = 4 Beweis des Fehlers in dyn. Version des RiTrees 1 2 3 (3, 30) (28, 30) an Knoten 28 eingefügt. 4 5 8 6 … 16 … 7 … 24 28 … (28, 30) Wurzel = 16 Das Einfügen von (28,30) führt zu einer Baumanpassung Neue Wurzel ist 16 Beweis des Fehlers in dyn. Version des RiTrees rightRoot = 2 log2 30 = 2 4 = 16 1 2 3 (3, 30) 4 (3, 30) an Knoten 4 wird bei einer Überschneidungssuche bzgl. dem Intervall (24, 29) nicht gefunden 5 8 6 … 16 … 7 … 24 28 … (28, 30) Wurzel= 16 Überschneidungssuche für Intervall (24,29) Relevantes Intervall (3,30) wird nicht gefunden! Beweis des Fehlers in dyn. Version des RiTrees
