Interoperable Informationssysteme - 1 Klemens Böhm Systeme 2: Query Processing - Grundlagen.

Slides:



Advertisements
Ähnliche Präsentationen
Kapitel 8 Anfragebearbeitung
Advertisements

Christian Scheideler SS 2009
Kap. 13 Sweep-Line Algorithmen Kap Schnittprobleme
Kapitel 8 Anfragebearbeitung Logische Optimierung Physische Optimierung Kostenmodelle Tuning.
Dr. Brigitte Mathiak Kapitel 10 Physische Datenorganisation.
Graphen Ein Graph ist eine Kollektion von Knoten und Kanten. Knoten sind einfache Objekte. Sie haben Namen und können Träger von Werten, Eigenschaften.
Kapitel 8 Anfragebearbeitung
Bauinformatik II Softwareanwendungen 1
Übung 6.6Schranken 1.Angenommen, Ihr Algorithmus habe einen Aufwand von g(n) = 5n 3 + n für alle n a)Geben sie eine obere Schranke O(g(n)) an. b)Beweisen.
Konzeption und prototypische Implementierung eines zentralen Informationssystems für Systemmanagement Motivation Oft wird es schwierig, die benötigten.
Stefanie Selzer - Pascal Busch - Michael Kropiwoda
Anfrage-Optimierung und -Bearbeitung in Verteilten DBMS
Lehrstuhl Informatik III, DatenbanksystemeMartin Wimmer Übung zu Architektur und Implementierung von Datenbanksystemen 1 Implementierungen des Join- Operators.
Sortierverfahren Richard Göbel.
Java: Dynamische Datentypen
Sortierverfahren Richard Göbel.
FH-Hof Effizienz - Grundlagen Richard Göbel. FH-Hof Inhalt Einführung Aufwand für Anfragen ohne Indexierung Indexstrukturen für Anfragen an eine Tabelle.
Anfragesprachen – Dipl. Ing. Ulrich Borchert / FH Merseburg1/7 Datenbanken werden als Anhäufung von Werten eines Wertebereiches aufgefasst und Datenbankabfragen.
WS Algorithmentheorie 02 - Polynomprodukt und Fast Fourier Transformation Prof. Dr. Th. Ottmann.
Dynamische Programmierung (2) Matrixkettenprodukt
WS Algorithmentheorie 08 – Dynamische Programmierung (2) Matrixkettenprodukt Prof. Dr. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (27 – Kürzeste Wege) Prof. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (17 – Bäume: Grundlagen und natürliche Suchbäume) Prof. Th. Ottmann.
Union-Find-Strukturen
WS Prof. Dr. Th. Ottmann Algorithmentheorie 09 - Suche in Texten Suffix - Bäume.
Geometrisches Divide and Conquer
Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme
Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme
Übung Datenbanksysteme SQL-Anfragen (2)
– Team 2 Aktueller Projektleiter: Christian Krapp
Seminar: Verteilte Datenbanken
Einführung Dateisystem <-> Datenbanksystem
Beispielrelation Buchbestellungen H = Menge der bedeutenden Ziele = {a, d} Schwelle T = 4 Stichprobe S = {a, b, a, a, a, a} mit s = |S| = 6 N = Anzahl.
Rel-Modell Relationenspezifische Operationen (11|21) Definition: natural join (natürlicher Verbund) Geg.: zwei Relationen r 1 : (A) und.
SQL - Ausführungspläne Matthias Jauernig (03INB), Michael Lahl (03IND)
Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
EDC Entwicklerforum Geoprocessing im Web 18. Juli 2013 Benjamin Proß Ein erweiterbarer WPS Client für ArcMap.
Interoperable Informationssysteme - 1 Klemens Böhm Systeme 3: Queryoptimierung für heterogene Umgebungen.
Die Grundterminologie
LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
EXPLAIN PLAN - Erste Schritte April 2004EXPLAIN PLAN2 Was fehlt noch? Konkretes Beispiel für einen Plan.
Effiziente Algorithmen
Mit 3 Schichte zum Erfolg
Interoperable Informationssysteme - 1 Klemens Böhm Systeme 4: Query Processing in heterogenen Umgebungen.
Quantum Computing Hartmut Klauck Universität Frankfurt WS 04/
1 J4 Hash-Join R und S werden mittels der gleichen Hashfunktion h – angewendet auf R.A und S.B – auf (dieselben) Hash- Buckets abgebildet Hash-Buckets.
WS 2009/10 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #3 Das relationale Modell (Teil 2)
WS 2011/12 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #8 Anfragebearbeitung.
WS 2013/14 Datenbanksysteme D0 15:15 – 16:45 R Vorlesung #5 SQL (Teil 2)
WS 2012/13 Datenbanksysteme Fr 15:15 – 16:45 R Vorlesung #9 Anfragebearbeitung.
WS 2007/08 Datenbanksysteme Mi 17:00 – 18:30 R Vorlesung #9 Anfragebearbeitung (Teil 1)
HORIZONT 1 XINFO ® Das IT - Informationssystem PL/1 Scanner HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 / 540.
HORIZONT 1 XINFO ® Das IT - Informationssystem Assembler HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 /
Jamshid Azizi: Folie Isomorphietest Jamshid Azizi
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #9 Anfragebearbeitung.
SQL - Structured Query Language AIFB SS (1/9) Join-Operationen in SQL-92(1/9) Syntax einer Join-Operation: join-op := CROSS JOIN | [NATURAL]
SFZ FN Sj. 13/14 Python 3 Rekursion Inf K1/2 Sj 13/14
Eike Schallehn, Martin Endig
© 2001 Sven Dammann1 Aufbau Integrierter Informationssysteme XML Bearbeitung und relationale Abbildung Sven Dammann Martin-Luther-Universität Halle-Wittenberg.
WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #3 Anfragebearbeitung (Teil 1)
Analyse der Laufzeit von Algorithmen
Einführung Dateisystem <-> Datenbanksystem
WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #10 RDBMS Erweiterungen.
WS 2014/15 Datenbanksysteme D0 15:15 – 16:45 R Vorlesung #6 SQL (Teil 3)
EXPLAIN PLAN - Erste Schritte -. EXPLAIN PLAN speichert die Abfolge sämtlicher Operationen zur Ausführung eines Statements: – referenzierte Tabellen –
Vorlesung Datenbanksysteme vom Anfragebearbeitung  Logische Optimierung.
Vorlesung Datenbanksysteme vom Anfragebearbeitung 2  Architektur eines DBMS  Logische Optimierung  Physische Optimierung  Kostenmodelle.
Indexierung Oracle: indexes Indexierung.
Abfragestrategien in verteilten Systemen
 Präsentation transkript:

