Interoperable Informationssysteme - 1 Klemens Böhm Systeme 3: Queryoptimierung für heterogene Umgebungen.

Präsentation zum Thema: "Interoperable Informationssysteme - 1 Klemens Böhm Systeme 3: Queryoptimierung für heterogene Umgebungen."—  Präsentation transkript:

1 Interoperable Informationssysteme - 1 Klemens Böhm Systeme 3: Queryoptimierung für heterogene Umgebungen

2 Interoperable Informationssysteme - 2 Klemens Böhm Erweiterbarkeit Zwei Arten der Erweiterbarkeit: 1. Herkömmliche Anfragen im relationalen Datenmodell, Komponenten mit unterschiedlichen Fähigkeiten: u Hinzufügen neuer Komponenten, u Query-Optimizer über Komponenten und ihre Fähigkeiten informieren, u Berücksichtigung der neuen Komponenten bei Queryplanerzeugung. 2. Externe Funktionen: u Unterschiedliche Folgen von Aufrufen können äquivalent sein, u Berücksichtigung bei der Query-Planerzeugung. Ziel: Zuhörer soll die Arten der Erweiterbarkeit + Mechanismen kennen. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 Adaptivität

3 Interoperable Informationssysteme - 3 Klemens Böhm Erweiterbarkeit im Sinne von 1. l Erweiterbarkeit heisst hier: Erweiterbarkeit des Suchraums, d.h. der Menge der Pläne, die betrachtet werden. l Annahmen bezüglich des Szenarios: u Komponenten sind unterschiedlich leistungsfähig. Beispiele: –Tabelle in Spreadsheet oder RDBMS, –Daten in Informationssystem à la sbb.ch oder in (full-fledged) SQL-Datenbank. u Möglichst grossen Teil der Queries von den Komponenten ausführen lassen. l Ansatz: Garlic-Middleware, IBM Almaden, Verwendung des DB2-Query Optimizers. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

4 Interoperable Informationssysteme - 4 Klemens Böhm Abfolge l Interesting Orders, das sind Eigenschaften eines Queryplans, l Production Rules (Ansatz basiert auf Production Rules), Production Rules geben an, wie Querypläne aufgebaut sein können, l Zusammenhang Production Rules – Queryplanerzeugung, l Production Rules für externe Sourcen. Einleitung Erweiterbar- keit 1 -Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

5 Interoperable Informationssysteme - 5 Klemens Böhm Annahmen l Keine Replikation, l relationales Modell, l keine Heterogenität auf der Modellierungsebene. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

6 Interoperable Informationssysteme - 6 Klemens Böhm Properties eines Plans l Äquivalenz von Algebraausdrücken: nicht nur, welcher Teil des Querygraphen evaluiert wird, sondern auch weitere Eigenschaften des Plans – Beispiele: u Sortierung: Erster Plan ist u.U. besser, will jene Sortierung später noch einmal gebraucht werden kann. D.h. Pläne nur dann identisch, wenn auch Sortierung gleich. u Client-Server Verteilung, d.h. wo befinden sich die Tupel. Get A Sort Get B Sort Get A Get B Sort-Merge Hash Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

7 Interoperable Informationssysteme - 7 Klemens Böhm Properties eines Plans l Menge von Eigenschaften (Properties) für jeden Plan. l Property-Werte: Vergleichbarkeit von logisch äquivalenten Plänen. l Properties: u.a. Input für Kostenmodell. l Property-Vektor: erweiterbar. l Interesting Orders. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

8 Interoperable Informationssysteme - 8 Klemens Böhm Properties eines Plans mit Garlic l Relational (Was?) u TABLESMenge der zugegriffenen Tables, u COLSMenge der zugegriffenen Spalten (Projektion verringert diese Menge.) u PREDSMenge der angewendeten Prädikate, l Physikalisch (Wie?) u ORDERReihenfolge der Tupel (d.h. Liste von Spalten), u SITESite, wo sich Tupel befinden, u TEMPTRUE gdw. Tupel in Temp-Table materialisiert sind, l Geschätzt (Wieviel?) u CARDGeschätzte Anzahl von Tupeln, u COSTGeschätzte Kosten. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität Interesting Orders

9 Interoperable Informationssysteme - 9 Klemens Böhm Beispiel l Zwei Sourcen: u Lehrveranstaltungs-Datenbank, u Komponente zur Verwaltung von Emails, Komponente kann Emails zurückgeben, keine Selektion, keine Joins. l Beispielquery: l Algebra-Operatoren: u Project, Join – mit der üblichen Bedeutung, u PushDown – gibt Teilquery zur Ausführung an Komponente weiter, u Fetch extrahiert Attribute. selectm.Body fromInbox m, Classes c wherem.Subject=c.Course and c.Prof=Schek Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität D.h. wir wollen alle Mails, in denen es um Lehrveranstaltungen von Prof. Schek geht.

