Optimierung von Anfragen an verteilte Datenbanksysteme

1. Optimierung von Anfragen an verteilte Datenbanksysteme Frank Steffen Sebastian Muhl Andreas Geißler

2. Warum Verteilung der DBS • Dezentralisierung • Verfügbarkeit, Gesamtdurchsatz, Lastverteilung, Kostenoptimierung • Integration • Single-System-Image, Konsistenzverbesserung • Redundanz

3. 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

4. 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

5. 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

6. 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

7. Ü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

8. Ü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

9. 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

10. 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

11. 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

12. 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

13. 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

14. Ziele der Optimierung • Basisoperationen zusammenfassen und ohne Zwischenspeicherung realisieren • redundante Operationen, Idempotenzen oder leere Zwischenrelationen entfernen • Zusammenfassen gleicher Teilausdrücke: Wiederverwendung von Zwischenergebnissen

15. 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

16. 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

17. 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

18. Optimierer • Unterscheidung in: • Lokale Optimierer • Globale Optimierer

19. 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)

20. 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

21. 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

22. Entscheidungen des Optimierers • Selektionen, Projektionen, Joinordering • Access Path Selection, d.h. welche Indexe sollen verwendet werden • Wahl der Joinmethode • Zwischenergebnisbehandlung (Pipelining oder Materialisierung)

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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.

29. Phasen der Optimierung • logische Optimierung • algebraische Optimierung • physikalische Optimierung • kostenbasierte Auswahl

30. Logische Optimierung • heuristische Methoden (algebraische Optimierung, Relationenalgebra + Gruppierung)  SDD-1 • exakte Methoden (Tableauoptimierung, Anzahl Verbunde minimieren)

31. 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

32. verteilte Anfrageoptimierungsalgorithmen • dynamisches Optimierungstiming: verteiltes INGRES • statisches Optimierungstiming: SDD-1, R*

33. 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

34. 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.

35. 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.

36. Beispiel • SELECT E.NAME FROM E,G,J WHERE E.ENo=G.ENoAND G.JNo=J.JNoAND 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.

37. 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

38. SDD-1 • statisches Optimierungstiming • Minimierung der Gesamtzeit • Optimierungsfaktor: Nachrichtengröße • nutzt Semijoins als Anfrageoptimierungs-technik (mehr Infos als Join)

39. 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.

40. 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.

41. Danke Sagen: Frank Steffen Sebastian Muhl Andreas Geißler 