Query Optimizer in DB2 Leo & POP Learning Optimizer / Progressive Query Optimization

Query Optimizer in DB2 Leo & POP Thomas Krömer 2 Gliederung  Einleitung  Ziel  LEO Kostenberechnung Architektur Wege des Lernens  POP Architektur  Zusammenfassung

Query Optimizer in DB2 Leo & POP Thomas Krömer 3 Einleitung Datenbankmanagementsysteme sind hoch komplex, bei ihrer Konfiguration und Tuning werden tiefgreifende Kenntnisse verlangt Leo ist ein lernender Optimierer Leo und Pop nutzen das Query Feedback zum Auto-Tuning zukünftiger sowie der aktuellen Anfrage Sie sind an ein Kostenmodell geknüpft, welches gewissen Annahmen unterliegt

Query Optimizer in DB2 Leo & POP Thomas Krömer 4 Einleitung Was heißt Lernen auf dem Gebiet der Künstlichen Intelligenz? „Maschinelles Lernen bezeichnet Veränderungen in Systemen, die Anpassungsfähig sind, in dem Sinne, dass diese Systeme in der Lage sind, die gleichen oder ähnliche Probleme in einer wiederkehrenden Situation besser zu lösen.“ MECHLER [Mec95] „Intelligente Informationssysteme“

Query Optimizer in DB2 Leo & POP Thomas Krömer 5 Ziele: Verbesserung der Leistungsfähigkeit eines Systems Leistungsverhalten = Wissenserwerb und Erweiterung des bereits vorhandenen Wissens Realität adäquat abbilden

Query Optimizer in DB2 Leo & POP Thomas Krömer 6 LEO - DB2's LEarning Optimizer LEO erkennt Fehler und betreibt Ursachensuche Grundlage ist ein Kostenmodell, das den Anfrageausführungsplan bewertet (QEP = „Query Execution Plan“) Modellannahmen:  Aktualität der Informationen  Gleichverteilung der Werte  Unabhängigkeit der Prädikate  Einschließungsprinzip

Query Optimizer in DB2 Leo & POP Thomas Krömer 7 LEO - DB2's LEarning Optimizer Von der Anfrage zum Ausführungsplan 1.Anfrageübersetzung 2.Optimierung 3.Codegenerierung 4.Anfrageausführung

Query Optimizer in DB2 Leo & POP Thomas Krömer 8 LEO - DB2's LEarning Optimizer Architektur:

Query Optimizer in DB2 Leo & POP Thomas Krömer 9 LEO - DB2's LEarning Optimizer Gebrauchskomponente: Vor Erzeugung verschiedener QEP für alle Basis-Tabellen der Anfrage müssen die Selektivitätsfaktoren für jedes Prädikat berechnet werden Falls Lernen = „true“  Anpassungswerte verwendet Beispiel:

Query Optimizer in DB2 Leo & POP Thomas Krömer 10 LEO - DB2's LEarning Optimizer Planaufbewahrungskomponente: Speichert QEP und zugehörige Schätzungen des Optimierers Code-Generator liefert ein ausführbares Programm aus dem optimalen QEP In Sektion werden dabei Counter platziert und diese inkrementiert

Query Optimizer in DB2 Leo & POP Thomas Krömer 11 LEO - DB2's LEarning Optimizer Planaufbewahrungskomponente: TBScan: IXScan: NL-Join: Group By: Est: Stat: TableScan, der die gesamte Tabelle einliest und mit dem Prädikat X.Prize >= 100 filtert ein IndexScan, bei dem ein Index genutzt wird, um das jeweilige Prädikat zu erfüllen ein Nested-Loop-Join stellt den Operator für die Funktion von Group By A in der Anfrage dar geschätzte Kardinalität am Ausgang des Operators Kardinalität im Systemkatalog EST: 1140 Stat: 7200Stat: 2100 EST: 200 Stat: EST: 149EST: 1120 EST: 513 EST: 10

Query Optimizer in DB2 Leo & POP Thomas Krömer 12 LEO - DB2's LEarning Optimizer Monitorkomponente: Liest Counter aus Berechnet aktuelle Kardinalitäten (Act) darf nur einen sehr geringen Overhead erzeugen

Query Optimizer in DB2 Leo & POP Thomas Krömer 13 LEO - DB2's LEarning Optimizer Monitorkomponente: Est: Stat: Act: geschätzte Kardinalität am Ausgang des Operators Kardinalität im Systemkatalog tatsächliche Kardinalität, bestimmt durch die Monitorkomponente EST: 1140 Act: 1283 Stat: 7200 Act: 7623 Stat: 2100 Act: 3949 EST: 200 Act: 500 Stat: Act: EST: 149 Act: 133 EST: 1120 Act: 2112 EST: 513 Act: 1007 EST: 10 Act: 117

