Effizientes Einfügen und Reorganisieren von grossen Datenmengen

Präsentation zum Thema: "Effizientes Einfügen und Reorganisieren von grossen Datenmengen"—  Präsentation transkript:

1 Effizientes Einfügen und Reorganisieren von grossen Datenmengen
Datawarehouse / -mining Seminarvortrag WS 1998/99 Thomas Meyer iiic 14. Januar 1999

2 Übersicht Teil I Teil II
Verschieben von Daten in Parallelen Daten-banken [AESN95] Effizientes Einfügen von Daten in Datenbanken [JNSSK97] Problemstellung OAT Algorithmus Bulk Algorithmus Vergleich OAT-Bulk Zusammenfassung Problemstellung Stepped Merge Alg. Stepped Hash Alg. Vergleich Zusammenfassung

3 Problemstellung A - H I - R S - Z L - Z A - K A - M N - Z
Die optimale Datenverteilung kann nicht vorhergesehen werden Verschiebung der Daten muss oft Online erfolgen (24h, 7d Datenbanken) Modifizierung der Indexverzeichnisse (Start-, Zielknoten) sind mit einem erheblichen Zeitaufwand verbunden. (Bsp. Sybase SQL Server: bis zu 250 Indexverzeichnisse pro Relation möglich) Parallele Datenbank A - H I - R S - Z L - Z A - K A - M N - Z Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

4 Lösungsansatz Naiver Ansatz : Verschieben jedes einzelnen Records
Kosten: löschen des Indexeintrags (Startknoten): mind. 1 random I/0 erzeugen eines neuen Indexeintrages (Zielknoten): mind. 1 random I/0 Relation Indexverzeichnis 1 Indexverzeichnis 2 Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

5 Anforderungen an Algorithmen
Updates auf die Daten sollen während der Reorganisation möglich sein Die Zeit in der Locks gehalten werden soll minimiert werden Es darf stets nur eine Kopie der Daten sichtbar sein (Konsistenz) Es gibt zu keinem Zeitpunkt Daten, die aufgrund der Reorganisation nicht gefunden werden können Erreichen einer guten Systemleistung während der Reorganisationszeit Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

6 OAT ( One At a Time page movement ) Koordinierte Verschiebung ganzer Diskseiten einer Relation von einem Startknoten zu einem Zielknoten Während der Indexmodifikation werden die Datensätze in einem speziellen Buffer gehalten (Reorganisations-Buffer) Transaktionsmanager muss in jedem Falle den Reorganisationsbuffer aufsuchen Nur für den physikalischen Transfer werden Locks auf den Daten verwendet. Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

7 Startknoten: Senden einer Seite
( One At a Time page movement ) 1.) Seite wird in den «Reorganisationsbuffer» (RB) geladen 2.) für jedes Indexverzeichnis lösche die entsprechenden Einträge: Original - Relation Indexverzeichnis (Name) 3.) Unter Verwendung eines Locks (Lock1) sende die Seite zur Dest. 4.) Warte auf Ack, gib Lock1 frei 5.) Warte auf eine Proceed Msg Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

8 Zielknoten: Ankunft einer Seite
1.) Speichern der Seite im Reorg. Buffer, sende ACK an Startknoten 2.) für jedes Indexverzeichnis der Relation führe folgenden Schritt aus: Einzufügende Seite .... 3.) Speichere die Seite vom Reorganisationsbuffer auf die Disk 4.) Sende eine Proceed Msg an Source Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

9 Update eines Attributes
Update am Startknoten Update am Zielknoten falls das Attribut schon ins Indexverzeichnis aufgenommen wurde: keine spezielle Behandlung erforderlich falls das Attribut noch nicht ins Indexverzeichnis aufgenommen wurde: update in der Sortierten Liste kein Einfügen eines neuen Indexeintrages nötig (Seite wird sogleich verschoben) kein Löschen des Indexeintrages nötig (wird durch Reorganizer sowieso erledig) Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