10 Interoperable Informationssysteme - 10 Klemens Böhm Source - gibt an, wo Output produziert wird. (zusätzliches Property, das zuvor noch nicht erwähnt wurde) Garlic-Queryplan mit Properties Tables:{Inbox m, Classes c} Columns:{m.Body} Preds:{c.Prof=Schek, m.Subject=c.Course} Source:{Garlic} Temp:false Order:NIL Tables:{Inbox m} Columns:{m.OID, m.Subject, m.Body} Preds:{} Source:{Garlic} Temp:false Order:NIL Tables:{Inbox m, Classes c} Columns:{m.OID, m.Subject, m.Body, c.OID, c.Course} Preds:{c.Prof=Schek, m.Subject=c.Course} Source:{Garlic} Temp:false Order:NIL Tables:{Inbox m} Columns:{m.OID} Preds:{} Source:{Mail} Temp:false Order:NIL Tables:{Classes c} Columns:{c.OID, c.Course} Preds:{c.Prof=Schek} Source:{DB2} Temp:false Order:NIL Project Join Fetch (m, {Subject, Body}) PushDown(Mail) PushDown(DB2) Entspricht Teilgraph des Querygraphen (vgl. Dynamic Programming) Fetch extrahiert Attribute Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität selectm.Body fromInbox m, Classes c wherem.Subject=c.Course and c.Prof=Schek

11 Interoperable Informationssysteme - 11 Klemens Böhm Erweiterbare Queryoptimierung l Motivation – noch einmal, ausführlicher: u neue Operator-Implementierung hinzunehmen, u Komponente mit bestimmten Fähigkeiten dazunehmen/wegnehmen. l Menge der möglichen Pläne darf nicht hartkodiert sein, muss explizit beschrieben werden. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

12 Interoperable Informationssysteme - 12 Klemens Böhm Production Rules l Regeln funktionieren wie Regeln einer Grammatik. l Regeln spezifizieren, wie Queryalgebra-Ausdrücke aus anderen Ausdrücken zusammengesetzt sind. l STARs - Strategy Alternative Rules. p := joinPlan(optPlan(S j ), R j ) wäre hartkodierte Regel im Dynamic Programming Algorithmus. l Andere Regel für bushy Trees. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

13 Interoperable Informationssysteme - 13 Klemens Böhm Production Rules – Beispiel l Beispiele (für Regeln, nicht für Anwendung): u JoinRoot(T 1,T 2,P) ::= NestedLoopJoin(T 1,T 2,P) u JoinRoot(T 1,T 2,P) ::= HashJoin(T 1,T 2,P) Conditions: none; Functions: none l Regeln anwendbar, bis nur noch Terminalsymbole (d.h. Algebraoperatoren, für die Implementierung existiert): NestedLoopJoin(T 1, T 2, P) ::= NLJ(FetchCols(T1, NeedAttr(T1, P)), Scan(Temp(FetchCols(T2,NeedAttr(T2,P)))), P) Conditions: none NeedAttr(Plan, Preds) ermittelt die Attribute der Kollektionen in Plan, die zur Berechnung der Prädikate in Preds gebraucht werden. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

14 Interoperable Informationssysteme - 14 Klemens Böhm Regelanwendung l Grammatik: Startsymbol und mind. eine Regel, die Ersetzung für Startsymbol definiert. l Sinngemäss gleiches Vorgehen hier: Unterschiedliche Startausdrücke (Startsymbole), die dann expandiert werden. 1. Phase - einen Startausdruck für jede Relation 2. Phase - schrittweise u ein Startsymbol (JoinRoot) für Teilgraphen des Querygraphen, dessen Teilgraphen schon analysiert wurden; u Bedingungen für Regelanwendungen erlauben einzustellen, ob bushy/linear oder ob kartesisches Produkt; u Prunen suboptimaler Teilausdrücke. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

15 Interoperable Informationssysteme - 15 Klemens Böhm Beispiel: Regeln für externe Sourcen l Beispiel hier: Join-Evaluierung durch die Sourcen. l Weitere JoinRoot-Regel: JoinRoot(T 1,T 2,P) ::= RepoJoin(T 1,T 2,P) C: keine;F: keine. l Wrapper implementiert Funktion plan_join. Sie liefert Ergebnis, wenn Wrapper Join evaluieren kann, z.B. l plan_join(T 1, T 2, P) = R_Join(T 1, T 2, P) Condition: T 1.Source = T 2.Source.Function: keine l RepoJoin(T 1, T 2, P) := p plan_join(T 1, T 2, P): PushDown(p) C: T 1.Source = T 2.Source; T 1.Source Garlic; plan_join(T 1, T 2, P) ist definiert für den Wrapper von T 1.Source. F: keine Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

