Optimierung von Anfragen an verteilte Datenbanksysteme

Frank Steffen

Sebastian Muhl

Andreas Geißler

Warum Verteilung der DBS

• Dezentralisierung– Verfügbarkeit, Gesamtdurchsatz,

Lastverteilung, Kostenoptimierung

• Integration– Single-System-Image,

Konsistenzverbesserung

• Redundanz

Besonderheiten bei der Anfragebearbeitung

• lokale und globale Optimierung

• Beachtung von Parallelität und Lastverteilung

• Optimierungsaspekt: Antwortzeit

• besonders kritische und kostenintensive Operation: Join

• Aufgaben der globalen Ebene werden in Komponentensystemen gelöst

Anfragebearbeitung

• wegen Heterogenität der Komponentensysteme (KS) Aufwand bei der Bearbeitung einer globalen Anfrage größer als Anfragebearbeitung innerhalb eines DBS

• Anfragebearbeitung wird in verschiedene Phasen zerlegt

Anfragebearbeitung

• föderiertes DBS erhält globale Anfrage (GQ)• GQ wird in Teilanfragen zerlegt (SQ1, ..., SQn)• jede SQ liefert Daten, die zur Beantwortung von

GQ benötigt werden• hier Festlegung der Verknüpfungen der SQ

(Erzeugung von Postprocessinganfragen [PQ])• PQ sind festgelegte globale Operationen und

redundant gespeicherte Daten behandelt• Kontrolle über redundante Daten, so dass sie

nicht mehrfach in Endergebnis eingehen

Anfragebearbeitung

• Übersetzen der Teilanfragen in die Anfragesprachen der jeweiligen KS:– globale Anfragen müssen in Teilanfragen der

KS übersetzt werden– nicht immer möglich– dabei ergibt sich ein Problem:

• Anfragesprache des KS nicht so ausdrucksmächtig wie die der Teilanfragesprache

• Anfragesprache läßt sich nicht in äquivalente Sprache des KS übersetzen

Übersetzen der Teilanfragen

• Lösung:– globale Teilanfrage in mehrere Teilanfragen teilen.

Ergebnisse danach wieder zusammenfügen– globale in lokale Anfragen übersetzen (Lösung

entspricht nicht dem vollständigem Ergebnis)– lokale Anfrage ergibt Ergebnis, das das globale

beinhaltet. Durch Postprocessing muss noch sichergestellt werden, dass nur der Teil weiterverwendet wird, der für das Gesamtergebnis wichtig ist

Übersetzen der Teilanfragen

• Problem:– viele DBS-Sprachen besitzen keine

deklarative Sprache

• Lösung:– lokale Anwendungsprogramme, die

Teilanfragen realisieren können– vordefinierte Anwendungsprogramme, die

allgemeine Anfragen realisieren können– Nachbearbeitung durch Postprocessing auf

globaler Ebene erforderlich

lokale Bearbeitung der Teilanfragen der KS

• lokale Anfragen werden in dem KS bearbeitet• wegen Autonomie der KS kann diese lokale

Anfragebearbeitung und -optimierung nicht von globaler Ebene beeinflußt werden.– lokale Optimierung der lokalen Anfragen unabhängig

von der globalen Optimierung.

• jedes lokale Ergebnis wird an die globale Ebene zurückgegeben

Zurücksetzen der lokalen Anfrageergebnisse in das globale

Datenmodell

• transformieren eines lokalen Ergebnisses in ein Ergebnis eines globalen Datenmodells

• wenn nicht eindeutig möglich, bereits bei Übersetzung einer globalen in lokale Teilanfrage festlegen, wie das Ergebnis später transformiert werden soll

Zusammensetzen der globalen Antwort aus den lokalen Antworten

mit Postprocessing

• nur nötig, wenn Postprocessing Anfragen festgelegt wurden

• Umwandlung der Ergebnisse der globalen Teilanfragen in globale Anfragen

• Zusammensetzung in der Zerlegung festgeschrieben

Optimierung

• Nutzung von Heuristiken für eine sinnvolle Abschätzung der Ausführungszeit

• Probleme, die auf der Autonomie und Heterogenität basieren

• Optimierungsverfahren für verteilte DBS sind nicht kompatibel auf föderierte DBS Grund: Voraussetzungen sind nötig, die föderierte Systeme nicht haben

Ziele der Optimierung

• effizienter Ausführungsplan in kurzer Zeit

• wenig Seitenzugriffe bei Anfragebearbeitung

• in allen Operationen so wenig wie möglich Seiten (Tupel) berücksichtigen

• Selektionen so früh wie möglich

Ziele der Optimierung

• Basisoperationen zusammenfassen und ohne Zwischenspeicherung realisieren

