FernUniversität in Hagen - Seminar 1912 im Sommersemester 2005

Transkript

1 FernUniversität in Hagen - Seminar 1912 im Sommersemester 2005 Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung Thema 4 Eddies: Kontinuierliche adaptive Anfrageverarbeitung Referent: Linus Stubert 30. Mai 2005

2 Linus Stubert, Thema 4: Eddies Folie 1 Übersicht Motivation: Wo liegen die Grenzen traditioneller Anfrageverarbeitungsverfahren? Eddies als Ansatz zur Überwindung der Nachteile traditioneller Verfahren: Vorstellung von Grundidee und Zielen des Einsatzes von Eddies Änderbarkeit von Anfrageplänen während der Laufzeit: Unter welchen Voraussetzungen lassen sich Anfragepläne effizient während der Laufzeit ändern? Eignung von Join-Algorithmen für den Einsatz mit Eddies: Wie gut arbeiten verschiedenen Join- Algorithmen aufgrund ihrer Eigenschaften mit Eddies zusammen? Ripple-Joins: Vorstellung eines effizienten, gut mit Eddies arbeitenden Join-Algorithmus River: Vorstellung der Programmierumgebung, in der Eddies implementiert sind Funktionsweise von Eddies: Wie werden Anfragen von Eddies verarbeitet? Mit welchen unterschiedlichen Strategien können Eddies arbeiten? Experimente zur Performance von Eddies: Vorstellung und Erläuterung der Ergebnisse diverser Performance-Tests

3 Linus Stubert, Thema 4: Eddies Folie 2 Motivation Ineffektivität traditioneller statischer Anfragebearbeitungstechniken bei großen verteilten Datenquellen hohe Bedeutung neuer Anfrageverarbeitungsmechanismen aufgrund steigender Komplexität der Daten und Unsicherheit über deren Eigenschaften Aspekte der Komplexität in großen Datensystemen: erhöhte Hardwarekomplexität und Belastung Datenkomplexität erhöhte Anforderungen an Benutzerschnittstelle Nachteile traditioneller Verarbeitungsverfahren: Erstellung eines statischen Plans zu Beginn der Anfrageverarbeitung häufig Validitätsverlust der Annahmen über Eigenschaften von Daten und Operatoren im Laufe der Bearbeitungsdauer bei Aggregationen keine Ergebnisse vor Abschluss der Anfragebearbeitung

4 Linus Stubert, Thema 4: Eddies Folie 3 Eddies: Ein Ansatz zur Überwindung der Nachteile traditioneller Verfahren Grundidee: kontinuierliche Umordnung von Operatoren auf Ebene einzelner Tupel während der Anfrageverarbeitung Ziel: Anpassung an Laufzeitfluktuationen wichtiger Variablen der Anfrageverarbeitung: Kosten von Operatoren Selektivitäten Rate, mit der Tupel aus Datenquellen ankommen

5 Linus Stubert, Thema 4: Eddies Folie 4 Änderbarkeit von Anfrageplänen während der Laufzeit Synchronisationsbarrieren: bewirken Reduktion möglicher Bearbeitungsreihenfolgen und infolgedessen auch von Nebenläufigkeit und Performance nachteilige Aspekte für Performance: Häufigkeit des Auftretens von Barrieren Differenz zwischen Ankunftszeiten der Eingangsrelationen an der Barriere symmetrische und asymmetrische Operatoren: symmetrische Operatoren: Unterscheidung der Eingangsrelationen nur aufgrund gelieferter Daten; Beispiel: Merge-Join asymmetrische Operatoren: unterschiedliche Behandlung der Eingangsrelationen; Beispiel: Nested-Loop-Join Symmetriemomente: Momente, in denen Eingangsrelationen eines Operators ohne Änderung von dessen Status umgeordnet werden können

6 Linus Stubert, Thema 4: Eddies Folie 5 Eignung von Join-Algorithmen für den Einsatz mit Eddies wünschenswerte Eigenschaften: häufige Symmetriemomente adaptive Barrieren minimale Umordnungseinschränkungen Standard-Nested-Loop-Joins: seltene Symmetriemomente unausgeglichene Barrieren Merge-Joins: Barrieren Umordnungseinschränkungen Index-Joins: vergleichbar mit Selektionen auf der nicht-indizierten Relation Ripple-Joins: hohe Effizienz häufige Symmetriemomente adaptive Synchronisationsbarrieren