16 Interoperable Informationssysteme - 16 Klemens Böhm Zusammenfassung l Production Rules beschreiben, wie Teilquery evaluiert werden kann. l Startsymbol u entspricht Teilgraph der Query, u werden nacheinander abgearbeitet, von kleinen zu grossen Queries. l Funktion plan_join u Wrapper implementiert sie, u wird aufgerufen zur Überprüfung, ob Regel anwendbar. Einleitung Erweiterbar- keit 1 - Übersicht - Interesting Orders - Production Rules - P. Rules – Q.Planerz. - externe Sourcen Erweiterbar- keit 2 Adaptivität

17 Interoperable Informationssysteme - 17 Klemens Böhm Motivation, erster Teil l Viele Szenarien erfordern Aufruf benutzerdefinierter Funktionen in Queries. l Benutzerdefinierte Funktionen enkapsulieren Zugriff auf existierende Komponenten. l Unterschied zu eben: Externe Funktionen in Queries erlaubt. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

18 Interoperable Informationssysteme - 18 Klemens Böhm Beispiel l RDBMS mit Relation Business, Attribute: ID, Name, Art des Business, Adresse, Telefon, Grösse, Gewinn, l Komponente für Spatial Data Management (d.h. geographische Daten) – Funktionen: u Map – selektiert alle Punkte der Landkarte, die Geschäften entsprechen, u Map_Restaurant – dto. Restaurants, u Inside – erwartet Punkt und rechteckiges Fenster, liefert boolschen Wert u Mapclip – erwartet Fenster, liefert Punkte, die Geschäften entsprechen. l Query: Alle Punkte zu Geschäften in gegebenem Fenster. Evaluierungsalternativen: u Map, gefolgt von Inside, u Mapclip. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

19 Interoperable Informationssysteme - 19 Klemens Böhm Beispiel 2 l Query: Alle Restaurants in Wipkingen. (Rechteck-Fenster, das Wipkingen entspricht, sei gegeben.) l Evaluierungsalternativen: u Map_Restaurant, gefolgt von Inside, u Mapclip + Zugriff auf Relation Business + Schnittmengenbildung. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

20 Interoperable Informationssysteme - 20 Klemens Böhm Motivation, Fortsetzung l Queryoptimierer braucht semantische, anwendungsspezifische Information, d.h. Anwendungsprogrammierer muss sie bereitstellen. l Beispiel: Query-Optimizer muss wissen, dass Map, gefolgt von Inside, sowie Mapclip äquivalent sind. l Spezifikation sollte möglichst einfach sein, z.B. deklarativ. l Rewrite Rules, die als Input für den Queryoptimizer dienen. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

21 Interoperable Informationssysteme - 21 Klemens Böhm Datalog-Notation (1) l Query: Selektiere alle Restaurants im Fenster w, die besser verdienen, als Grösse erwarten lässt. SQL-Statement: selectBusiness.Name, Map.Location fromBusiness, Map whereBusiness.Type = Restaurant andBusiness.ID = Map.ID andInside(w, Map.Location) andBusiness.Earning > Expected- Revenue(Business.Size) Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

22 Interoperable Informationssysteme - 22 Klemens Böhm Datalog-Notation (2) Datalog-Notation: Query(name, location) :- Business(name, Restaurant, earn, size, id), Map(id, location), Inside( w, location), Expect_Revenue(size, exp), earn > exp l Erläuterung: -Paar ist Ergebnis der Query, wenn gilt: Tupel in Business mit … Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

23 Interoperable Informationssysteme - 23 Klemens Böhm Rewrite Rules l Beispiel für Rewrite Rule – sie spezifiziert Äquivalenz von vorangegangener Folie: Map(id, loc), Inside(window, loc) -> Mapclip(id, loc, window) l Die folgenden Queries müssen also stets das gleiche Ergebnis liefern: u Q l (id, loc, window) :- Map(id, loc), Inside(window, loc) u Q r (id, loc, window) :- Mapclip(id, loc, window) Regel ist anwendbar auf Queries: Query(name, loc) :- Business(name, Restaurant, earn, size, id), Map(id, loc), Inside(w, loc), Intersect( w1, w2, w) wird zu Query(name, loc) :- Business(name, Restaurant, earn, size, id), Mapclip(id, loc, w), Intersect( w1, w2, w) Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität OK, dass andere Variablennamen.