• redundante Operationen, Idempotenzen oder leere Zwischenrelationen entfernen

• Zusammenfassen gleicher Teilausdrücke: Wiederverwendung von Zwischenergebnissen

1. Annahme für Optimierung in verteilten DBS

• keine Dateninkonsistenz innerhalb des Gesamtdatenbestandes (in föderierten Systemen unrealistisch)

• Komponentensysteme vor Eintritt in Föderation unabhängig– Inkonsistenzen bezüglich Daten, die in mehreren KS

gespeichert werden• Inkonsistenzen nicht oder nur teilweise erkannt

und behoben• Inkonsistenzen schwer zu entfernen, weil die

jeweiligen lokalen Anwendungen ungünstig beeinflußt werden

2. Annahme für Optimierung in verteilten DBS

• Anfrageverarbeitung und -optimierung in verteilten DBS setzt direkte Austauschbarkeit der Daten in einzelnen DBS voraus

• nur in der Import/Export-Schema-Architektur möglich

• direkte Verbindungen schränken Autonimie der KS ein

3. Annahme für Optimierung in verteilten DBS

• meist sind Charkateristiken der lokalen Systeme bekannt (auch statistische Infos)

• mit diesen Infos kann globaler Optimierer möglichst günstigen Ausführungsplan erzeugen

• globalem Optimierer stehen in föderierten Systemen diese Infos nicht zur Verfügung (wegen Autonomie)

• für bestehende DBS gibt es keine Möglichkeit über eine von außen zugängliche Schnittstelle diese Infos abzurufen

Optimierer

• Unterscheidung in:

– Lokale Optimierer

– Globale Optimierer

Lokaler Optimierer

• entscheidet über Nutzung von Indexstrukturen und Auswahl über Join-Strategie

• CPU- und E/A-Kosten (auch für globale Optimierungsentscheidungen zu berücksichtigen)

Globaler Optimierer

• besitzt keine Infos über lokale Schemaangaben der einzelnen Rechner

• bestimmt über Ausführungsfolge und Ausführungsorte der Operationen

• bestimmt die Methode des Datenaustauschs• globale Systeme: nur Kommunikationskosten

abgeschätzt• keine signifikante Einschränkung weil teuere

Kommunikation Großteil der Verarbeitungsdauer

Komponenten des Anfrageoptimiers

• Enumerator: Regeln, um alle Pläne für eine Anfrage aufzuzählen

• Kostenmodell: bewertet jeden einzelnen Plan

• Suchstrategie: versucht mit Hilfe des Enumerators, möglichst schnell guten Plan zu finden

Entscheidungen des Optimierers

• Selektionen, Projektionen, Joinordering

• Access Path Selection, d.h. welche Indexe sollen verwendet werden

• Wahl der Joinmethode

• Zwischenergebnisbehandlung (Pipelining oder Materialisierung)

Entscheidungen des Optimierers

• Replikatauswahl bei lesenden Anfragen, d.h. welche Kopie einer Partition wird verwendet

• Site Selection, d.h. wo werden die einzelnen Operationen ausgeführt

• Einsatz von speziellen verteilten Techniken

Entscheidungshilfe

• präzise quantitative Abschätzung der Bearbeitungskosten mit entsprechenden Statistiken vornehmen

• physische Aspekte der Hardwareumgebung

• vorliegende Speicherstrukturen• Zugriffspfade• unterschiedliche Implementierungsformen

für einzelne Operatoren

Woher bekommt der Optimierer die Daten?

• wichtiger Bereich: Schemaintegration• Abbildungsinformation müssen bestimmt

werden (die globalen Schemabestandteile werden den entsprechenden Schema-bestandteilen der lokalen Schemata der KS zuordnet)

• ohne Abbildungsinformationen ist es nicht möglich, globale Anfragen zu bearbeiten

Woher bekommt der Optimierer die Daten?

• alternative Quellen für bestimmte Daten, die redundant gespeichert sind, sind vorhanden

alternative Ausführungspläne können generiert werden

• keine Entscheidung möglich, welcher Weg der günstigere ist

Probleme bei Optimierung

• KS können unterschiedliche Optimierungsstrategien bei der lokalen Anfragebearbeitung einsetzen

• in Föderation mit mehreren DBS ist große Heterogenität zu erwarten

• nicht bekannt, welche Optimierungsstrategien das Komponentensystem verwendet geeignetes Verfahren gesucht

• Anfrage an ein DBS, welches Verfahren es verwendet, nicht möglich

• Testverfahren bestimmt experimentell, wie KS optimiert wird

Fazit der theoretischen Optimierung