10 BULK - Algorithmus Alle Daten werden kopiert und auf einmal verschoben
Die Daten werden am Zielknoten eingefügt während Updates weiterhin am Startknoten erfolgen Unter Verwendung eines Locks werden die Updates vom Startknoten geholt Query Path wird danach umgeleitet Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

11 BULK - Startknoten 1.) Erstelle eine Kopie der Daten, sende sie zum Zielknoten 2.) Speichere alle Updates auf diese Daten in einem Log - File 3.) Log - File wird vom Zielknoten abgeholt 4.) Lösche die entsprechenden Indexeinträge Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

12 BULK - Zielknoten 1.) Für jedes Attribut, für welches ein Indexverzeichnis existiert: «Bulk-File» Existierendes Indexverzeichnis der Dest. insert 2.) Hole die Updates vom Startknoten unter Verwendung eines Locks 3.) ändern des Query - Paths Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

13 Update eines Attributes
Keine spezielle Behandlung erforderlich, da der Datenzugriffspfad erst geändert wird, wenn die Daten im Zielknoten komplett eingefügt worden sind Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

14 Experimenteller Vergleich
Hot Spot Size : 200 Pages (Page-Size: 2KB) Startknoten/Zielknoten : je 128 Bufferpages Totale Reorganisationszeit Anzahl Indexe Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

15 Experimenteller Vergleich
Durchschnittliche Antwortzeit Durchschnittlicher Transaktionsdurchsatz Anzahl Indexe Anzahl Indexe Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

16 Zusammenfassung Modifizierung der Indexverzeichnisse ist mit einem grossen Aufwand verbunden Die Zeit in der Locks gehalten werden muss minimiert werden OAT BULK Benötigt nur 1 zusätzliche Speicherseite Transaktionsmanager muss geändert werden i.a. besser als Bulk für Relationen mit <= 2 Indexverzeichnissen Erfordert viel zusätzlichen Speicherplatz sehr kurze Reorganisations dauer Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé

17 Teil 2: Effizientes Einfügen
Problemstellung Betrachtung von Systemen mit häufigen Insert - Operationen Insert Operationen sollen Online erfolgen Die Ankunft und Verteilung der Daten ist nicht vorhersehbar Beispiel: Erfassen von Telefongesprächen (im Gegensatz zum Erfassen von Börsenkursen) Motivation Stepped Merge Stepped Hash Vergleich Résumé

18 Naive Lösungsansätze Jeden Record einzeln einfügen:
Kosten: mind. 2 I/O Operationenen (Seite holen, zurückschreiben) pro Record bei 1 Mio Einfügeoperationen/Std müsste alle 3ms ein Record eingefügt werden können. Periodisch updaten (über Nacht): DB ist nicht aktuell («out of date») Verletzt die Forderung nach 24h/7d Datenbank in der Reihenfolge der ankommenden Datensätze organisieren Einfügen ist effizient Abfragen sind sehr ineffizient Motivation Stepped Merge Stepped Hash Vergleich Résumé

19 Anforderungen an Algorithmen
Die Anzahl Einfügeoperationen/Zeiteinheit soll maximiert werden  Minimierung der Anzahl Diskzugriffe  Daten müssen vorsortiert werden Effizientes Abfragen der Daten  Daten können gemäss beliebigem Key eingefügt werden Motivation Stepped Merge Stepped Hash Vergleich Résumé

20 Stepped Merge Algorithmus
Die ankommenden Daten werden im Memory vorsortiert. Zur Sortierung wird ein B* Baum verwendet, genannt «Run» Ist der «Run» voll, so wird er auf die Disk geschrieben als «Level 0 Run» Existieren K Runs vom Level i, so werden diese zu einem Run vom Level i+1 verschmolzen, d.h. als grösserer Baum Ist ein bestimmtes Level erreicht, so wird der gesamte Run in die DB eingefügt. Motivation Stepped Merge Stepped Hash Vergleich Résumé

21 Stepped - Merge Algorithmus
In - memory Run Level 0 Runs Level 1 Runs . . Level N-1 Run Datenbank Motivation Stepped Merge Stepped Hash Vergleich Résumé

