Datenbanken. Prof. Dr. Ralf Möller Universität zu Lübeck Institut für Informationssysteme

Transkript

1 Datenbanken Prof. Dr. Ralf Möller Universität zu Lübeck Institut für Informationssysteme Marc Stelzner (Übungen) Torben Matthias Kempfert (Tutor) Maurice-Raphael Sambale (Tutor)

2 Anfrageoptimierung Architecture of a DBMS / Course Outline Web Forms Applications SQL Interface Webformulare Anwendungen SQL-Schnittstelle Executor Ausführer Operator Operator-Evaluierer Evaluator SQL SQL-Kommandos Commands Parser Optimizer Optimierer Transaction Files Dateiverwaltungs- and Access und Zugriffsmethoden Transaktions- Methods Manager Verwalter Buffer Puffer-Verwalter Manager Sperr- Lock Manager Verwalter Verwalter Disk Space für externen Manager Speicher data Dateien files, für Daten indices, und Indexe... Recovery Wieder- herstellungs- Manager Verwalter Database Datenbank DBMS Fall 2008 Systems Group Department of Computer Science ETH Zürich 3 this dieser Teil course des Kurses 2 Figure inspired by Ramakrishnan/Gehrke: Database Management Systems, McGraw-Hill 2003.

3 Danksagung Diese Vorlesung ist inspiriert von den Präsentationen zu dem Kurs: Architecture and Implementation of Database Systems von Jens Teubner an der ETH Zürich Graphiken und Code-Bestandteile wurden mit Zustimmung des Autors (und ggf. kleinen Änderungen) aus diesem Kurs übernommen 3

4 Anfrageoptimierung Finding the Best Query Plan SELECT FROM WHERE? 1 hash Es gibt mehr als eine Art, eine Anfrage zu beantworten Welche Implementation eines Verbundoperators? answer a given query. Welche Parameter für Blockgrößen, Pufferallokation,... Automatisch which parameters einen (block Index size, aufsetzen? buffer allocation,... )? I Die The Aufgabe, task of finding den the besten execution Ausführungsplan is, in fact, zu the finden, ist holy grail of any database implementation. der heilige Gral der Datenbankimplementierung R 1 NL I We already saw that there may be more than one way to I Which one of the join operators should we pick? With Fall 2008 Systems Group Department of Computer Science ETH Zürich 161 S T 4

5 Plan Generierung Generation eines Process Ausführungsplans SQL Parser Rewriting Optimizer Plan Parser: syntaktische und I Parser: semantische syntactical/semantical Analyse analysis I Rewriting: Umschreibung: optimizations Optimierung independent of the unabhängig current database von dem state aktuellen (table sizes, availability Datenbankinhalt of indexes, etc.) (Tabellengrößen, Verfügbarkeit I Optimizer: optimizations that rely on a eines Index,...) cost model and information about the current Optimierer: database Umformungen state auf Basis eines Kostenmodells und I The resulting plan is then evaluated by Information zum DB-Zustand the system s execution engine. Resultierender Plan wird dann ausgeführt durch Ausführungsmaschine Fall 2008 Systems Group Department of Computer Science ETH Zürich 162 5

6 Impact on Performance Finding the right plan can dramatically impact performance. Auswirkungen auf die Performanz SELECT L.L PARTKEY, L.L QUANTITY, L.L EXTENDEDPRICE FROM LINEITEM L, ORDERS O, CUSTOMER C WHERE L.L ORDERKEY = O.O ORDERKEY SELECT L.L_PARTKEY, L.L_QUANTITY, L.L_EXTENDEDPRICE FROM LINEITEM L, ORDERS O, CUSTOMER C WHERE AND L.L O.OORDERKEY CUSTKEY = O.O = C.C ORDERKEY CUSTKEY AND O.O_CUSTKEY = C.C_CUSTKEY AND AND C.CC.C_NAME = = IBM Corp. 6 mio L 6 mio mio O 1 150,000 C 1 150,000 C mio O 6 mio L I In Bezogen terms of auf execution die Ausführungszeit times, these differences können die can easily mean Unterschiede seconds Sekunden versus days. vs. Tage bedeuten Fall 2008 Systems Group Department of Computer Science ETH Zürich 163 6

