Optimierung von Anfragen an verteilte Datenbanksysteme

Präsentation zum Thema: "Optimierung von Anfragen an verteilte Datenbanksysteme"—  Präsentation transkript:

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

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 