24 Interoperable Informationssysteme - 24 Klemens Böhm Safety Constraint l Unterschied zwischen Datenbank-Relationen und Prädikaten, z.B. Business vs. Inside: Man kann alle Tupel aus Relation Business holen, man kann aber nicht explizit alle (Fenster, Punkt)-Paare bilden, die inside erfüllen. l Beide Argumente von inside müssen gebunden sein, d.h. expliziter Zugriff auf andere Relation instanziiert Variable loc. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

25 Interoperable Informationssysteme - 25 Klemens Böhm Soundness l Rewrite Rule darf keine Variable enthalten, die nur auf linker Seite vorkommt, und die auch in Literal ausserhalb der Transformationsregel vorkommt. l D.h. Regelanwendung ist sound oder nicht, nicht Regel selbst. l Beispiel: Query: Query(loc) :- Business(bname, Restaurant, earn, size, id), Map(id, loc), Owner(bname, bob ) Transformationsregel: Business(bname, Restaurant, earn, size, id), Map(id, loc) Map_Restaurant(id, loc) Nicht äquivalente Query: Query(loc) :- Map_Restaurant(id, loc), Owner(bname, bob ) l Kein Zusammenhang zwischen id und bname mehr. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules -Queryplan- erzeugung Adaptivität

26 Interoperable Informationssysteme - 26 Klemens Böhm Queryplanerzeugung l Prinzip (wird gleich verfeinert): 1. Erzeugung aller zur Ausgangsquery äquivalenten Query durch Anwenden der Rewrite Rules. 2. Planerzeugung für alle in Schritt 1 generierten Queries und Auswahl des billigsten Plans. l Regeln nicht unkontrolliert anwenden - Illustration: u Integritätsbedingung: Alle Restaurants sind im Fenster w. u Mapclip ist weniger aufwendig, wenn Fenster klein. Regel: Business(bname, Restaurant, earn, size, id), Mapclip(id, loc, window) -> Business(bname, Restaurant, earn, size, id), Mapclip(id, loc, small_win), Intersect(window, w, small_win) u Abhilfe: Dummy-Prädikate einführen. u Welches Prädikat muss umbenannt werden? Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules - Queryplan- erzeugung Adaptivität

27 Interoperable Informationssysteme - 27 Klemens Böhm Wiederverwertung optimaler Pläne l Äquivalente Queries haben i.a. identische Subqueries, l mit dem o.g. Vorgehen werden diese Subqueries mehrmals optimiert, ineffizient. l Hashtabelle, die jede Subquery auf entsprechenden optimalen Plan abbildet, als Hilfsstruktur. l Vor der Planerzeugung für jede Subquery wird die Hashtabelle konsultiert. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 - Motivation - Rewrite Rules - Queryplan- erzeugung Adaptivität

28 Interoperable Informationssysteme - 28 Klemens Böhm Queryoptimierung in verteilten, heterogenen Systemen – neue Verfahren l Variante 1: u Erzeugung mehrerer Pläne zur Compile-Zeit, unterschiedliche Pläne sind für unterschiedliche Datenbank-Zustände unterschiedlich gut. u Auswahl aus diesen Alternativen zur Laufzeit. l Variante 2: u Ausführung eines (zur Compilezeit oder Laufzeit ermittelten) Plans, u Wenn Abweichung tatsächlicher von erwarteten Kosten > gegebener Schwellenwert: Zwischenergebnis materialisieren, nochmals optimieren. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 Adaptivität

29 Interoperable Informationssysteme - 29 Klemens Böhm Berechnung der Response Time bei verteilter Query Execution (1) 1. Berechnung des Ressourcenverbrauchs jedes Operators, 2. Berechnung der Auslastung jeder Ressource durch parallele Operatoren, 3. Antwortzeit dieser parallelen Operatoren – Maximum der in 1. und 2. berechneten Zeiten. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 Adaptivität

30 Interoperable Informationssysteme - 30 Klemens Böhm Berechnung der Response Time bei verteilter Query Execution (2) Beispiel: l Annahmen: u Jeder Join kostet 200 s CPU-Zeit, u Shipping eines Join-Ergebnisses kostet 130 s, u alle weiteren Kosten sind Null. l Alternativen dauern 600 s bzw. 200 s. Einleitung Erweiterbar- keit 1 Erweiterbar- keit 2 Adaptivität join A B C D display join A B C D display join A D C B display Plan zur Compile-Zeit Plan 1 Plan 2