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.ENo AND 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. 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 