Grid Files – Martin HaseneyerFolie 1/ 51 – 09.06.2005 Siegmundsburg Grid Files Daten hinter...

Grid Files – Martin Haseneyer Folie 1/ 51 – 09.06.2005 Siegmundsburg

Grid FilesDaten hinter Gittern?

Eine dynamische Datenstruktur mit mehrdimensionalen Zugriffspfaden

Seminar im Sommersemester 2005Dozent: Prof. Dr. Klaus KüspertBetreuer: Dipl.-Inf. David Wiese

Grid Files – Martin Haseneyer Folie 2/51 – 09.06.2005 Siegmundsburg

1. Eigenschaften2. Aufbau

1. Buckets2. Grid Directory

3. Dynamisches Verhalten1. Suchen2. Einfügen3. Löschen

4. Implementierung5. Relevanz für

Data Warehousing 6. Erweiterungen

1. Grid Grids2. Interpolations-

basiertes Grid File

7. Fazit

Agenda

Ein Einstieg in das Thema

Data Warehousing: oft… riesige Datenmengen (GB und mehr) hohe Aggregation hohe Selektivität (gesucht oft „nur“ im

Bereich MB/KB) d.h., wenn wir einen Table Scan auf die

Daten laufen lassen, haben wir genug Zeit, um richtig viel Kaffee zu kochen

Eine effiziente Datenstruktur muss hierbei helfen.








basiertes Grid File

7. Fazit

Agenda

1. Eigenschaften

oder: kleine Wunschlistean eine Datenstruktur








basiertes Grid File

7. Fazit

Agenda

1. Eigenschaften (I): Prinzip der zwei Zugriffe

Prinzip der zwei Plattenzugriffe für exakte Anfragen (point queries) bei Anfragen nach Ergebnismengen: erster

Datensatz nach zwei Zugriffen egal, wie die Verteilung der Datensätze

aussieht egal, wieviele Operationen vorher

durchgeführt wurden egal, wieviele Datensätze momentan

gespeichert sind








basiertes Grid File

7. Fazit

Agenda

1. Eigenschaften (II): Lokalitätsprinzip

Benachbarte Punkte im Datenraum sollen auch physisch benachbart gespeichert werden (möglichst ~) einfacher Zugriff auf „ähnliche“ Daten auf

der Platte Nearest-Neighbor-Abfragen

Diese beiden Prinzipien werden selten erfolgreich umgesetzt.








basiertes Grid File

7. Fazit

Agenda

1. Eigenschaften (III): Effizienzgesichtspunkte

Beim Teilen oder Verschmelzen von Zellen sollen nur zwei Speichereinheiten („Buckets“) betroffen sein

Durchschnittliche Speicherplatz-Ausnutzung (der „Buckets“) soll über einer „vernünftigen“ Grenze liegen (in der Regel bei ca. 70%)








basiertes Grid File

7. Fazit

Agenda

1. Eigenschaften (IV): Dynamik, Symmetrie

dynamische Anpassung beim Einfügen und Löschen

Symmetrische Behandlung aller Dimensionen des Datenraums alle Attribute wie Primärschlüssel

behandelt, es gibt keine Hierarchie Multikey-Access: es kann nicht „nur

einen geben“ ermöglicht partial-match-Anfragen Mehrdimensionalität








basiertes Grid File

7. Fazit

Agenda

2. Aufbau

oder: stecken Sie Array A in Liste E,um eine Datenstruktur zu erhalten








basiertes Grid File

7. Fazit

Agenda

2. Aufbau (I): Modellierung der Datensätze

Datensätze als Datenpunkte im Raum auf jeder Dimension ein Punkt alle Dimensionspunkte: „Ort“ des

Datensatzes im Datenraum








basiertes Grid File

7. Fazit

Agenda

2. Aufbau (II): Übersicht über Grid File-Strukturen

Buckets zur Speicherung der Daten Grid Directory, bestehend aus:

Skalenvektoren Grid-Directory mit Grid-Zellen (teilweise zu

Regionen zusammengefasst)


2.1. Buckets (Speicherseiten)

Speichereinheit für Datensätze Menge von Datensätzen (oder besser:

Zeigern auf Datensätze), die zusammen auf einer physikalischen Einheit gespeichert werden

z.B. bei b = 3: Es passen bis zu drei Datenpointer in einen Bucket, sonst „läuft er über“

typischerweise auf Externspeicher


2.2. Grid-Directory (I): Skalenvektoren

„Verwaltung der Verwaltung“ für jede Dimension von D ein Vektor

lineare Ordnung entlang der Dimension in Intervalle unterteilt skalieren Dimension auf Grid-Zellen

typischerweise im Hauptspeicher (Prinzip der zwei Plattenzugriffe!)


