Gunnar Söllig, Stand 3. 1. 2006

Studienarbeit

Umsetzung von nutzerdefinierten Indexstrukturen in ORDBMS amBeispiel eines Indexes für mehrdimensionale Datenstrukturen

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)

0: ObjObj

dObjF :

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 = 1SEARCH BY EXACT INDEX EXTENSION

interval_treeWHEN 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