7 Linus Stubert, Thema 4: Eddies Folie 6 Ripple-Joins Generalisierung traditioneller Nested-Loop-Joins kontinuierliche Vertauschung der Rollen der inneren und äußeren Relation während der Verarbeitung Bedeutung des Namens Ripple-Join : wellenartige Ausbreitung über kartesisches Produkt Abkürzung für rectangles of increasing perimeter length gute Zusammenarbeit mit Online-Aggregations-Mechanismen Ripple-Joins und Online-Aggregation: Online-Aggregation: Schätzung von Aggregaten anhand bisheriger Ergebnistupel laufende Aktualisierung der Schätzungen Anzeige der Genauigkeit durch Vertrauensintervalle Beispiel für ein Online-Aggregations-Interface Voraussetzung: zufällige Tupelreihenfolge Aktualisierung der Schätzungen extern steuerbar, z.b. durch Online-Aggregations-Interface Ripple-Joins erlauben dynamischen Tradeoff zwischen: Zeit zwischen aufeinander folgenden Aktualisierungen Betrag, um den sich der Vertrauensbereich bei jeder Aktualisierung verkleinert

8 Linus Stubert, Thema 4: Eddies Folie 7 Allgemeine Funktionsweise von Ripple-Joins Square -Ripple-Join: Auswahl je eines Tupels aus zwei Relationen R und S in jedem Schritt Join der Tupel miteinander und mit bereits vorher betrachteten Tupeln falls R S, werden nachdem alle Tupel einer Relation aufgebraucht sind nur noch Tupel aus der anderen Relation gezogen Rectangular -Ripple-Join: Auswahl von jeweils 1, 2,, K Tupeln aus den entsprechenden Relationen R 1, R 2,, R K in jedem Schritt Entartung zum Nested-Loop-Join bei K = 1, K 1 = R K 1,, 1 = R 1 bei der Online-Aggregation wird ausgehend von einer vorgegebenen unteren Geschwindigkeitsgrenze versucht, die Größe der Vertrauensintervalle durch geeignete Auswahl der Seitenverhältnisparameter zu minimieren zur schnellstmöglichen Reduktion der Vertrauensintervalle bei der Online-Aggregation ist es sinnvoll, aus variableren Relationen mehr Tupel pro Schritt zu ziehen im Allgemeinen existiert kein einzelnes Seitenverhältnis, welches die Vertrauensintervalle in jedem Schritt minimiert

9 Linus Stubert, Thema 4: Eddies Folie 8 Varianten des Ripple-Join Block-Ripple-Join: Lesen ganzer Blöcke vom Speichermedium statt einzelner Tupel in jedem Schritt Vergleich aller Tupel eines neuen Blocks mit allen bisherigen Tupeln der anderen Relation Einspar-Faktor proportional zu Blockgröße Index-Ripple-Join: schnelles Auffinden passender Tupel über Index Rollen der inneren und äußeren Relation nicht vertauschbar Seitenverhältnis nicht frei wählbar identisch mit Index-Nested-Loop-Join Hash-Ripple-Join: nur bei Equijoins anwendbar Aufbewarung der bisher betrachteten Tupel einer (oder beider) Relationen in einer Hash-Tabelle mit Join-Attribut als Hash-Wert Rückgriff auf Block-Ripple-Join sobald Hash-Tabelle nicht mehr in den Speicher passt

10 Linus Stubert, Thema 4: Eddies Folie 9 River Anfrageverarbeitungs-Engine, bei der Operatoren als unabhängige Iterator-Module realisiert sind Kommunikation der Module über festgelegten Datenfluss-Graph Module laufen als unabhängige Threads Kanten im Graph sind endliche Nachrichten-Warteschlangen wenn Erzeuger und Verbraucher mit unterschiedlichen Raten laufen, kann der schnellere Thread durch den langsameren aufgehalten werden River kann bei barrierefreie Algorithmen aus verschiedenen Eingaberelationen mit unabhängigen Raten lesen Beispiel für einen Datenflussgraphen in River