2.2. Grid-Directory (II): Grid

Such- und Verwaltungseinheit typischerweise auf Externspeicher besteht aus:

Grid-Zellen: Hyperquader, die den Datenraum ausfüllen (konvex, paarweise disjunkt)

Grid-Regionen: Zusammenfassung von Grid-Zellen, die genau einem Bucket zugeordnet sind (konvex, paarweise disjunkt)








basiertes Grid File

7. Fazit

Agenda

2. (VI) Aufbau: Regionen, Buddy-System

Buddy- oder Zwillingszellen: Zellen, die aus der Teilung einer

vorhergehenden Zelle entstehen Teilmenge der Nachbarzellen








basiertes Grid File

7. Fazit

Agenda

2. (VII) Aufbau: Das kommt davon…








basiertes Grid File

7. Fazit

Agenda

2. Aufbau (VI): Beziehungen zwischen Komponenten

Beziehung Region – Zelle: 1:n Beziehung Region – Bucket: 1:1








basiertes Grid File

7. Fazit

Agenda

Buckets

Grid Directory

2. Aufbau (VII): Zusammenfassung

Grid File








basiertes Grid File

7. Fazit

Agenda

3. Dynamisches Verhalten

oder: Pressen, da geht noch was!








basiertes Grid File

7. Fazit

Agenda

3. Dynamisches Verhalten (I): Überblick

Was soll möglichst (kosten)günstig gehen? Datensätze einfügen Datensätze suchen Datensätze wieder löschen

dazu brauchen wir als Grundlage: Teilen von Grid-Zellen Verschmelzen von Grid-Zellen

…möglichst ohne sichtbare Pausen aufgrund „plötzlicher“ interner Verwaltungsroutinen








basiertes Grid File

7. Fazit

Agenda

3.1. Suchen (I): Beispiel

Finde Datensatz (Q;68) SuchvorgangIntervallgrenzen

IntervallnummernDaten(raum)








basiertes Grid File

7. Fazit

Agenda

3.1. Suchen (II): Algorithmus

bestimme für jede Dimension, in welchem Intervall (der Dimension) der gesuchte Wert ist

bestimme aus Intervallen die gesuchte Grid-Zelle

lade Directory-Teil, der Zelle(n) enthält lese Verweis auf Bucket(s) aus Grid-

Zelle(n) lade Bucket(s) durchsuche die gefundenen Werte liefere Ergebnis zurück

1. Plattenzugriff

2. Plattenzugriff








basiertes Grid File

7. Fazit

Agenda

3.2. Einfügen (I): Beispiel

Beispiel für: Datenraum D (1..100; A..Z) Bucketgröße b = 3

Bucket-Überlauf!








basiertes Grid File

7. Fazit

Agenda

3.2. Einfügen (II): Algorithmus

Schritt 1: Zuordnung zur Grid-Zelle finde Bucket, in den der Wert

gespeichert werden soll wie Suche…

speichere Wert in Bucket


3.2. Einfügen (III): Algorithmus (Fortsetzung)

Schritt 2: Läuft der Bucket über? Ja: dann erstelle neuen, leeren Bucket

Wird „alter“ Bucket mehrfach referenziert? Ja (Fall A): dann…

Verbiege Zeiger der beiden Zellen auf die beiden Buckets

Verteile die Werte aus Bucket (und den neuen) gemäß der Zellgrenzen auf die beiden Buckets

Nein (Fall B): dann… Wähle Dimension und Trennwert teile die Zellen in der Dimension

entlang des Wertes; geteilte Zellen zeigen auf denselben Bucket

Auslöserzelle: Fall A Nein: füge den Wert in den Bucket ein

Fall B

Fall A








basiertes Grid File

7. Fazit

Agenda

3.3. Löschen (I): Beispiel Beispiel für:

Datenraum D (1..100; A..Z) Bucketgröße b = 3

Bucket-Unterlauf!








basiertes Grid File

7. Fazit

Agenda

3.3. Löschen (II): Algorithmus

finde Wert in Bucket lösche Wert bestimme Merging-Kandidaten würde verschmolzener Bucket über

Auslastungs-Schwelle liegen? ja: Buckets verschmelzen, Zeiger

umbiegen ggf. Test ob man Intervall auf der

Dimension verschmelzen kann korrespondierende Zellen der Teilintervalle

verweisen auf jeweils dieselben Buckets? Ja: Intervallverschmelzung








basiertes Grid File

7. Fazit

Agenda

4. Implementierung

oder: Wie kriegen wir das jetzt hin?








basiertes Grid File

7. Fazit

Agenda

4. Implementierung (I)

Zwei Fragen der Implementierung: Wie läßt sich das Grid Directory möglichst

„gut“ abspeichern? Wo wird getrennt, wenn Zellen oder