7 The SQL Parser Der SQL-Parser I Besides some analyses regarding the syntactical and semantical correctness of the input query, the parser creates Neben an internal der representation syntaktischen ofund the input semantischen query. Richtigkeit I einer This representation Eingabeanfrage still resembles erzeugt the der original Parser query: eine interne Repräsentation I (Anfrageblock) Each SELECT-FROM-WHERE clause is translated into a query block. query block SELECT proj-list FROM R 1, R 2,..., R n WHERE predicate-list! GROUP BY groupby-list HAVING having-list proj-list having-list grpby groupby-list predicate-list R 1 R 2 R n Each Ri can be a base relation or another query block. I Jedes R i kann eine Basisrelation oder ein anderer Anfrageblock sein Anfrageblock Fall 2008 Systems Group Department of Computer Science ETH Zürich

8 Such nach dem besten Ausführungsplan Ausgabe des Parsers wird durch Umschreibemaschine verarbeitet, die einen äquivalenten Anfrageblock generiert inding the Best Execution Plan Aufgabe des Optimierers: Finde optimalen The parser Ausführungsplan output is fed into a rewrite engine which, again, yields a tree of query blocks. Zähle alle äquivalenten Pläne auf It is then the Bestimme optimizer s die task Qualität to come (Kosten) up with eines jeden the optimalplans execution plan for the given query. Essentially, Wähle the optimizer den/die besten als finalen Plan 1. enumerates Bevor wir all fortfahren possible execution müssen wir plans, klären 2. determines Was ist the überhaupt quality (cost) ein guter of each Plan? plan, then 3. chooses the best one as the final execution plan. Before we can do so, we need to answer the question SQL Parser Rewriting Optimizer Plan 8

9 Kostenmetriken Kostenfaktoren für einen Plan Anzahl der benötigten Platten-I/Os Kosten für vorgesehene CPU-Operationen Reaktionszeit bis zum ersten Tupel für den Benutzer Gesamtausführungszeit Abschätzung der Kosten, so dass der beste ( billigste ) Plan gefunden wird, ohne ihn tatsächlich auszuführen Kritischer Faktor: Größe der Zwischenrepräsentationen Ziel: Größe von Anfrageergebnissen möglichst genau abschätzen 9

10 Result Abschätzung Size Estimation der Ergebnisgröße Consider Betrachte a query Anfrageblock corresponding für Select-From-Where-Anfrage to a simple SFW queryq Q. proj-list predicate-list R 1 R 2 R n Abschätzung der Ergebnisgröße von Q durch We can estimate the result size of Q based on die Größe der Eingabetabellen R 1, R 2,..., R n und I the size of the input tables, R die Selektivität sel(predicate-list) 1,..., R n, and I the selectivity sel(p) of the predicate predicate-list: Q = R 1 R 2... R n sel(predicate-list) Q R 1 R 2 R n sel(predicate-list). 10

11 Tabellenkardinalitäten Die Größe einer Tabelle ist über den Systemkatalog verfügbar (hier IBM DB2) db2 => SELECT TABNAME, CARD, NPAGES db2 (cont.) => FROM SYSCAT.TABLES db2 (cont.) => WHERE TABSCHEMA = 'TPCH'; TABNAME CARD NPAGES ORDERS CUSTOMER NATION 25 2 REGION 5 1 PART SUPPLIER PARTSUPP LINEITEM record(s) selected. 11

12 Abschätzung der Selektivität Estimating Selectivities... durch Induktion über die Struktur des Anfrageblocks To estimate the selectivity of a predicate, we look at its structure. column = value sel( ) = 1 / I if there is an index I on column 1/10 otherwise sonst column 1 = column >< max{ I 1, I 2 } if there are indexes on both cols. 1 sel( ) = I >: k if there is an index only on col. k 1/10 otherwise sonst p 1 AND p 2 sel( ) =sel(p 1 ) sel(p 2 ) falls es einen Index I auf Attribut column gibt falls es Indexe auf beiden Spalten gibt falls es einen Index nur auf column gibt p 1 OR p 2 sel( ) =sel(p 1 )+sel(p 2 ) sel(p 1 ) sel(p 2 ) Fall 2008 Systems Group Department of Computer Science ETH Zürich

13 Verbesserung der Selektivitätsabschätzung Hinter den obigen Regeln stecken Annahmen Gleichverteilung der Datenwerte in einer Spalte Unabhängigkeit zwischen einzelnen Prädikaten Annahmen nicht immer gerechtfertigt Sammlung von Datenstatistiken (offline) Speicherung im Systemkatalog IBM DB2: RUNSTATS ON TABLE Meistverwendet: Histogramme 13

