Query Optimizer in DB2

Leo & POPLearning Optimizer / Progressive Query Optimization

2

Query Optimizer in DB2Leo & POP

Thomas Krömer

Gliederung

Einleitung Ziel LEO

KostenberechnungArchitekturWege des Lernens

POPArchitektur

Zusammenfassung

3

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

Ziele:

• Verbesserung der Leistungsfähigkeit eines Systems

Leistungsverhalten =

• Wissenserwerb und Erweiterung des bereits vorhandenen Wissens

• Realität adäquat abbilden

6

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

LEO - DB2's LEarning Optimizer

Von der Anfrage zum Ausführungsplan

1. Anfrageübersetzung

2. Optimierung

3. Codegenerierung

4. Anfrageausführung

8

Query Optimizer in DB2Leo & POP

Thomas Krömer

LEO - DB2's LEarning Optimizer

Architektur:

9

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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: 7200 Stat: 2100

EST: 200

Stat: 23410

EST: 149EST: 1120

EST: 513

EST: 10

12

Query Optimizer in DB2Leo & POP

Thomas Krömer

LEO - DB2's LEarning Optimizer

Monitorkomponente:

• Liest Counter aus

• Berechnet aktuelle Kardinalitäten (Act)

• darf nur einen sehr geringen Overhead erzeugen

13

Query Optimizer in DB2Leo & POP

Thomas Krömer

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: 1140Act: 1283

Stat: 7200Act: 7623

Stat: 2100Act: 3949

EST: 200Act: 500 Stat: 23410

Act: 23599

EST: 149Act: 133

EST: 1120Act: 2112

EST: 513Act: 1007

EST: 10Act: 117

14

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

LEO - DB2's LEarning Optimizer

Berechnung der Anpassungswerte:

• Anpassungswert adj für Price < 100:

• Berechnungen bei zukünftig ausgeführter Anfrage:

18

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Risiko Chancen

• Für gute Ergebnisse ist Checkpointoperator verantwortlich

20

Query Optimizer in DB2Leo & POP

Thomas Krömer

POP – „progressive query optimization“

Addiert Logik zu:

Plangenerator des Anfrageoptimierers

Checkplatzierungen

Codegenerator

„Runtime System“

Zwischenergebnisse

21

Query Optimizer in DB2Leo & POP

Thomas Krömer

POP – „progressive query optimization“

Varianten von Checks:

Check Risken Chancen

Lazy Checking Sehr geringGering, nur an Materialisierungspunkten

Lazy Check with Eager Materialization Etwas höher als Lazy Checking An MP und NLJN-Ausgabe

Eager Checking without compensation(ECWC)

HochKann 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

22

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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

Query Optimizer in DB2Leo & POP

Thomas Krömer

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!