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

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

2. Gliederung • Einleitung • Ziel • LEO KostenberechnungArchitekturWege des Lernens • POPArchitektur • Zusammenfassung

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

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“

5. Ziele: • Verbesserung der Leistungsfähigkeit eines Systems • Leistungsverhalten = • Wissenserwerb und Erweiterung des bereits vorhandenen Wissens • Realität adäquat abbilden

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

7. LEO - DB2's LEarning Optimizer Von der Anfrage zum Ausführungsplan • Anfrageübersetzung • Optimierung • Codegenerierung • Anfrageausführung

8. LEO - DB2's LEarning Optimizer Architektur:

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:

10. LEO - DB2's LEarning Optimizer • Planaufbewahrungskomponente: • Speichert QEP und zugehörige Schätzungendes Optimierers • Code-Generator liefert ein ausführbares Programm aus dem optimalen QEP • In Sektion werden dabei Counter platziert und diese inkrementiert

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: 10 EST: 513 EST: 1120 EST: 149 EST: 1140 EST: 200 Stat: 23410 Stat: 7200 Stat: 2100

12. LEO - DB2's LEarning Optimizer • Monitorkomponente: • Liest Counter aus • Berechnet aktuelle Kardinalitäten (Act) • darf nur einen sehr geringen Overhead erzeugen

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: 10 Act: 117 EST: 513 Act: 1007 EST: 1120 Act: 2112 EST: 149 Act: 133 EST: 1140 Act: 1283 EST: 200 Act: 500 Stat: 23410 Act: 23599 Stat: 7200 Act: 7623 Stat: 2100 Act: 3949

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 oderonline nach jeder ausgeführten Anfrage ablaufen

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 < x) ein Fehler (|old est − act|/act > 0, 05) festgestellt wird, berechnet LEO folgendermaßen einen Anpassungswert:

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:

17. LEO - DB2's LEarning Optimizer • Berechnung der Anpassungswerte: • Anpassungswert adj für Price < 100: • Berechnungen bei zukünftig ausgeführter Anfrage:

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“

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 Reoptimierungsschemabewerten kann • RisikoChancen • Für gute Ergebnisse ist Checkpointoperator verantwortlich

20. POP – „progressive query optimization“ • Addiert Logik zu: • Plangenerator des Anfrageoptimierers • Checkplatzierungen • Codegenerator • „Runtime System“ • Zwischenergebnisse

21. POP – „progressive query optimization“ Varianten von Checks:

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

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“

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!

25. Danke für die Aufmerksamkeit!