Logische Optimierung verteilter Anfragen

Transcription

Informationsintegration
Logische Optimierung verteilter
Anfragen
Ulf Leser
Wissensmanagement in der
Bioinformatik
Gestern - Heute
Ulf Leser: Informationsintegration, Wintersemester 2006/2007
2
Minicon
[PL01]
• Idee
• Probleme beim BA machen vor allem Joins in der Benutzeranfrage
• Sind die in einem Plan?
• Kann man sie in einem Plan erzwingen?
• Werden die notwendigen Variablen exportiert?
• Diese Beobachtung nutzt MiniCon, um
• Kleinere Buckets zu bauen – manche Views kann man früh
auszuschließen
• Weniger Pläne aufzuzählen – die „Building Blocks“ werden größer
• Grundaufbau wie BA
• Buckets pro Literal der Query, partielle CM, UNION, …
• Aber im Grunde werden dann problematische Joins der Reihe nach
behandelt, nicht Literale
3
Kleinere Buckets
• Sei v ein View für Literal l mit partiellem CM h: l→k
• Wenn l in q einen Join über Variable X mit Literal l‘ macht,
und X in k nicht exportiert wird (also auch nicht in l)
•
Wenn !∃k‘∈v: Füge v nicht in Bl ein
• Der BA würde den einfügen
• Aber wir können den Join über X niemals herstellen
• „Vorausschau“
•
Wenn ∃k‘∈v und der Join über X ist nicht in v: Füge v nicht in Bl ein
• Der BA würde den einfügen
• Aber wieder – der Join kann in keinem Plan mit v hergestellt werden
•
Sonst: Füge v in Bucket Bl ein
• Merke außerdem das Literal k‘, das mit k über X gejoined wird
• Wenn v X nicht exportiert, müssen k und k‘ in jedem Plan mit v von v abgedeckt
werden
• Das muss beim Aufzählen berücksichtigt werden
4
Bewertung
• Wenn alle Variable exportiert werden, macht
Minicon das gleiche wie der BA
• Minicon gilt als derzeit schnellster AQUV
Algorithmus
• Problem: Welche Anfragen soll man zum Messen
benutzen?
•
•
•
•
Was ist ein Average Case für Anfragen?
Chain queries: r1(X…), r2(X…Y…), r3( Y…Z…), …
Star queries: r1(X…), r2(X…), r3(X…), …
Complete queries: r1(X,Y,Z…), r2(X,Y,Z…), r3(X,Y,Z…), …
5
Inverse Rules
• Gänzlich andere Herangehensweise
• Beobachtung
• Jeder View auf das globale Schema „liefert“ Informationen für jede
Relation im View
• Wir fassen diese Informationen in einer Regel pro Literal jedes
Views zusammen
• Kopf der Regel ist das Literal
• Rumpf der Regel ist der Kopf des Views
• Inverse Rules –Views werden zu Regeln umgedreht
• Beispiel:
V3(F,H) :- cites(F,G),cites(G,H),sametopic(F,G)
• cites(F,?) :- V3(F,H)
• cites(?,H) :- V3(F,H)
• sametopic(F,?) :- V3(F,H)
• Problem: Nicht-exportierte Variable und Joins
6
Planung mit Inverse Rules
• Wir interpretieren die Regeln als „externe“
Datalog-Regeln
• Die Instantiierungen (Ground-Fakten) liegen in den Quellen
• Durch Ausführen einer Regel können wir sie berechnen
• Die Anfrage q können wir einfach als Programm
auf diesen Regeln laufen lassen
• Der Rest ist PROLOG / DATALOG
• Unifikation der Variablen und Konstanten
• Gleiche Skolemterme dürfen unifiziert werden
• Skolemterme dürfen nicht als Ergebnis zurückgegeben werden
7
Bewertung
• Erzeugt in polynomialer Zeit ein DatalogProgramm mit polynomial vielen Regeln
• Wo ist unsere exponentielle Komplexität?
• Der Ableitungsbaum ist exponentiell groß
• Jedes Blatt im Ausführungsbaum entspricht einem Plan
• Das Programm ist eine kompakte Repräsentation exponentiell vieler
Anfragepläne
• Ausführung und Planung sind verschränkt
• Man führt erst schon Anfragen aus, obwohl man die Tupel am
Ende unter Umständen nicht braucht (z.B. V4)
• Regeln werden in verschiedenen Ästen des Ableitungsbaums
mehrmals ausgeführt - Caching
8
Problems with the BA
• Expensive
• Planning: Exponential number of potential plans
• Execution: Potentially exponential number of queries
Who needs all plans?
9
Our solution: 1. Preparation
Annotate correspondences with information quality:
Mediator
(90,0.5...)
(46,0.7...)
(60,0.3...)
(99,0.5...)
(12,0.1...)
(23,0...)
Wrapper
Wrapper
Wrapper
Data source
Data source
Data source
10
2. Source selection
Use IQ scores to remove the worst sources:
Mediator
(90,0.1...)
(46,0.2...)
(60,0.3...)
(99,0.5...)
(12,0.1...)
(23,0...)
Wrapper
Wrapper
Wrapper
Data source
Data source
Data source
11
3. Query planning
Compute all plans:
User
query q
p1 := q1,q2,q3,q4,...
Mediator
p2 := q3,q5,q6,q7,...
p3 := q1,q3,q5,q9,...
etc.
Wrapper
Wrapper
12
4. Plan selection
Use IQ scores to find the best plans:
Mediator
(90,0.1...)
(46,0.2...)
Wrapper
(60,0.3...)
(99,0.5...)
p1 := q1,q2,q3,q4,...
3
p2 := q3,q5,q6,q7,...
1
p3 := q1,q3,q5,q9,...
2
etc.
Wrapper
IQ(p1) = (60,0.3...)
(46,0.2...)
...
13
IQ criteria can be ...
• Source-specific • Corresp.-specific • Attribute-specific
•
•
•
•
Understandability
Reputation
Reliability
Timeliness
Phase 1
Source
selection
•
•
•
•
•
•
Availability
Price
Repr. consistency
Response time
Accuracy
Relevancy
Phase 2
Query
planning
- Completeness
- Amount
Phase 3
Plan
selection
14
Phase 3: Plan selection
• Goal: Find best N plans
• Three steps for each plan
1. Determine attribute-specific IQ scores
⇒ Complete IQ vector per view
2. Aggregate the IQ scores along the plan
⇒ Complete IQ vector per plan
3. Find overall IQ score
⇒ IQ scalar per plan
Query
planning
Output
Quality-ranked
plans
Phase 3
Plan
selection
15
Step 2: Aggregate IQ scores
Merge functions:
•
•
•
•
•
Availability:
Price:
Response time:
Completeness:
...
*
+
max
Sylvester
Plan P3
(89.35,0,1,1,99.8,28.8,76.06,3)
merge
(94.05,0,1,1,99.85,48,54.86,0)
merge
v6
(95,0,0.7,1,99.95,60,48.2,0)
v7
(95,0,0.7,1,99.95,60,38,3)
v2
(99,0,1,0.2,99.9,80,52.8,0)
16
Discussion
• Fine-grained IQ score assignments
• per source, per query and per attribute
• selection and classification of criteria
• Quality as “cost”
• different levels
• merge functions
• Improvements
• Branch & bound algorithm: Prune growing plans when they become
too bad (compared to the current top N plans)
17
LaV – Anwendungen
• Datenintegration
• Datenquellen als Sichten auf globales (Mediator) Schema
• Anfrageoptimierung
• Materialisierte Sichten auf Datenbankschema
• Datawarehouse Design
• Materialisierte Sichten auf Warehouse-Schema
• Semantisches Caching
• Materialisierte Daten beim Client
18
Inhalt dieser Vorlesung
• Optimierungsziele in der Informationsintegration
• Logische Optimierung
• Plan Minimierung
• Multiple Query Optimization
19
Klassische Anfrageoptimierung
• Zentrale relationale Datenbanken
•
•
•
Eine Anfrage – viele Anfragepläne
Alle Anfragepläne berechnen dasselbe Ergebnis
Optimierung: Berechne dieses Ergebnis in möglichst kurzer Zeit
• Methoden
•
•
•
•
•
Algebraische Umformungen
Pushen von Selektionen und Projektionen
Access path selection (Indexe)
Join-Methoden, Sortierung
Join-Order durch dynamische Programmierung
• Heuristiken
•
•
•
•
Zeit hängt im wesentlichen vom IO Zugriff ab
IO-Zugriffskosten hängen von der Datenmenge ab
Also: Minimiere die insgesamt zu bewegende Datenmenge
(Was ignorieren wir dabei alles?)
20
Optimierung in der Informationsintegration
• Unterschiede zu zentralen RDBMS
1. Viele heterogene Quellen – wollen wir immer alle benutzen?
2. Netzwerkzugriff – Daten kommen nicht von der Platte, sondern
über das Netz
3. Beschränkte, technisch heterogene Quellen
4. Zwei Stufen: Optimierung in der Integrationsschicht, Optimierung
in jeder Quelle
• Unterschiede zu verteilten Datenbanken
•
•
•
•
Verteilte DB können Verteilung optimieren (Data Placement)
Hier: Verteilung und Redundanz ist unkontrolliert
Hier: Oftmals keine (guten) Statistiken verfügbar
Hier: Datenbestände und Quellen ändern sich häufig
21
Viele Quellen
• Viele Quellen
• Lange Wartezeiten
• Quellen fallen aus – Time-Outs & Replanning
• Hohe Kosten, viele Verbindungen
• Quellen überlappen extensional und intensional
• Für Unions: Eine Quelle fragen reicht
• Für Joins: Ohne Überlappung ist das Ergebnis leer
• Ergebnisumfang und –güte wächst i.A. nicht linear
mit der Menge der benutzen Quellen
• Umfang: Menge Tupel / Menge Attribute / Menge nicht-null Werte
• Güte: Wenig Fehler, vollständige Ergebnisse
22
Trade-Off
• Abwägung
Ergebniskosten / Wartezeit
• Kosteneinsatz pro
• Ergebnisverbesserung
• Problem
Ergebnisgüte
• Man kann meistens beides
nur schätzen
• Alternative Optimierungsziele
Anzahl Quellen
• Berechne alles in minimaler Zeit
• Berechne alles mit der minimalen Anzahl an Anfragen
• Berechne alles mit der minimalen Menge an zu übertragenden Daten
• Finde die besten k Pläne
• Finde die k Pläne, die zusammen das beste Ergebnis liefern
• Benötigt Abschätzungen über die ext. Überlappung zwischen Plänen
• Finde die Pläne, die das beste Ergebnis liefern zu max. Kosten c
23
Netzwerkzugriff
• Kostenmodelle müssen beinhalten
• Kosten für den Aufbau der Verbindung (Latenzzeit)
• Finden der Quellen im Netz (DNS etc.)
• Quelle erzeugt Prozess, reserviert Puffer etc.
• Kosten für den Datentransport (möglicher versus realer Durchsatz)
• Daten kommen bursty – schwierig für Pipelineing
• Kosten für die Berechnung der Daten in der Quelle
• Kosten für die Nachbearbeitung der Daten im Mediator
• Eventuell Koordinationskosten zwischen Quellen
• Konkrete Kosten hängen vom Typ der Quelle ab
• Datenbankserver: Prozess aufbauen
• Webdatenquelle: HTTP Verarbeitung, CGI Skript, …
• Legacy Datenquelle: Programm starten, Report generieren, aus
Datei lesen
24
Beschränkte Quellen
• Quellen können (oder wollen) nicht alles, was sich der
Mediator wünscht
•
•
•
•
Ausführungsautonomie
Pushen von Operationen nicht möglich
Pipelining nicht möglich (Webseiten, Webservices)
…
• Muss bei der Optimierung beachtet werden
•
Sind erzeugte Ausführungspläne überhaupt ausführbar?
• Zum Teil steckt das in den Korrespondenzen
•
•
•
Die lokale Anfrage muss laut Definition ausführbar sein
Das ist immer eine Fall-Back Position
Aber Potential geht verloren (z.B: Pushen eines Joins zu einer Quelle)
• Spezielles Problem: Binding Pattern (später)
25
Zwei-stufige Optimierung
• Mediator braucht Kenntnisse
über Quellen
•
•
Globale Statistiken
Datenbestand
• Insb. für den Vergleich von Quellen
•
•
Selektivität, Verteilung
Funktionalität
• Lokale Anfragen werden noch
mal optimiert
•
•
•
•
Quelle führt lokale Statistiken
Bei Abweichungen werden die globalen
Schätzungen nicht erreicht
Neuplanung während der Ausführung
Inline-Anpassung globaler Statistiken
26
27
Globale Anfrageoptimierung
• Zur Erinnerung
• result(q) = ∪ result(p)
= p1 ∪ p2 ∪ … ∪ pn
(v11 ⋈ v12 ⋈ … ⋈ v1n) ∪
(v21 ⋈ v22 ⋈ … ⋈ v2n) ∪
… ∪
(vm1 ⋈ vm2 ⋈ … ⋈ vmn)
• Die vij sind idR nicht unterschiedlich, sondern Views
kommen öfters vor
• Globale Optimierung
•
•
•
Finde die minimale Menge von Ausführungen von v‘s, die result(q)
berechnet
Optimiert alle Anfragepläne auf einmal
Optimiert die disjunktive Normalform von result(q)
28
Techniken
• Redundante Views in Anfragepläne finden
• Anfrageminimierung
• Klassisches DB Problem
• Versuche, Views aus dem Plan zu entfernen und beweise
Containment/ Äquivalenz der Pläne
• Redundante Pläne entfernen
• Pläne, die nichts neues zum Ergebnis beitragen können
• Gesamtzahl von Viewausführungen minimieren
• Betrachte Teilpläne
• Finde und entferne doppelte Teilpläne
• Caching
29
Redundante Anfragepläne
• Definition
Sei q eine Benutzeranfrage und P die Menge aller
semantisch korrekten Anfragepläne für q. Ein Plan
p∈P ist redundant, wenn
U result (k ) ⊆ U result (k )
k∈P
k∈P \ p
• Bemerkung
• Offensichtlich tragen redundante Pläne nicht zum Ergebnis bei
• Die können wir also ignorieren
• Erste Idee: p ist redundant, wenn ∃p‘∈P: p⊆p‘
• Was heißt denn überhaupt: p⊆p‘ ?
30
Wrapperanfragen analysieren
• Beispiel
•
•
•
v1: film(T,R) :- doku(T,R)
v2: film(T,R) :- spielfilm(T,R)
q: film(T,R)
•
p1≡p2, aber beide sollten zur Beantwortung von q benutzt werden
• Die lokalen Anfragen der Korrespondenzen sind gefragt
• Lemma
Sei q eine Benutzeranfrage und p1, p2 zwei Anfragepläne
für q. Sei loc(p1) bzw. loc(p2) die Expansion von p1, p2 mit
den jeweiligen Wrapperqueries. Dann gilt
p1 ⊆ p2
gdw. loc ( p1 ) ⊆ loc ( p2 )
• Bemerkung
•
•
Relationen in loc() sollten mit der Quelle gepräfixed werden (name space)
Beweis: einfach
31
Beispiel
• Beispiel
•
•
•
•
•
v1: film(T,R) :- doku(T,R)
v2: film(T,R), reg(R,N) :- doku(T,R), reg(R,N)
q: film(T,R)
loc(v1) = film(T,R) :- doku(T,R)
loc(v2) = film(T,R) :- doku(T,R), reg(R,N)
• Damit ist p2⊆p1, p2 ist redundant
• Ursachen für das Auftreten redundanter Pläne
• Überlappende bzw. enthaltene oder redundante Korrespondenzen
• Durch Anfrageplanung erzeugt
32
Redundante Pläne entfernen
• Lemma
Sei q eine Benutzeranfrage und p1, p2 zwei
Anfragepläne für q. Wenn p1⊆p2, dann ist p1
redundant.
• Bemerkung
• Das ist nur eine hinreichende, aber keine notwendige Bedingung
• I.A. können wir aber keine Aussagen über die tatsächliche
Extension von Wrapperanfragen machen
• Korrespondenzen beschreiben ja nur ihre Intension
• Damit können wir redundante Pläne entfernen
• Paarweise Containment testen
• Wie finden wir dabei am schnellsten überflüssige Pläne?
• Offene Frage
33
34
Multiple Query Optimization
• Redundant von Plänen entfernt nur ganze Pläne
• Aber verschiedene Pläne können durchaus auch dieselben
Views benutzen
• In dem Fall kann man sich manchmal die Ausführung von
Teilplänen sparen
• Multiple Query Optimization MQO (allgemein)
•
•
•
•
Gegeben eine Menge von Queries Q
MQO sucht nach common subexpressions (gleichen Teilanfragen)
Diese werden nur einmal ausgeführt
Queries in Q werden umgeschrieben, um dieses Ergebnis zu benutzen
• MQO ist nicht Standard in RDBMS
• In unserem Fall: „common subexpr.“ = gleiche Views
35
Der einfache Fall
• Wenn wir weder Projektionen noch Selektionen noch Joins
pushen wollen, ist das Problem einfach
•
•
•
•
Jeder View, der mehrmals vorkommt, muss nur einmal ausgeführt werden
Alle weiteren Ausführungen benutzen dieses Ergebnis
Das kann man in der Optimierungsphase feststellen oder …
Als Cache betrachten (konzeptionell einfacher)
• Beispiel
•
•
•
•
•
•
v1: film1(T,R) :- doku(T,R)
v2: film1(T,R) :- spielfilm(T,R)
v3: reg(R,N) :- reg(R,N)
q: film(T,R), reg(R,N)
p1: v1 ⋈ v3 = film1(T,R),reg(R,N)
•
•
Kein Plan ist redundant
v3 ist doppelt und muss nur einmal ausgeführt werden
36
Kompliziertere Fälle
• Beispiel – aber wir können den Join pushen
•
•
•
•
•
•
v1: film1(T,R) :- doku(T,R)
v2: film1(T,R) :- spielfilm(T,R)
v3: reg(R,N) :- reg(R,N)
q: film(T,R), reg(R,N)
• Wenn wir v3 nur einmal ausführen wollen, müssen wir alle Tupel zum
Mediator bewegen
• Alternative
•
•
•
Erst v1 ausführen und Werte für R an v3 pushen
Da v1 und v2 unterschiedliche Wertemengen berechnen werden, muss v3 auch
mehrmals aufgerufen werden
Dabei kann man R(v1) \ R(v2) Aufrufe sparen
• Was ist schneller? Hängt davon ab …
• Im allgemeinen heißt „gleicher View“ also nicht, dass wir uns eine
Ausführung komplett sparen können
37
Vorberechnung
• Einige Arbeit können wir vorab leisten
• Lemma
Eine Korrespondenz k: v⊆w ist redundant, wenn es eine
andere Korrespondenz k‘: v‘⊆w‘ gibt, für die gilt
v ≡v‘ ∧ w⊆w‘ ∧ exp(v)⊆exp(w)
• Bemerkung
•
•
Redundante Korrespondenzen kann man von vorneherein wegwerfen
Nur Containment reicht nicht
38
Blüten
• Das Streichen von redundanten Teilplänen kann
auch kontraproduktiv sein
• Beispiel
• v1: parentOf(P,C) :- hasChild(P, C)
• q: opaPeter(G) :- parentOf(G,P),parentOf(P, „peter‘)
• p1: v1 ⋈ v1 = hasChild(G,P),hasChild(P,‘peter‘)
• Die zweite Anfrage ist in der ersten enthalten
• Also nur die Allgemeinere ausführen: hasChild(G,P), ohne Bindung
• Das ist sicher viel teurer als beide ausführen
• Weil das zweite Literal die höhere Selektivität hat, dieses zuerst
• Dann die Bindung für P in die zweite Ausführung von v pushen
• MQO muss Teil einer kostenbasierten Opt. sein
39

Logische Optimierung verteilter Anfragen

Transcription

Similar documents

IPv6-¨Uberblick

Binding Pattern

Managed Care - Familie Sternfeld

Mediator-Wrapper

Mediator-Wrapper

Endbericht

Volume P-242(2015) - Mathematical Journals

Klausur WS0708 ohne Musterlösungen