Interoperable Informationssysteme - 1 Klemens Böhm Systeme 2: Query Processing - Grundlagen

Interoperable Informationssysteme - 2 Klemens Böhm Interoperabilität – Architektur Wrapper Source Mediator Wrapper Source Client Wrapper Source Anfragen sind deklarativ, Ausführung muss gefunden werden. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 3 Klemens Böhm Mediatoren und Wrapper l Aufgaben des Mediators: u Parsen der Query, Query Rewrite, u Query Optimization, u Ausführung eines Teils der Anfrage, u Verwaltung des globalen Schemas. l Aufgabe des Wrappers: u Übersetzen jedes Requests des Mediators in die Sprache der zugrundeliegenden Komponente, u Übersetzen des Anfrageergebnisses ins Mediator-Format; Konformität zum globalen Schema. l Mediatoren und Wrapper sind Bestandteile der Software-Architektur. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 4 Klemens Böhm Gliederung im folgenden l Problem im folgenden: Wie geht Query Processing? l Vorgehen: u Aussagen zu Query Processing allgemein (nicht-verteilter Fall) u Query Processing im verteilten, heterogenen Fall: –Middleware für Information Integration: Harmony –Erweiterbarkeit Hinzunehmen neuer Komponenten, benutzerdefinierte, externe Funktionen, –Adaptivität. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 5 Klemens Böhm Query Processing - Schritte l Parsing: Umwandlung der Query in interne Repräsentation l Query Validation: Überprüfung, ob die Query nur zulässige Referenzen auf existierende Datenbankobjekte enthält. l View Resolution: Expandieren von Views/Integritätsbedingungen in die Query, l Optimization: Erzeugung eines ausführbaren Plans, l Plan Compilation: Umwandlung des Plans in direkt ausführbare Repräsentation, l Execution. Parsing Query Validation View Resolution Optimization Plan Compilation Execution Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell Klassisches Modell, wird später z.T. gekippt.

Interoperable Informationssysteme - 6 Klemens Böhm Algebraische Darstellung von Queries l Operatoren haben eine oder mehr Input- Mengen und erzeugen eine (oder mehr) Output-Menge(n). l Blätter entsprechen Quellen, z.B. Relationen. Get p,Person Get a,Account p.age<30 a,balance>10000 name Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell Gib mir die Namen der Personen, die jünger als 30 sind und mehr als auf einem Konto haben.

