Gunnar Söllig, Stand 3. 1. 2006 Studienarbeit Umsetzung von nutzerdefinierten Indexstrukturen in...
-
Upload
julian-sommer -
Category
Documents
-
view
215 -
download
0
Transcript of Gunnar Söllig, Stand 3. 1. 2006 Studienarbeit Umsetzung von nutzerdefinierten Indexstrukturen in...
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