11 Linus Stubert, Thema 4: Eddies Folie 10 Funktionsweise von Eddies Eddy als Modul in River implementiert und enthält beliebig viele Eingangsrelationen einige beteiligte unäre und binäre Operatoren genau eine Ausgangsrelation Mit dem Eddy verbundene Operatoren: ein Eddy verkapselt die Ablaufplanung der mit ihm verbundenen Operatoren: im Eddy eingehende Tupel können die Beispiel für einen Eddy in River Operatoren in verschiedenen Reihenfolgen durchfließen jeder Operator hat 1 2 Eingänge, die mit Tupeln aus dem Tupelpuffer des Eddies gespeist werden Umordnung von Operatoren im Eddy insgesamt nicht auf Symmetriemomente einzelner Operatoren beschränkt Routing von Tupeln: Tupeldeskriptoren: Ready-Bits: Operatoren, die Tupel bereits bearbeitet haben Done-Bits: Operatoren, die Tupel bereits bearbeiten dürfen Tupelbuffer als Prioritätswarteschlange implementiert Effizienz des Systems durch Prioritätsschema bestimmt

12 Linus Stubert, Thema 4: Eddies Folie 11 Prioritätsschemata Simples Prioritätsschema ( naiver Eddy ): niedrige Priorität bei Betreten des Eddies hohe Priorität nach Verarbeitung durch Operator soll zügigen Durchlauf von Tupeln gewährleisten Lotterie-Prioritätsschema: Gutschrift eines Loses auf Konto des Operators bei Übergabe von Tupel an Operator Abzug eines Loses vom Konto des Operators bei Rückgabe von Tupel an Eddy Verlosung der Tupel unter allen zur Verfügung stehenden Operatoren, Gewinnchancen des Operators entsprechen der Anzahl seiner Tickets berücksichtigt neben Kosten auch Selektivitäten Fenster-Prioritätsschema: Abänderung des Lotterie-Schemas Ziel: Anpassung an Fluktuationen der Kosten/Selektivitäten Hinterlegung gutgeschriebener Tickets auf separatem Konto zu Beginn eines neuen Zeitfensters wird das Lotterie-Konto auf die Zahl der hinterlegten Tickets gesetzt und das Hinterlegungs-Konto wird auf 0 zurückgesetzt

13 Linus Stubert, Thema 4: Eddies Folie 12 Performance-Vergleich bei Selektionen Selektionen mit unterschiedlichen Kosten: Kosten von Selektion s1 variieren über Versuche von 1 bis 9 Kosten von Selektion s2 über alle Versuche = 5 Selektivitäten von s1 und s2 über alle Versuche = 50% Ergebnis: naiver Eddy fast genauso schnell wie die jeweils günstigere statische Reihenfolge Performance bei zwei 50%-Selektionen, s2 hat Kosten 5, s1 variiert über Anfragen

14 Linus Stubert, Thema 4: Eddies Folie 13 Selektionen mit unterschiedlichen Selektivitäten: Selektivität von s1 variiert über Versuche von 10% bis 50% Selektivität von s2 über alle Versuche = 50% Kosten von s1 und s2 über alle Versuche konstant Ergebnis: naiver Eddy erzielt Ergebnisse, die etwa mittig zwischen den beiden statischen Reihenfolgen liegen, der Lotterie-Eddy erzielt fast dieselben Ergebnisse wie die jeweils günstigere der beiden statischen Reihenfolgen Performance bei 2 Selektionen mit Kosten 5, s2 hat Selektivität 50%, s1 variiert über Anfragen

15 Linus Stubert, Thema 4: Eddies Folie 14 Performance-Vergleich bei Joins Vergleich bei konstanten Kosten über die Zeit: Anfrage auf 3 Tabellen: SELECT * FROM R, S, T WHERE R.a = S.a Hash-Ripple-Join AND S.b = T.b Index-Join Selektivität von R * S in Bezug auf S : prozentuelle Angabe der im Schnitt auf ein Tupel aus S passenden Tupel in R Selektivität von R S in Bezug auf S = 180% Selektivität von S T in Bezug auf S = 10% Ergebnis: Lotterie-Eddy fast so schnell wie optimaler Plan Performance bei einem Index- (Selektivität 10%) und einem Hash- Ripple-Join (Selektivität 180%)

16 Linus Stubert, Thema 4: Eddies Folie 15 Vergleich bei dynamischen Fluktuationen: Equijoin-Anfrage auf 3 Tabellen, davon zwei externen, auf denen jeweils ein Index besteht 2 Index-Joins, externe Tabellen als innere Relationen zu Beginn ist Index I_fs schnell und Index I_sf langsam Vertauschung der Geschwindigkeiten nach 30s beide Indices finden passendes Tupel in 1% der Fälle Ergebnis: Eddy mit Fenster-Schema erheblich schneller als beide statischen Pläne Performance bei 2 Index-Joins, deren Kosten sich nach 30s verändern