14 Histogramme SELECT SEQNO, COLVALUE, VALCOUNT FROM SYSCAT.COLDIST WHERE TABNAME = 'LINEITEM' AND COLNAME = 'L_EXTENDEDPRICE' AND TYPE = 'Q'; SEQNO COLVALUE VALCOUNT SYSCAT.COLDIST enthält Informationen wie n-häufigste Werte (und der Anzahl) Anzahl der verschiedenen Werte pro Histogrammrasterplatz Tatsächlich können Histogramme auch absichtlich gesetzt werden, um den Optimierer zu beeinflussen 14

15 Verbund-Optimierung Anfrage übersetzt in Graph von Anfrageblöcken Join Sieht Optimization wie ein mehrfaches kartesischen Produkt aus mit einer zusätzlichen Selektion oben drauf I We ve now translated the query into a graph of query blocks. I Abschätzung Query der blocks Kosten essentially eines are a multi-way Ausführungsplans Cartesian product with a number of selection predicates on top. Abschätzung I We can estimate der the Ergebnisgrößen cost of a given execution mit den plan. Kosten von einzelnen I Use Verbundalgorithmen result size estimates in combination für jeden with Block the cost for individual join algorithms in the previous chapter. Auflistung der möglichen Ausführungspläne, d.h. We are now ready to enumerate all possible execution plans, i.e., alle 3-Wege-Verbundkombinationen für jeden Block all possible 3-way join combinations for each query block T 1 T 1 S 1 R 1 S 1 R R S S R R T S T T R T S R 1 S 1 R 1 S 1 T 1 T 1 S T R T T S T S R S S R Fall 2008 Systems Group Department of Computer Science ETH Zürich

16 Suchraum Search Der sich Space ergebende Suchraum ist enorm groß: Schon The resulting bei 4 search Relationen space is enormous: ergeben sich 120 Möglichkeiten number of relations n C n 1 join trees , , , ,430 17,297, ,796 17,643,225,600 Noch I And nicht we haven t berücksichtigt: yet even considered Anzahl the use v der of kverschiedenen different join algorithms (yielding another factor of k Verbundalgorithmen (n 1) )! Fall 2008 Systems Group Department of Computer Science ETH Zürich