Query Optimizer in DB2 Leo & POP Thomas Krömer 14 LEO - DB2's LEarning Optimizer Analysekomponente: aktuelle Kardinalitäten (von Monitorkomponente) mit denen aus dem Skelett des korrespondierenden QEP zusammengeführt fehlerhafte Berechnungen werden erkannt, nach Ursachen dafür gesucht und Anpassungswerte gespeichert Analyse kann offline als Batch-Prozess auf dem eigenen oder auf einem fremden System oder online nach jeder ausgeführten Anfrage ablaufen

Query Optimizer in DB2 Leo & POP Thomas Krömer 15 LEO - DB2's LEarning Optimizer Berechnung der Anpassungswerte: Vergleich der aktuellen Selektivität eines Prädikates mit der geschätzten Selektivität  leitet daraus Anpassungswerte ab Wenn für ein Prädikat (z.B. col 0, 05) festgestellt wird, berechnet LEO folgendermaßen einen Anpassungswert:

Query Optimizer in DB2 Leo & POP Thomas Krömer 16 LEO - DB2's LEarning Optimizer Berechnung der Anpassungswerte: Selektivität für ein Prädikat sel(col >=x) entspricht 1 − sel(col< x) Der Anpassungswert für den Operator TBSCAN auf Tabelle X mit dem Prädikat Price >= 100 wird wie folgt berechnet:

Query Optimizer in DB2 Leo & POP Thomas Krömer 17 LEO - DB2's LEarning Optimizer Berechnung der Anpassungswerte: Anpassungswert adj für Price < 100: Berechnungen bei zukünftig ausgeführter Anfrage:

Query Optimizer in DB2 Leo & POP Thomas Krömer 18 LEO - DB2's LEarning Optimizer Zwei Wege des Lernens: Verzögertes Lernen: Es werden Korrekturwerte für die Statistiken berechnet, die zur Verbesserung zukünftiger Kostenschätzungen eingesetzt werden. „deferred learning for the futur“ Sofortiges Lernen: Während der Ausführung wird eine Suboptimalität des Ausführungsplans erkannt und Teile davon reoptimiert. Bereits berechnete Zwischenergebnisse können wieder verwendet werden. „progressive optimization“

Query Optimizer in DB2 Leo & POP Thomas Krömer 19 POP – „progressive query optimization“ Pop vergleicht während der Ausführung an „Checks“ Kardinalitätschätzungen mit den tatsächlichen Kardinalitäten Pop ist somit fähig Kardinalitäts - Schätzungsfehler in der Mitte eines QEP´s zu finden und zu Reoptimieren  liefert somit Robustheit, weil suboptimale Pläne nicht ausgeführt werden zwei Dimensionen, an denen man ein Reoptimierungsschema bewerten kann RisikoChancen Für gute Ergebnisse ist Checkpointoperator verantwortlich

Query Optimizer in DB2 Leo & POP Thomas Krömer 20 POP – „progressive query optimization“ Addiert Logik zu:  Plangenerator des Anfrageoptimierers  Checkplatzierungen  Codegenerator  „Runtime System“  Zwischenergebnisse

Query Optimizer in DB2 Leo & POP Thomas Krömer 21 POP – „progressive query optimization“ Varianten von Checks: CheckRiskenChancen Lazy CheckingSehr gering Gering, nur an Materialisierungspunkten Lazy Check with Eager MaterializationEtwas höher als Lazy CheckingAn MP und NLJN-Ausgabe Eager Checking without compensation (ECWC) Hoch Kann zu jeder Zeit während der Materialisation reoptimieren Eager Checking with Deferred compensation (ECDC) HochÜberall vor einem MP Eager Checking with buffering (ECB)HochÜberall in einem SPJ-Anfrageplan

Query Optimizer in DB2 Leo & POP Thomas Krömer 22 Zusammenfassung Forschungsergebnis: Stabilität und Konvergenz  aus dem Query Feed-Back (hartes Wissen)  aus Statistik und den Modellannahmen (unsicheres Wissen) Bei Unterschätzungen greift Leo auf unsicheres Wissen zurück Überschätzung werden sind nicht so einfach zu beheben  Um eine vernünftige Form der Stabilität zu erreichen, sollte der „autonomic optimizer“ einen Forschungsmodus am Anfang verwenden

Query Optimizer in DB2 Leo & POP Thomas Krömer 23 Zusammenfassung Wann wieder optimieren? „Immediate feedback-based learning“ Frage: Ist der aktuelle Plan suboptimal mit den neuen Kardinalitäten? Ist die Kostendifferenz groß genug für eine Reoptimierung? Zahl von Wiederoptimierungsversuchen für eine einzelne Frage beschränken „stability and convergenz“

Query Optimizer in DB2 Leo & POP Thomas Krömer 24 Zusammenfassung Lernen anderer Informationen Lernen nicht beschränkt auf Kardinalitäten und Selektivitäten Feedback Schleife kann laufende Kosten und Parameter vergleichen Feedback ist nicht beschränkt auf Dienstleistung und Mittelverbrauch (was DBMS nutzt) sondern kann auch Anwendungen dienen!

Danke für die Aufmerksamkeit!