Inkrementelles Einfügen von Daten
Werbung
Effizientes Einfügen und Reorganisieren von grossen Datenmengen Datawarehouse / -mining Seminarvortrag WS 1998/99 Thomas Meyer iiic 14. Januar 1999 Übersicht Teil I Teil II Verschieben von Daten in Parallelen Daten-banken [AESN95] • • • • • Problemstellung OAT Algorithmus Bulk Algorithmus Vergleich OAT-Bulk Zusammenfassung Effizientes Einfügen von Daten in Datenbanken [JNSSK97] • • • • • Problemstellung Stepped Merge Alg. Stepped Hash Alg. Vergleich Zusammenfassung Problemstellung Parallele Datenbank A-H A-K I-R S-Z L-Z 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) Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé Lösungsansatz • Naiver Ansatz : Verschieben jedes einzelnen Records Relation key L1 L2 L3 L4 L5 L6 L7 L8 Name Smith Jones Blake Clark Adams Hart Parker James Indexverzeichnis 1 Stadt KM London 20 Paris 10 Paris 30 London 20 Athen 30 Chicago 80 New York 70 Athen 25 Name Adams Blake Clark Hart James Jones Parker Smith key 5 3 4 6 8 2 7 1 Indexverzeichnis 2 Stadt Athen Chicago London New York Paris key 5,8 6 1,4 7 2,3 • Kosten: löschen des Indexeintrags (Startknoten): mind. 1 random I/0 erzeugen eines neuen Indexeintrages (Zielknoten): mind. 1 random I/0 Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé 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é 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é ( One At a Time page movement Startknoten: Senden einer Seite ) 1.) Seite wird in den «Reorganisationsbuffer» (RB) geladen 2.) für jedes Indexverzeichnis lösche die entsprechenden Einträge: Original - Relation Indexverzeichnis (Name) key Name Stadt KM L1 L2 L3 Smith Jones Blake London Paris Paris 20 10 30 L4 L5 L6 Clark Adams Hart London Athen Chicago 20 30 80 L7 L8 Parker James New York Athen 70 25 Name key Adams Adams Clark Hart Blake 3 Clark Hart James Jones Parker Smith 5 4 6 8 2 7 1 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é 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 L4 L5 L6 Clark Adams Hart London Athen Chicago Athen Chicago London Adams Clark Hart 20 30 80 .... Name key Adams Clark 5 4 de Niro Dennis Duck 12 22 15 Hart Ryan Stone Willis 6 19 24 34 3.) Speichere die Seite vom Reorganisationsbuffer auf die Disk 4.) Sende eine Proceed Msg an Source Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé Update eines Attributes Update am Startknoten Update am Zielknoten • kein Einfügen eines neuen Indexeintrages nötig (Seite wird sogleich verschoben) • kein Löschen des Indexeintrages nötig (wird durch Reorganizer sowieso erledig) • 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 Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé 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é BULK - Startknoten 1.) Erstelle eine Kopie der Daten, sende sie zum Zielknoten key L1 L2 L3 L4 L5 L6 L7 L8 Name Smith Jones Blake Clark Adams Hart Parker James Stadt KM London 20 Paris 10 Paris 30 London 20 Athen 30 Chicago 80 New York 70 Athen 25 ... .. .. ... .. .. ... .. .. key L1 L2 L3 L4 L5 L6 L7 L8 Name Smith Jones Blake Clark Adams Hart Parker James Stadt KM London 20 Paris 10 Paris 30 London 20 Athen 30 Chicago 80 New York 70 Athen 25 .. .. .. 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é BULK - Zielknoten 1.) Für jedes Attribut, für welches ein Indexverzeichnis existiert: «Bulk-File» key L1 L2 L3 L4 L5 L6 L7 L8 Name Smith Jones Blake Clark Adams Hart Parker James Stadt KM London 20 Paris 10 Paris 30 London 20 Athen 30 Chicago 80 New York 70 Athen 25 Name Adams Blake Clark Hart James Jones Parker Smith key 5 3 4 6 8 2 7 1 Existierendes Indexverzeichnis der Dest. insert Name .... ..... ..... ..... ..... key ... ... ... ... ... 2.) Hole die Updates vom Startknoten unter Verwendung eines Locks 3.) ändern des Query - Paths Einleitung OAT - Alg. BULK- Alg. Vergleich Résumé 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é Experimenteller Vergleich • Hot Spot Size : 200 Pages (Page-Size: 2KB) • Startknoten/Zielknoten : je 128 Bufferpages Totale Reorganisationszeit 12000 Zeit in Sec 10000 OAT BULK 8000 6000 4000 2000 0 0 Einleitung 1 OAT - Alg. 2 3 BULK- Alg. 4 5 Anzahl Indexe Vergleich Résumé Experimenteller Vergleich 750 700 650 600 550 500 450 Durchschnittlicher Transaktionsdurchsatz Transak./sek. Zeit (msec) Durchschnittliche Antwortzeit OAT BULK 0 1 2 3 4 5 41 39 37 35 33 31 29 27 25 O AT BULK 0 1 Anzahl Indexe Einleitung OAT - Alg. 2 3 Anzahl Indexe BULK- Alg. Vergleich Résumé 4 5 Zusammenfassung • Modifizierung der Indexverzeichnisse ist mit einem grossen Aufwand verbunden Die Zeit in der Locks gehalten werden muss minimiert werden OAT • Benötigt nur 1 zusätzliche Speicherseite • Transaktionsmanager muss geändert werden • i.a. besser als Bulk für Relationen mit <= 2 Indexverzeichnissen Einleitung OAT - Alg. BULK • Erfordert viel zusätzlichen Speicherplatz • sehr kurze Reorganisations dauer BULK- Alg. Vergleich Résumé 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é 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é 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é 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é 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é 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é Stepped Hash Algorithmus • Memory wird in M0 Hash-Buckets aufgeteilt: (B0,0B0,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é Stepped - Hash Algorithmus B0,0 B0,1 B0,2 B0,3 B1,0 Level 0 (memory) B1,11 . . . Level 1 B2,35 . . . M0 == 4 ; K == 3 Level 2 Level N-1 Datenbank Motivation Stepped Merge Stepped Hash Vergleich Résumé Concurrency Control (1) • Konsistenz: Updates auf Datensätze können in verschiedenen Levels vorkommen ..... DB Level 0 Level 1 Level 2 • Lösung: Verwendung von Timestamps Motivation Stepped Merge Stepped Hash Vergleich Résumé Concurrency Control (2) • Beim Verschmelzen von 2 Runs kann derselbe Datensatz doppelt gefunden werden (oder gar nicht). Level i Level i+1 • Naiver Ansatz: Locks auf den Runs: Shared Locks für Queries, exklusive Locks für Reorganisationsprozess • besserer Ansatz: Beim Verschmelzen der Runs wird eine neue Version des Run-Indexes erstellt Motivation Stepped Merge Stepped Hash Vergleich Résumé 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é Experimenteller Vergleich Stepped Merge 00 35 00 30 00 25 00 20 00 15 00 10 0 50 00 Anzahl Records in der DB Motivation N=2, K=2 1 0.5 0 35 00 30 00 25 00 20 00 15 00 10 50 0 1 0.5 0 Direktes Einfügen 2.5 2 1.5 0 N=2, K=2 Anzahl I/O pro Record Stepped Hash Direktes Einfügen 2.5 2 1.5 0 Anzahl I/O pro Record Stepped Merge Anzahl Records in der DB Stepped Hash Vergleich Résumé 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é Referenzen • 1.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:351-385, 1996