Interoperable Informationssysteme - 7 Klemens Böhm Logische u. physische Algebraausdrücke Intersection Set A Set B Merge-Join (Intersect) Sort File Scan A File Scan B l Logische Operatoren drücken aus, welches die Zwischenergebnisse sind. l Physische Operatoren geben an, wie die Queryevaluierung abläuft. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 8 Klemens Böhm Logische und physische Algebra Warum Unterscheidung? l Physical Algebra ist systemspezifisch, z.B. unterschiedliche Join-Implementierungen: Nested-Loop, Sort-Merge, Hash. l Nur Operatoren der physischen Algebra haben Kosten. Unterschiedliche Operatoren: l Weniger Operatoren auf logischer Ebene, z.B. kein Sort. D.h. Sortiertheit ist keine logische Eigenschaft, logische Sicht ist Mengen-Sicht. l Physische Operatoren implementieren mehrere oder nur Teile von logischen Operatoren (z.B. Join-Implementierung enthält Projektion, Duplicate-Removal) Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 9 Klemens Böhm Operator-Implementierung Alternativen: l set-at-a-time, l tuple-at-a-time. Set-at-a-time: - evaluiert Operatoren nacheinander. Get p,Person Get a,Account p.age<30 a,balance>10000 name Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 10 Klemens Böhm Operator-Implementierung - Tuple-at-a-Time Tuple-at-a-time implementiert Iteratorkonzept. Üblicherweise einheitliche Operationen: l open (baut beim Hash-Join z.B. Hash-Tabelle auf), next, erst next erklären, am Beispiel des -Operators l close. Get p,Person Get a,Account p.age<30 a,balance>10000 name Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 11 Klemens Böhm Operator-Implementierung - Tuple-at-a-Time (2) Iteratorkonzept - Erläuterungen: l Ergebnis und Zwischenergebnisse sind Folge von Tupeln (aber auch andere Granularität möglich), l jeder Operator implementiert Iterator über sein Zwischenergebnis, l Operator ruft Input-Operator auf, um nächsten Tupel etc. zu bestimmen. l Tuple-at-a-time ist zwar i.d.R. schneller, funktioniert aber nicht immer bei Updates. Beispiel: Erhöhe das Einkommen von den 10% der Mitarbeiter, die am wenigsten verdienen, um CHF 200,--. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 12 Klemens Böhm Meta-Operatoren Input wird nicht manipuliert, stattdessen Kontroll-Funktion: l Wechsel von einer Granularität zur anderen, Ziel: Reduzierung der Netz-Belastung. l Caching. Get p,Person Get a,Account p.age<30 a,balance>10000 Receive Send Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 13 Klemens Böhm Queryoptimierung/Querypläne Grundprobleme: l Query ist (per Definition) deklarativ, macht keine Aussagen zur Ausführungsreihenfolge. Man benötigt aber ausführbaren Plan. l Ziel ist nicht unbedingt, optimalen Plan zu finden, guter Plan reicht im allgemeinen. Optimierungszeit verlängert Gesamtdauer des Query Processing. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 14 Klemens Böhm Gängige graphische Darstellung einer (Select-Project-Join) Query (SPJ-Query), z.B. select v2.Name from p in produkt, v in verkauf, v2 in verkaeufer, g in geschaeft, s in stadt whereg.location == s and s.bundesland == bayern... Query Graph produkt verkaeufer verkauf geschaeft stadt Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 15 Klemens Böhm Join-Prädikate vs. Selektionsprädikate l Selektionsprädikat - Prädikat, das sich auf eine Relation bezieht u Beispiel: verkaeufer.name == Bischoff, u würde im Querygraph durch Zykel dargestellt, wird aber oft weggelassen, u Selektionsprädikate werden _üblicherweise_ so früh wie möglich evaluiert. produkt verkaeufer verkauf geschaeft stadt Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 16 Klemens Böhm Join-Prädikate vs. Selektionsprädikate l Join-Prädikat - Prädikat, das sich auf zwei Relationen bezieht, u entspricht Kante im Querygraph, u bei frei definierbaren Prädikaten kann Join-Prädikat sich auf mehr als zwei Relationen beziehen. produkt verkaeufer verkauf geschaeft stadt Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 17 Klemens Böhm Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell Querypläne Menge der möglichen Pläne: l left-deep vs. bushy dazwischen: Beschränkung der Tiefe des rechten Teilbaums left-deep - als Liste von Relationen darstellbar. l kartesisches Produkt oder nicht. Differenzierungen werden gebraucht für Queryplanerzeugung – was genau wird erzeugt? stadtgeschaeft verkauf produkt verkaeufer stadtgeschaeft produkt verkauf verkaeufer