Dimensionen geteilt werden sollen?








basiertes Grid File

7. Fazit

Agenda

4. Implementierung (II): Speichern des GD (I)

Als Array?+ direkter, wahlfreier Zugriff auf die

Elemente möglich (random access)- hoher Aufwand beim Teilen und

Verschmelzen „in der Mitte“ (umkopieren)








basiertes Grid File

7. Fazit

Agenda

4. Implementierung (III): Speichern des GD (II)

Als verkettete Liste?+ Teilen/Verschmelzen von Zellen einfach,

nur Umbiegen der Zeiger und Einfügen von Elementen

- kein direkter Zugriff auf Elemente, nur Durchlaufen der Liste möglich


4. Implementierung (IV): Speichern des GD (III)

Mögliche Methode: Array-Größe über kleinstes Intervall bestimmen falls Min-Intervall geteilt wird: Array-Größe

verdoppeln genug Raum um Teilungen an anderer

Stelle zu kompensieren ggf. hoher Speicherplatzbedarf (besonders

bei schiefen Verteilungen) viele kleine Teilungen zu einer großen

Teilung zusammengefaßt

Ist die Einfüge-/Lösch-Laufzeit für Data Warehousing überhaupt wichtig?








basiertes Grid File

7. Fazit

Agenda

4. Implementierung (V): Wo teilen? (I)

In welcher Dimension wird geteilt? Wo genau wird dann geteilt? Müssen wir eine Dimension teilen? Oder reicht es, einen Bucket

aufzusplitten? gerade bei großen Directories und

schiefen Verteilungen zeigen große Regionen auf ein und denselben Bucket








basiertes Grid File

7. Fazit

Agenda

4. Implementierung (VI): Wo teilen? (II)

Aber bei Teilung viele Möglichkeiten, eine Dimension auszuwählen: zyklisch durchlaufend Bevorzugung von Attributen genauere

Auflösung der Ergebnisse (z.B. werden unterschiedliche Granulate bei Abfragen erwartet)

… Ein bestimmtes Verfahren ist nicht

vorgesehen. Vielfältige Optimierungsmöglichkeiten für

den Administrator Performance, Performance, Performance!








basiertes Grid File

7. Fazit

Agenda

4. Implementierung (VII): Wo teilen? (III)

Wo teilt man Zellen/Intervalle? Intervall halbieren Mittelwert der Intervallwerte Nach Einheiten (z.B. Zeitachsen-Split

immer zur ganzen Woche usw.) …

Auch hier kein bestimmtes Verfahren vorgesehen.

Optimierungspotenzial begrenzt; aber: ggf. Performance-Einbußen bei ungünstiger Verteilung der Daten, z.B. A1: a, d, d, d, f, s, v A2: 0, 5, 5, 5, 7, 9








basiertes Grid File

7. Fazit

Agenda

5. Relevanz für Data Warehousing

oder: Wozu erzählt uns der Onkel das überhaupt?








basiertes Grid File

7. Fazit

Agenda

5. Relevanz für Data Warehousing (I)

Anfangsszenario: zig GB Daten, teilweise hohe Selektivität wichtig ist Geschwindigkeit der Verarbeitung

Vorgehen: oft „BULK INSERT“, dann nur „SELECT“-Abfragen Prinzip der zwei Zugriffe ideal

ermöglicht einfache und schnelle Mehr-Komponenten-Anfragen über verschiedene Dimensionen („Scheiben schneiden“)

Bereichanfragen (partial range), partial match-Anfragen problemlos möglich








basiertes Grid File

7. Fazit

Agenda

5. Relevanz für Data Warehousing (II)








basiertes Grid File

7. Fazit

Agenda

6. Erweiterungen

oder: Warum denn nicht gleich so?








basiertes Grid File

7. Fazit

Agenda

6.1. Grid Grids, hierarchische Grid Files, …

viele Namen für ein Prinzip: ein kleines Grid verwaltet das/die großen Grids

Persistent Grid File

Hierarchical Grid File








basiertes Grid File

7. Fazit

Agenda

6.2. Interpolationsbasiertes Grid File (I): Motivation

Dimensionsverfeinerung: Grid benötigt eigentlich nur eine neue Zelle es wird aber die ganze Dimension geteilt Buckets bleiben, aber Directory wächst

besonders bei schiefen Verteilungen: viele leere Zellen








basiertes Grid File

7. Fazit

Agenda

6.2. Interpolationsbasiertes Grid File (II): Hintergrund

Zellen unterschiedlicher Größe (statt „Scheiben schneiden“)

nur ein Directory-Eintrag pro BucketIdee: zerteile Datenraum in Hierarchie jede Zelle angesprochen über Zell- und

Ebenennummer Teilung in der Zellmitte Binärzellen








