Studienarbeit

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

2. Gliederung • Erweiterung ORDBMS • Drei Ansätze • Multidimensionale Zugriffsverfahren • Überblick • Konkret: LSDh-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 Lk-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 LSDh-Tree • Weitere • Pyramid Tree • Space Filling Curves

12. Genauer: LSDh-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 LSDh-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 LSDh-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 LSDh-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