Interoperable Informationssysteme - 18 Klemens Böhm Query Optimierung l Queryoptimierung := Erzeugung eines guten Queryplans, nicht in erster Linie des besten. l zentrales Problem bei Queryoptimierung: Anordnung der Joins (Join Enumeration) Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 19 Klemens Böhm Bottom-Up Query Optimierung l Schrittweises Vorgehen: Schritt k berechnet besten Plan für zusammenhängenden Teilgraphen der Grösse k.zusammenhängenden Teilgraphen l Vorgehen: Man erzeugt mehrere sog. Kandidaten-Pläne, und zwar durch Verknüpfung optimaler Teilpläne (hier im Algorithmus alle optimalen Teilpläne der Grösse k-1). l Streng genommen müsste man noch beweisen, dass Teilpläne des optimalen Plans für ihren Teilplan optimal sind. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 20 Klemens Böhm Bottom-Up Query Optimierung procedure DP: for i := 2 to n do { for all S {R 1, …, R n } s.t. ||S||=i do { bestPlan := a dummy plan w/ infinite cost for all R j, S j s.t. S = {R j } S j do { p := joinPlan(optPlan(S j ), R j ) if cost(p) cost(bestPlan) bestPlan := p} optPlan(S) := bestPlan}} return (optPlan({R 1, …, R n })) Subgraphen müssen zusammenhängend sein. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 21 Klemens Böhm Bottom-Up Query Optimierung - Erläuterungen l Algorithmus implementiert nur Join-Enumeration. l Menge der möglichen Pläne ist hartkodiert (s.b. Animation auf voriger Folie), l Bottom-up Query Optimierung = Dynamic Programming. Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 22 Klemens Böhm Kostenmodellierung l Man hat mehrere mögliche Pläne für eine Query (bzw. für eine Teilquery), muss sich für einen entscheiden. l Übliches Kriterium: Dauer der Ausführung, aber auch andere Kosten denkbar, z.B. Ressourcenverbrauch oder pekuniäre Kosten l externe Kosten apriori nicht bekannt, Schätzung (Kostenmodell) erforderlich. l Kostenmodell sollte realistisch, aber nicht zu ausgefeilt sein (Gesamtkosten = Kosten Queryoptimierung + Kosten Queryevaluierung) Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell

Interoperable Informationssysteme - 23 Klemens Böhm Sortieraufwand Kostenmodellierung - Beispiel l Nested-Loop Join ohne Indexunterstützung R1 wird stückweise eingelesen und mit R2 gejoint; Main Memory gross R2 wird nur einmal gelesen. l Sort-Merge Join, Relationen sind sortiert. l Sort-Merge Join, Relationen sind unsortiert. Anzahl Blocks, die R 1 belegt. Grösse Main Memory Motivation Query Proc. Basics Übersicht Q. Proc. log. vs. phys. Alg. Queryeval. Optimie- rungen Queryplan- erzeugung Kosten- modell.

Interoperable Informationssysteme - 24 Klemens Böhm Kostenmodellierung l Das ist nur die halbe Wahrheit: Man muss auch die Grösse des Join- Ergebnisses abschätzen, um Kosten der darauf aufbauenden Operatoren schätzen zu können, l sehr schwierig, da von der Werteverteilung in den Relationen abhängig. Motivation Query Proc. Basics -Übersicht Q. Proc. - log. vs. phys. Alg. - Queryeval. - Optimie- rungen - Queryplan- erzeugung - Kosten- modell. Infrastruktur Erweiterbar- keit 1 Erweiterbar- keit 2 Adaptivität

Interoperable Informationssysteme - 25 Klemens Böhm Plädoyer für Heuristiken für die Queryoptimierung l Anzahl der möglichen Querypläne wächst exponentiell mit der Anzahl der Join-Prädikate. l Vollständige Aufzählung der Pläne i.d.R. nur möglich für Queries mit ca. sechs Joins. l Grosse Queries kommen vor: u Datenbank-Frontends erzeugen automatisch komplexe Query-Statements, u komplexe Sichtdefinitionen, die der User i.a. nicht sieht, u OLAP-Queries. l Menge möglicher Querypläne vergrössert sich in nicht-konventionellen Szenarien. - Beispiele: u Client-Server Verteilung, u benutzerdefinierte Prädikate. l D.h. man kann in Wirklichkeit nicht alle Pläne aufzählen. Motivation Query Proc. Basics -Übersicht Q. Proc. - log. vs. phys. Alg. - Queryeval. - Optimie- rungen - Queryplan- erzeugung - Kosten- modell. Infrastruktur Erweiterbar- keit 1 Erweiterbar- keit 2 Adaptivität