17 Wie viele Kombinationen gibt es? How Many Verbund Such über Combinations n+1 Relationen Are R 1, There?..., R n+1 benötigt n How Many Such Combinations Are There? I binäre A join over Verbunde n + 1 relations R 1,...,R n+1 requires n binary joins. I I Its root-level A join over operator n + 1 relations joins sub-plans R 1,...,R n+1 of requires k and n binary k 1joins. I Its root-level operator joins sub-plans of k and n k 1 join Der operators Wurzeloperator (0 apple k apple n 1): verbindet k und n-k-1 Verbundoperatoren operators (0 apple k apple n (0 1): k n-1) 1 1 k joins n k 1 joins k Verbunde k joins n k 1 joins R 1,...,R R 1,...,R k R k+1 k R,...,R k+1,...,r n+1 n+1 n - k - Verbunde I Sei LetI C i Let be i die Cthe i beanzahl number the number of der possibilities ofmöglichkeiten, to toconstruct um a binary einen Binärbaum tree of tree i inner of i inner nodes von nodes i (join inneren (join operators): Knoten (Verbunde) zu konstruieren: n 1X n 1 X C C n = C k C n k 1. n = C k C n k 1. k=0 k=0 Fall 2008 Systems Group Department of Computer Science ETH Zürich 173 Fall 2008 Systems Group Department of Computer Science ETH Zürich

18 Catalan Numbers Catalan-Zahlen This recurrence relation is satisfied by Catalan numbers: Rekurrenzgleichung erfüllt durch Catalan-Zahlen X n 1 C n = C k C n k 1 = (2n)! (n + 1)!n!, k=0 zur Beschreibung der Anzahl der geordneten Binärbäume mit n+1 Blättern describing the number of ordered binary trees with n + 1 leaves. For each of these trees, we can permute the input relations R 1,...,R n+1, leading to Für jeden dieser Bäume können die Eingaberelationen R 1,..., R n+1 permutiert werden, und es ergeben sich (2n)! (n + 1)!n! (2n)! (n + 1)! = n! Möglichkeiten für einen (n+1)-wege-verbund possibilities to evaluate an (n + 1)-way join. 18 Fall 2008 Systems Group Department of Computer Science ETH Zürich 174 Fall 2008 Systems Group Department of Computer Science ETH Zürich 174

19 Suchraum Search Space Der sich ergebende Suchraum ist enorm groß: The resulting search space is enormous: Anzahl number der ofrelationen relations n C n 1 #Verbundbäume join trees , , , ,430 17,297, ,796 17,643,225,600 Noch I And nicht we haven t berücksichtigt: yet even considered Anzahl the use v der of kverschiedenen different Verbundalgorithmen join algorithms (yielding (ergibt anotherneuen factor offaktor k (n 1) )! v (n-1) ) Fall 2008 Systems Group Department of Computer Science ETH Zürich

20 Dynamische Programmierung Traditioneller Ansatz, einen großen Suchraum zu beherrschen (siehe AuD-Vorlesung) Bestimme günstigsten Plan für n-wege-verbund in n Durchgängen In jedem Durchgang k bestimme den besten Plan für alle k-relationen-unterabfragen Konstruiere die Pläne aus Durchgang k aus den besten i-relationen- und (k-i)-relationen-unterplänen aus früheren Durchgängen (1 i < k) Annahme: Zur Bestimmung des optimalen globalen Plans ist es ausreichend, die optimalen Pläne der Unterabfragen zu betrachten 20

21 Beispiel: 4-Wege-Verbund Example: Four-Way Join Pass 1 (best 1-relation plans) Find the best access path to each of the R i individually (considers index scans, full table scans). Pass 2 (best 2-relation plans) For each pair of tables R i and R j, determine the best order to join R i and R j (R i 1 R j or R j 1 R i?): optplan({r i, R j }) best of R i 1 R j and R j 1 R i.! 12 plans to consider. Pass 3 (best 3-relation plans) For each triple of tables R i, R j, and R k, determine the best three-table join plan, using sub-plans obtained so far: optplan({r i, R j, R k }) best of R i 1 optplan({r j, R k }), optplan({r j, R k }) 1 R i, R j 1 optplan({r i, R k }),....! 24 plans to consider. Fall 2008 Systems Group Department of Computer Science ETH Zürich

22 Beispiel (Fortsetzung) Example (cont.) Pass 4 (best 4-relation plan) For each set of four tables R i, R j, R k, and R l, determine the best four-table join plan, using sub-plans obtained so far: optplan({r i, R j, R k, R l }) best of R i 1 optplan({r j, R k, R l }), optplan({r j, R k, R l }) 1 R i, R j 1 optplan({r i, R k, R l }),..., optplan({r i, R j }) 1 optplan({r k, R l }),....! 14 plans to consider. Insgesamt: 50 (Unter-)Pläne betrachtet (anstelle von possible 120 four-way join plans; % slide 175). 120 möglichen 4-Wege-Verbundplänen, siehe Tabelle) I Overall, we looked at only 50 (sub-)plans (instead of the I All decisions required the evaluation of simple sub-plans Alle only Entscheidungen (no need to re-evaluate basieren the interior auf vorher of optplan( )). bestimmten Unterplänen (keine Neuevaluierung von Plänen) Fall 2008 Systems Group Department of Computer Science ETH Zürich

23 Algorithmus zur Planbestimmung Dynamic Programming Algorithm Function: find join tree dp (q(r 1,...,R n )) for i = 1 to n do optplan({r i }) access plans (R i ) ; prune plans (optplan({r i })) ; for i = 2 to n do foreach S {R 1,...,R n } such that S = i do optplan(s)? ; foreach O S do optplan(s) optplan(s) [ possible joins (optplan(o), optplan(s \ O)); prune plans (optplan(s)) ; return optplan({r 1,...,R n }) ; I possible joins (R, S) enumerates the possible joins possible_joins(r, S) enumeriert alle möglichen Pläne zwischen R und S (geschachtelte-schleifen-verbund, between R and S (nested loops Misch-Verbund, join, merge...) join, etc.). I prune plans (set) discards all but the best plan from set. prune_plan(set) eliminiert alle außer den besten Plänen aus set Fall 2008 Systems Group Department of Computer Science ETH Zürich

24 Diskussion: Dynamische Programmierung finf_join_tree_dp() eliminiert Plankandidaten früh Im Beispiel wird in Durchgang 2 der Suchraum um den Faktor 2 und in Durchgang 3 um den Faktor 6 reduziert Heuristiken helfen, den Suchraum weiter zu reduzieren Vermeide kartesische Produkte Erzeuge links-tiefe Pläne (s. nächste Folie) Abwägung der Optimalität der Plan vs. Suchdauer nach dem optimalen Plan DB2 UDB: SET CURRENT QUERY OPTIMIZATION = n 24

25 Links-tiefe vs. buschige Verbundplan-Bäume Der Plangenerierungsalgorithmus Left/Right-Deep vs. Bushy Join exploriert Trees alle möglichen The algorithm on slide 179 explores all possible shapes a join tree Formen von Verbundplänen could take: left-deep bushy (everything else) right-deep Implementierte Actual systems Systeme often prefergenerieren left-deep join trees. meist 11 links-tiefe Pläne 1 I The inner relation is always a base relation. Die innere Relation ist immer eine Basisrelation I Allows the use of index nested loops join. I Easier to implement in a pipelined fashion. Bevorzugung der Verwendung von Index-Verbunden 11 The seminal System R prototype, e.g., considered only left-deep plans. Gut geeignet für die Verwendung von Pipeline- Verarbeitungsprinzipien Fall 2008 Systems Group Department of Computer Science ETH Zürich So z.b. der Prototyp von System R (IBM) 25

26 Verbund über mehrere Relationen Dynamische Programmierung erzeugt immer noch exponentiellen Aufwand Zeit: O(3 n ) Platz: O(2 n ) Das kann zu teuer sein... für Verbunde mit mehreren Relationen (10-20 und mehr) für einfache Anfragen über gut-indizierte Daten, für die ein sehr guter Plan einfach zu finden wäre Neue Plangenerierungsstrategie: Greedy-Join-Enumeration 26

27 Greedy-Join-Enumeration Greedy Join Enumeration Function: find join tree greedy (q(r 1,...,R n )) worklist? ; for i = 1 to n do worklist worklist [ best access plan (R i ) ; for i = n downto 2 do // worklist = {P 1,...,P i } find P j, P k 2 worklist and 1... such that cost(p j 1... P k ) is minimal ; worklist worklist \ P j, P k [ P j 1... P k ; // worklist = {P 1 } return single plan left in worklist ; Wähle I In each in jeder iteration, Iteration chooseden the cheapest kostengünstigsten join that can be Plan, made der über over den theverbliebenen remaining sub-plans. Unterplänen zu realisieren ist I Observe that find join tree greedy () operates similar to finding the optimum binary tree for Huffman coding. 27 Fall 2008 Systems Group Department of Computer Science ETH Zürich 185

28 Diskussion Greedy-Join-Enumeration Zeitkomplexität: O(n 3 ) Schleife: O(n) Pro Durchgang alle Paare von verbliebene Plänen betrachtet: O(n 2 ) Andere Verbund-Generierungstechniken: Randomisierte Algorithmen Zufälliges Umschreiben zusammen mit Hill-Climbing und Simulated Annealing Genetische Algorithmen Exploration des Suchraums durch Kombination von Plänen (Nachfolger) und Abänderung bestimmter Merkmale (Mutation) 28

29 Physikalische Planeigenschaften Betrachten wir die Anfrage, SELECT O.O ORDERKEY, L.L EXTENDEDPRICE FROM ORDERS O, LINEITEM L WHERE O.O ORDERKEY = L.L ORDERKEY in der Tabelle ORDERS mit einem geclusterten Index OK_IDX auf der Spalte O_ORDERKEY versehen ist Mögliche Pläne für ORDERS Absuchen der ganzen Tabelle: #I/Os = N ORDERS Absuchen des Index: #I/Os = N OK_IDX + N ORDERS Mögliche Pläne für LINEITEM Absuchen der ganzen Tabelle: #I/Os = N LINEITEM 29

30 Physikalische Planeigenschaften Absuchen der Tabellen ist jeweils günstigster Plan Verbund-Planer wird diesen Plan als günstigsten 1-Relationenplan in Durchgang 1 wählen 1 Für den Verbund beider Ausgaben gibt es: Geschachtelte-Schleifen-Verbund Hash-Verbund Sortierung + Misch-Verbund Hash-Verbund und Misch-Verbund meist bevorzugt Kosten hierfür ca. 2 (N ORDERS + N LINEITEM ) Ergibt Gesamtkosten: N ORDERS + N LINEITEM + 2 (N ORDERS + N LINEITEM ) 30 1 Dynamische Programmierung und Greedy-Join unterscheiden sich hier nicht

31 Verbesserung des Plans Ein besserer Plan liegt nahe 1. Verwende Absuchen des Index als Zugriff auf ORDERS (hierdurch ist die Ausgabe sortiert nach O_ORDERKEY) 2. Sortierte LINEITEM und 3. Berechne Verbund mittels Mischen Gesamtkosten: (N OK_IDX + N ORDERS ) + 2 N LINEITEM 1. 2./3. Obwohl teurer als Einzelplan, günstiger im Gesamtgefüge 31

32 Interessante Ordnungen Vorteil des Index-basierte Zugriffs of ORDERS: Gute physikalische Eigenschaften Optimierer verwenden Annotation für Kandidatenpläne, um auch dieses zu berücksichtigen System R hat Konzept der interessanten Ordnungen eingeführt, bestimmt durch Angaben ORDER BY oder GROUP BY in der Anfrage Verbundattribute für weitere Verbunde (Misch-Verbund) In prune_plans(), führe günstigsten ungeordneten Plan und günstigsten Plan mit interessanter Ordnung 32

33 Anfrageumschreibung Verbundoptimierung nimmt Menge von Relationen und Menge von Verbundprädikaten und bestimmt die beste Verbundreihenfolge Durch Umschreiben von Anfragegraphen im Vorwege Verbesserung der Effektivität der Optimierung Anfrageumschreiber verwendet (heuristische) Regeln, ohne den Datenbankzustand zu berücksichtigen Umschreibung von Prädikaten Entschachtelung von Anfragen 33

34 Prädikatsvereinfachung Beispiel: Schreibe SELECT * FROM LINEITEM L WHERE L.L TAX * 100 < 5 um in SELECT * FROM LINEITEM L WHERE L.L TAX < 0.05 Prädikatsvereinfachung ermöglicht Verwendung von Indexen und Vereinfacht die Erkennung von effizienten Verbundimplementierungen 34

35 Zusätzliche Verbundprädikate Implizite Verbundprädikate wie in SELECT * FROM A, B, C WHERE A.a = B.b AND B.b = C.c können explizit gemacht werden SELECT * FROM A, B, C WHERE A.a = B.b AND B.b = C.c AND A.a = C.c Hierdurch werden Pläne möglich wie (A C) B Vorher schien (A C) ein kartesisches Produkt zu sein 35

36 Geschachtelte Anfragen SQL bietet viele Wege, geschachtelte Anfrage zu schreiben Unkorrelierte Unteranfragen SELECT * FROM ORDERS O WHERE O_CUSTKEY IN (SELECT C_CUSTKEY FROM CUSTOMER WHERE C_NAME = IBM Corp. ) Korrelierte Unteranfragen SELECT * FROM ORDERS O WHERE O_CUSTKEY IN (SELECT C.C_CUSTKEY FROM CUSTOMER WHERE C.C_ACCTBAL = O.O_TOTALPRICE) 36

37 Anfrageentschachtelung Schachtelung kann teuer sein Ein unkorrelierte geschachtelte Anfrage braucht allerdings nicht immer wieder ausgewertet zu werden Häufig wird Schachtelung nur verwendet, um einen Verbund auszudrücken (oder einen Semi-Verbund) Anfrageumschreiber kann solche Verwendung entdecken und den Verbund explizit machen Dadurch kann Anfrageschachtelung durch Verbundoptimierung behandelt werden Won Kim. On Optimizing an SQL-like Nested Query. ACM TODS, vol. 7, no. 3,

38 Zusammenfassung Anfrageparser Übersetzung der Anfrage in Anfrageblock Umschreiber Logische Optimierung (unabhängig vom DB-Inhalt) Prädikatsvereinfachung Anfrageentschachtelung Verbundoptimierung Bestimmung des günstigsten Plan auf Basis eines Kostenmodells (I/O-Kosten, CPU-Kosten) und Statistiken (Histogramme) sowie Physikalischen Planeigenschaften (interessante Ordnungen) Dynamische Programmierung, Greedy-Join 38

39 Beim nächsten Mal... Architecture of a DBMS / Course Outline Web Forms Applications SQL Interface Webformulare Anwendungen SQL-Schnittstelle Executor Ausführer Operator Operator-Evaluierer Evaluator SQL SQL-Kommandos Commands Parser Optimizer Optimierer Transaction Files Dateiverwaltungs- and Access und Zugriffsmethoden Transaktions- Methods Manager Verwalter Buffer Puffer-Verwalter Manager Sperr- Lock Manager Verwalter Verwalter Disk Space für externen Manager Speicher data Dateien files, für Daten indices, und Indexe... Recovery Wieder- herstellungs- Manager Verwalter Database Datenbank DBMS Fall 2008 Systems Group Department of Computer Science ETH Zürich 3 this dieser Teil course des Kurses 39 Figure inspired by Ramakrishnan/Gehrke: Database Management Systems, McGraw-Hill 2003.