22 Queries ..... Jedes Level hat bis zu K-1 Runs (Bsp. K=3).
aufwendige Suche: Nebst der Datenbank müssen bis zu N*(K-1) Runs durchsucht werden DB ..... Level 0 Level 1 Level 2 Motivation Stepped Merge Stepped Hash Vergleich Résumé

23 Stepped Hash Algorithmus
Memory wird in M0 Hash-Buckets aufgeteilt: (B0,0-B0,M0-1) Die ankommenden Daten werden dem Bucket B0,m mittels der Hash-Funktion m = Hashwert MOD M0 zugeordnet. Bei Ueberlauf eines Buckets Bi,j wird dieser auf die Disk verschoben und in K - Unterbuckets aufgeteilt. Daten des Buckets Bi,j werden auf die Unterbuckets Bi+1,m verteilt mittels der Hash-Funktion m = Hashwert MOD (M0*Ki+1) Level N-1 : Einfügen der Daten in die DB Motivation Stepped Merge Stepped Hash Vergleich Résumé

24 Stepped - Hash Algorithmus
B0,0 B0,1 B0,2 B0,3 Level 0 (memory) B1,0 B1,11 Level 1 . B2,35 Level 2 . Level N-1 M0 == 4 ; K == 3 Datenbank Motivation Stepped Merge Stepped Hash Vergleich Résumé

25 Concurrency Control (1)
Konsistenz: Updates auf Datensätze können in verschiedenen Levels vorkommen Lösung: Verwendung von Timestamps DB ..... Level 0 Level 1 Level 2 Motivation Stepped Merge Stepped Hash Vergleich Résumé

26 Concurrency Control (2)
Beim Verschmelzen von 2 Runs kann derselbe Datensatz doppelt gefunden werden (oder gar nicht). Naiver Ansatz: Locks auf den Runs: Shared Locks für Queries, exklusive Locks für Reorganisations-prozess besserer Ansatz: Beim Verschmelzen der Runs wird eine neue Version des Run-Indexes erstellt Level i Level i+1 Motivation Stepped Merge Stepped Hash Vergleich Résumé

27 Experimenteller Vergleich
Record Size: 20 Byte (Primary Key: 8 Byte) Page Size: 4 Kbyte Memory Buffer Size : 328 Kbyte Stepped Merge: 128 Kbyte für In Memory Run Stepped Hash: 32 Buckets am Anfang Motivation Stepped Merge Stepped Hash Vergleich Résumé

28 Experimenteller Vergleich
Stepped Merge Stepped Hash Anzahl Records in der DB Anzahl Records in der DB Motivation Stepped Merge Stepped Hash Vergleich Résumé

29 Zusammenfassung Bei häufigen Insert-Operationen muss versucht werden, die Anzahl Diskzugriffe pro einzufügenden Record zu minimieren Dies erfolgt mittels Vorsortierung der Daten und Lazy Insert Stepped Merge und Stepped Hash liegt dieselbe Idee zu Grunde, die Implementation ist jedoch verschieden Stepped Merge schneidet bei Versuchen besser ab als Stepped Hash Motivation Stepped Merge Stepped Hash Vergleich Résumé

30 Referenzen 1.Teil: 2.Teil:
[AESN95] Kiran J. Achyutuni, Edward Omiecinski, Shamkant B. Navathe «Two Techniques for On-Line Index Modification in Shared Nothing Parallel Databases», 1995 [T94] J. Troisi. «NonStop availability and database configuration operations». Tandem Systems Review, July 1994 [Vossen94] Gottfried Vossen «Datenmodelle, Datenbanksprachen, Datenbank Managment Systeme», 1994 2.Teil: [JNSSK97] H. V. Jagadish, P. P. S. Narayan, S. Seshadri, S. Sudarshan, Rama Kanneganti «Incremental Organization for Data Recording and Warehousing» 23rd VLDB Conference Athens, 1997 [OCGO96] Patrick o‘Neill, Edward Cheng, Dieter Gawlick, Elizabeth J.O‘Neill. «The Log-structured Merge Tree», Acta Informatica, 33: , 1996