Je mehr Informationen der globale Optimierer über die Anfrageoptimierer in den KS hat, desto besser kann er globale Ausführungspläne erstellen, in denen die jeweilige lokale Optimierung der KS vorgesehen wird. Anfragen können bei nicht optimierten vom globalen Optimierer so gestaltet werden, dass eine effiziente Ausführung durch das KS möglich ist. In derzeitigen DBS ist nur eine geringe Anfrageoptimierung möglich.

Phasen der Optimierung

• logische Optimierung

• algebraische Optimierung

• physikalische Optimierung

• kostenbasierte Auswahl

Logische Optimierung

• heuristische Methoden (algebraische Optimierung, Relationenalgebra + Gruppierung) SDD-1

• exakte Methoden (Tableauoptimierung, Anzahl Verbunde minimieren)

algebraische Optimierung

• Termersetzung von Termen der Relationenalgebra anhand von Algebraäquivalenzen

• Äquivalenzen gerichtet als Ersetzungsregeln

• heuristische Methode: Operationen verschieben, um kleinere Zwischenergbnisse zu erhalten, Redundanzen erkennen

verteilte Anfrageoptimierungsalgorithmen

• dynamisches Optimierungstiming: verteiltes INGRES

• statisches Optimierungstiming: SDD-1, R*

Verteiltes INGRES

• Dynamisches Optimierungstiming

• Minimierung der Kombination von Antwortzeit und Gesamtzeit

• Optimierungsfaktoren: Nachrichtengröße, Verarbeitungszeit (E/A- und CPU-Zeit)

• Nutzt Joins wie bei Anfrageoptimierung der jeweiligen zentralisierten DBMS

• unterstützt zusätzlich auch Fragmente

Ingres Algorithmus zur Optimierung von Verbund-Ausdrücken

• Ingres ist eines der ersten kommerziellen relationalen Datenbanksysteme aus den 80er Jahren.

• Die Optimierung ist dynamisch, d.h. während der Ausführung.

• Der Optimierer trennt von einer Anfrage zu mehreren Relationen zunächst Anfragen zu einer Relation ab und führt resultierende „1-Variablen-Anfragen“ aus.

Ingres Algorithmus zur Optimierung von Verbund-Ausdrücken

• Resultate von 1-Variablen-Anfragen können im Hinblick auf folgende Verbunde geeignet abgespeichert werden.

• Anschließend wird bei der übriggebliebenen n-Variablen-Anfrage eine Variable durch eine Tupelkonstante aus der betreffenden Relation ersetzt (tuple substitution) und weiteres Abtrennen mit anschließender Variablenersetzung probiert.

Beispiel SELECT E.NAME FROM E,G,J

WHERE E.ENo=G.ENoAND G.JNo=J.JNo

AND JName=„CAD“.

Abtrennung erzeugt: SELECT J.JNo INTO JVar FROM J WHERE JName=„CAD“. SELECT E.NAME FROM E,G,JVar WHERE E.ENo=G.ENo AND G.JNo=JVar.JNo.

Variablenersetzung E.Name=„Bill“, E.ENo=47 erzeugt: SELECT „Bill“ FROM G,JVar WHERE 47=G.ENo AND G.JNo=JVar.JNo.

Abtrennung erzeugt: SELECT G.JNo INTO GVar FROM G WHERE G.ENo=47.

SELECT „Bill“ FROM GVar,JVar WHERE GVar.JNo=JVar.JNo.

usw.

R*

• statisches Optimierungstiming

• Minimierung der Gesamtzeit

• Optimierungsfaktor: lokale Verarbeitungszeit, Nachrichtengröße, Anzahl von Nachrichten, E/A- und CPU-Kosten

• Nutzt Joins wie bei Anfrageoptimierung der jeweiligen zentralisierten DBMS

SDD-1

• statisches Optimierungstiming

• Minimierung der Gesamtzeit

• Optimierungsfaktor: Nachrichtengröße

• nutzt Semijoins als Anfrageoptimierungs-technik (mehr Infos als Join)

SDD-1

• SDD-1 ist einer der ersten Prototypen eines verteilten Datenbanksystems aus den 80er Jahren.

• Die Anfrageoptimierung beruht auf der Verwendung von Semiverbunden; Kostenmaß sind die Kommunikationskosten.

• Die Kardinalitäten der beteiligten Relationen werden mittels Semiverbunden reduziert.

SDD-1

• Die eigentliche Anfrage wird an einer Site auf den reduzierten Relationen ausgeführt.

• Kosten und Nutzen eines Semiverbundes R|

XAS:

– cost(R|XAS) = CMsg+ card([A]S) x length(A) x CTrans

– benefit(R|XAS) = (1 - SFSJ(R,S)) x card(R) x length(R) x CTrans

length(R) gibt die Länge eines Tupels in R in Byte an.

Danke

Sagen:

Frank Steffen

Sebastian Muhl

Andreas Geißler