basiertes Grid File

7. Fazit

Agenda

6.2. Interpolationsbasiertes Grid-File (III): Aufteilung


6.2. Interpolationsbasiertes Grid-File (IV): Aufteilung

mehrere Hierarchieebenen verwendet: Binärzellen verschiedener Größe bessere Anpassung an ungleichförmige

Datenverteilung im Datenraum Grid Directory als Baum

1,23,3

7,4 15,4








basiertes Grid File

7. Fazit

Agenda

7. Fazit

oder: Das Buffet wird in O(n) eröffnet.








basiertes Grid File

7. Fazit

Agenda

7. Fazit (I): Vergleich – Überlappungsverfahren

Verfahren mit überlappenden Regionen (z.B. R-Baum): Suchen ineffizient Grid File: sehr

effizient (Prinzip der zwei Plattenzugriffe) gute Speicherausnutzung Grid File:

Buckets gut, Grid Directory weniger gut geringer Wartungsaufwand Grid File:

geringer Wartungsaufwand Grid Files sind bei Suche schneller,

brauchen aber ggf. mehr Speicher








basiertes Grid File

7. Fazit

Agenda

7. Fazit (II): Vergleich – Objektaufteilungsverfahren

Verfahren, die Objekte aufteilen (z.B. R+-Baum, Zellbaum) und redundant in mehreren Zellen speichern: Suche effizient Grid File: auch effizient schlechte Speicherplatzausnutzung

Grid File: Buckets relativ gut, Grid Directory weniger gut

Probleme bei der Wartung Grid File: relativ geringer Wartungsaufwand

Grid Files sind wartungsfreundlicher








basiertes Grid File

7. Fazit

Agenda

7. Fazit (III): Prinzipien

Prinzip der 2 Plattenzugriffe gewahrt Lokalitätsprinzip auch gewahrt

schön, da selten








basiertes Grid File

7. Fazit

Agenda

7. Fazit (IV): Überblick

Nutzung der Datenstrukturen für punktförmige Objekte (Datenobjekte zu Punkten transformiert und abgebildet)

symmetrische, anpassbare Datenstruktur für multiple Schlüssel

schneller Zugriff, effiziente Bereichsanfragen

Wartung einfach möglich, Speicherausnutzung gut








basiertes Grid File

7. Fazit

Agenda

7. Fazit (V): Probleme

Speichernutzung/Stabilität bei ungünstigen Datenverteilungen (Wachstum des Directorys)

zusätzliche Indirektion TIDs in Buckets gespeichert viel Platz im Bucket viele TIDs viele

Daten zu lesen langsam (besonders für Primärschlüsselzugriff)

Ansatzpunkt der/für Erweiterungen








basiertes Grid File

7. Fazit

Agenda

Quellen, Bildnachweis

Nievergelt, J.; Hinterberger, H.; Sevcik, K.: „The Grid File: An Adaptable, Symmetric Multikey File Structure“. TODS, 9(1):38-71. 1984.

Härder, T.; Rahm, E.: „Datenbanksysteme: Konzepte und Techniken der Implementierung“. Springer Verlag. 1999.

Saake, G; Heuer, A.: „Datenbanken: Implementierungstechniken“. MITP-Verlag. 2005.

Lehner, W.: „Datenbanktechnologie für Data-Warehouse-Systeme. Konzepte und Methoden“. dpunkt.verlag, Heidelberg. 2002.

Leser, U.: „Data Warehousing“ (WWW) Zabala, S.: „Mehrdimensionale Indexstrukturen“ (Text/

Folien) Apell, M.: „The Grid File“ (Text/Folien)

Bilder teilweise an diese Werke angelehnt

http://www.informatik.hu-berlin.de/Forschung_Lehre/wbi/teaching/sose05/dbs2/

http://www-dbs.informatik.uni-heidelberg.de/teaching/ws2004/sem/ausarb_2.pdf

http://www-dbs.informatik.uni-heidelberg.de/teaching/ws2004/sem/vortrag_2.pdf

http://www.inf.uni-konstanz.de/dbis/teaching/ws0304/datatypes/download/paper-grid-file.pdf

http://www.inf.uni-konstanz.de/dbis/teaching/ws0304/datatypes/download/slides-grid-file.pdf








basiertes Grid File

7. Fazit

Agenda

Danke, dass Sie noch wach sind.

Sie können nun Fragen stellen. Oder Merchandise-Artikel kaufen.

Grid Files – Martin HaseneyerFolie 1/ 51 – 09.06.2005 Siegmundsburg Grid Files Daten hinter...

Documents

Transcript of Grid Files – Martin HaseneyerFolie 1/ 51 – 09.06.2005 Siegmundsburg Grid Files Daten hinter...