Gunnar Söllig, Stand Studienarbeit Umsetzung von nutzerdefinierten Indexstrukturen in ORDBMS am Beispiel eines Indexes für mehrdimensionale Datenstrukturen

2 Gliederung  Erweiterung ORDBMS Drei Ansätze  Multidimensionale Zugriffsverfahren Überblick Konkret: LSD h -Baum  Konzept dieser Implementation Relational Indexing mit IBM DB2

3 Erweiterung ORDBMS  Vorhanden: Nutzerdefinierte Datentypen, Prädikate Erweiterbare Indexing-Frameworks  Data cartridges, database extenders, data blades  Probleme: Effiziente Ausführungspläne gefordert Zugriffsmethode selbst nicht änderbar Engpässe bei Auslagerung  Ziel: Verwendbarkeit selbstdefinierter Indexe gleichwertig Standardindexen

4 Erweiterung ORDBMS  Deklaration CREATE TYPE t_obj AS OBJECT(…) CREATE TABLE my_objects(obj t_obj) CREATE INDEX custom_idx ON my_objects(obj)  Extensible Indexing index_create(), index_drop(), index_open() index_close(), index_insert(), …  Unterstützung Optimierer stats_collect(), predicate_select() index_cpu_cost(), index_io_cost()

5 Varianten  Integrierender Ansatz „hartverdrahtet“ im DB-Kern  Generischer Ansatz Generalized Search Tree (GiST)  Relationaler Ansatz Setzt auf SQL-Schicht auf

6 Integrative Approach  ACID-Prinzip gewährleisten  Unterscheidet Extending/Enhancing Approach  Vorteil: Höchste Performanz  Nachteile: Umfangreiche Implementation Fehleranfällig, plattformabhängig Praktisch nur durch Hersteller realisierbar

7 Generic Approach  Generalized Search Tree  Wird einmalig wie Integrative Approach implementiert  Bietet dann Framework für beliebige Indexe  Vorteil: Leichte Integration neuer Indexe  Nachteile: Schwierig zu implementieren Aktuell nur Forschungsprototypen

8 Relational Approach  Definition des Indexes mittels relationaler Anfragesprache  Unterliegt deren Beschränkungen, nicht in jedem Fall anwendbar  Geringer Implementierungsaufwand  Implementierungsunabhängig von tieferliegenden Schichten, plattformunabhängig  Trotzdem konkurrenzfähige Performanz

9 Schaubild Vergleich Entnommen aus: Hans-Peter Kriegel et al: The Paradigm of Relational Indexing: A Survey

10 Multidimensionale Zugriffsverfahren  Anwendungsfälle Medizin, CAD, Geographie, Molekularbiologie  Ähnlichkeitsmaß Keine generelle Definition möglich Oft L k -Metrik  Feature Transformation  Typische Anfragen Punktanfrage (identity query) Bereichsanfrage (range query) (k-)NN-Anfrage (epsilon/nn-query)

11 Klassifizierung Zugriffsstrukturen  Data partitioning vs. space partioning  Hash-basierte (ungeignet) Grid-File, Buddy-Tree  R-Baum-ähnliche R-Tree, R*-Tree, R + -Tree, X-Tree SS-Tree, SR-Tree TV-Tree  kd-Baum-basierte VAMSplit-R-Tree, LSD-Tree, speziell LSD h -Tree  Weitere Pyramid Tree Space Filling Curves

12 Genauer: LSD h -Tree (A. Henrich et al)  Ist definiert durch Vorgehen beim Splitting: Wähle Dimensionen der Reihe nach Überspringe dabei Dimensionen, in denen keine verschiedenen Datenwerte auftreten Modifikation bei hoher Dimensionszahl möglich Splitwert i.d.R. datenabhängig, z.B. arithmetisches Mittel  Ausgleichsverfahren ähnlich B-Baum- Varianten  Erweiterung mittels Coded Actual Data Regions (CADR)

13 CADR im LSD h -Tree  Zerlegung des gesamten Datenraumes einer Region in gleich große Hyperwürfel  Pro Dimension Speicherung des kleinsten und des größten Indexes besetzter Teilwürfel  Zusätzlicher Speicheraufwand 2*z*d Bit bei d Dimensionen und Auflösung z Entnommen aus: Christian Böhm et al: Searching in High-Dimensional Spaces – Index Structures for Improving the Performance of Multimedia Databases

14 k-NN-Suche im LSD h -Tree  Von der Wurzel ausgehend Bucket mit Startpunkt p der Suche ermitteln (Punktanfrage)  Dabei Speichern der nicht verfolgten Geschwisterknoten in einer NPQ (node priority queue), Sortierung gemäß Abstand zu p  k nächste Nachbarn aus Bucket mit p in die OPQ (object priority queue)  Solange sinnvoll, ersetze Elemente aus OPQ durch bessere aus Datenregion des NPQ-Kopfes (Abbau NPQ)

15 Relational Indexing mit DB2  Erweiterungsmöglichkeiten DB2 UDFs, Stored Procedures, user defined types Prädikate auf nutzerdefinierten Datentypen  Bsp. Interval-Tree: IntervalOverlap  Auf (selbstdefinierten) komplexen Datentypen ist kein Ordnungskriterium bekannt Indexframework definiert Schnittstellen zur Bereitstellung der fehlenden Funktionalität  Fragestellungen bei Erstellung und Nutzung des Indexes Änderungsoperationen bedingen Einfügen, Löschen von Schlüsseln Anfrageoperationen bewirken Indexscans

16 Änderungsoperationen Entnommen aus: Knut Stolze et al: DB2 Index Extensions by example and in detail

17 Key-Generator  Anbindung innerhalb der Indexdefinition  Beispiel CREATE INDEX EXTENSION interval_tree FROM SOURCE KEY (i interval) GENERATE KEY USING IntervalKeyGen (i..start, i..stop)

18 Indexabfrage Entnommen aus: Knut Stolze et al: DB2 Index Extensions by example and in detail

19 Nutzerdefinierte Prädikate  Für welche Prädikate einer WHERE-Klausel kann der Index sinnvoll eingesetzt werden? Information mittels PREDICATES-Klausel in Prädikatdefinition  Beispiel CREATE FUNCTION IntervalOverlap (i1 interval, i2 interval) … PREDICATES ( WHEN = 1 SEARCH BY EXACT INDEX EXTENSION interval_tree WHEN KEY(i1) use USE overlaps(i2) WHEN KEY(i2) use USE overlaps(i1) )

20 Range Producer/Index Filter  Range-Producer: user defined funtion, liefert TABLE (rangestart INTEGER, rangeStop INTEGER)  Index Filter: für weitere Filterung des gefundenen Range kann noch eine UDF definiert werden (wiederum mit einer PREDICATES-Klausel)

21 Implementation LSD h -Baum  Ausgeglichener binärer Baum mit Pre- order-Numerierung der Knoten als virtueller Backbone-Tree (vgl. Interval- Tree)  Problem: Splitting/Ausgleichen  Lösungsansätze: Extra Datenstruktur zur Speicherung des Baumstatus, Berechnung des Schlüsselwertes vorgelagert in Insert-Routine Betroffene Datensätze mittels Delete- und Insert-Operationen verschieben