views in database management systems „nutzen von ... · views in database management systems ~...
TRANSCRIPT
Views in Database Management Systems
~„Nutzen von Materialized Views in
RDBMS“
Christian Becker
Einführung/Gliederung
1) Was sind Views/Materialized Views?2) Wie kann man die wiederverwenden und wieso?3) Welche Ansätze gibt es?
1) Query Graph Model4) Betrachtung der Umsetzung5) Praxis
Was sind Views?
● View: Relation über DB, virtuelle Tabelle– Und wozu?
● Nutzerfreundlichkeit– Denormalisierung, Komplexität verbergen
● (teils) Sicherheit– Zugriff auf Basistabellen beschränken/verbieten
● Effizienz– wiederverwendbar
● vorkompilierbar● gut in Cache einfügbar
Was kosten Views?
● Und was kostet das?– Flexibilität
● nicht auf jeden View kann man INSERT/UPDATE ausführen
– Identitäten gehen je nach View verloren● der View verhält sich nicht mehr wie andere Relationen
– Effizienz● wenn der Nutzer sie falsch verwendet
(wenn der Query Optimizer sie nicht versteht) → Beispiel
Beispiel Views und Optimierung (1)
● (Webshop)
Beispiel Views und Optimierung (2)● View1: create view usedcards as
select customer.name as cname, cardtype, expire fromcustomer, address, paymentwhere idcustomer = fk_idcustomer AND idpayment = fk_idpayment AND cardtype = 'visa';
– (alle Namen/Typen/Expires für Customer mit Visa-Karten)
● Query1: select cname, cardtype from usedcards;
– (nur Namen/Typen für Customer mit Visa-Karten)
– select cname, cardtype from(select customer.name as cname, cardtype, expire from
customer, address, paymentwhere idcustomer = fk_idcustomer AND
idpayment = fk_idpayment AND cardtype = 'visa') as usedcards;
– select customer.name as cname, cardtype fromcustomer, address, paymentwhere idcustomer = fk_idcustomer AND idpayment = fk_idpayment AND cardtype = 'visa';
das ist 'view flattening'
Beispiel Views und Optimierung (3)● View1: create view usedcards as
select customer.name as cname, cardtype, expire fromcustomer, address, paymentwhere idcustomer = fk_idcustomer AND idpayment = fk_idpayment AND cardtype = 'visa';
● Query2: select cname, cardtype, expire from usedcards where expire<'1.Jan.2008';
– (nur Namen/Typen für Customer mit Visa-Karten mit Expire in diesem Jahr)
– select cname, cardtype, expire from (select customer.name as cname, cardtype, expire from
customer, address, paymentwhere idcustomer = fk_idcustomer AND
idpayment = fk_idpayment AND cardtype = 'visa') as usedcards
where expire<'1.Jan.2008';
– select customer.name as cname, cardtype, expire fromcustomer, address, paymentwhere idcustomer = fk_idcustomer AND
idpayment = fk_idpayment AND cardtype = 'visa' AND expire<'1.Jan.2008';
das ist 'predicate pushdown'
Was sind Materialized Views?
● Materialized View: ein vorberechneter View– Und wozu?
● Effizienz! (Zwischenergebnisse wirft man nicht weg)– Und was kostet das?
● (Speicher), Effizienz!– jeder MV beruht auf einer bestimmten Instanz der DB (Snapshot)– MV muss regelmäßig aktualisiert werden
● Updatestrategien:– Zeitpunkt: sofortig (Transaktion) ↔ verzögert (Zeitpunkte)– Art: volles Update ↔ inkrementelles Update
ein großes Feld für sich
Materialized Views in RBDMS:
MSSQL Server 2000 Oracle 8/8.1 IBM db2 UDBIndexed Views Materialized Join View Automatic Summary Table- erzeugen von Indizes über View
- keine derived tables - nur mit Dynamic SQL nutzbar
- spezielle Form (ab Version 8) von:
Materialized Aggregate ViewMaterialized Query Table
Materialized View - beliebig komplex
- beliebig komplex
kein left/right outer/exception JOIN)
Generell:
Updates: Updates: Updates:- Index - inkrementell außer plain MV - IMMEDIATE / DEFERRED / BY USER
- Unterscheidung mit 10g obsolet?
- inner und equijoin - enthält GROUP BY (Aggregierung)
Materialized Subquery View- EXIST-Subquery
- Aggregierungs-Funktionen
- (Tabellenverhalten, kein Index, kein UNION,
- (Tabellenverhalten, Indizes,...)
- inkrementell via „staging table“
Wie nutzt man MVs?
● konventionell– direkte Anfragen auf den MV– analysieren/empfehlen durch externe Programme
● Wieso nicht in der Optimierung berücksichtigen?– jede ähnliche Anfrage könnte profitieren– eine weitere Ausdehnung der Query Optimization:– SPJ → Nested Queries → MV-Optimierung
● Und wie also den MV nutzen?– zB mit Query Rewriting
Query Rewriting
● Wann setzt man Query Rewriting ein:– Datenintegration und Optimierung
● Wie kann man Query Rewriting angehen:– Query Graph Model (zB IBM)
● Darstellung der Query als Graph● Abgleich des Query-Graphen mit dem View-Graphen● Berechnung der Unterschiede und Kompensation
– Join Graph (Oracle)● ~ Query Graph?
– Äquivalenzklassenberechnung (MS)● algorithmischer Abgleich der Prädikat-Äquivalenzen
Query Graph Model (QGM)● View1: create view usedcards as
select customer.name as cname, cardtype, expire fromcustomer, address, paymentwhere idcustomer = fk_idcustomer AND idpayment = fk_idpayment AND cardtype = 'visa';
● auch als Graph darstellbar(im Folgenden übertrieben zerlegt):– jede Box konsumiert/produziert
– Wurzelknotenenthält Ergebnis
OperationOutput
Prädikate
QGM-Rewriting: Ablauf
1) Graph für View und Query erstellen2) bottom-up-matchen der Knoten auf Äquivalenz
1) ggf. Kompensationsknoten erstellen
3) Kompensationsknoten für View erstellen1) Kompensationsknoten hochziehen2) Rejoins durchführen
QGM-Rewriting: exact child match● Query1: select customer.name as cname, cardtype from
customer, address, paymentwhere idcustomer = fk_idcustomer AND idpayment = fk_idpayment AND cardtype = 'visa';
● einfache project-Kompensation
QGM-Rewriting: exact child + pullup ● Query2: select customer.name as cname, cardtype, expire from
customer, address, paymentwhere idcustomer = fk_idcustomer AND
idpayment = fk_idpayment AND cardtype = 'visa' AND expire<'1.Jan.2008';
● predicate pullup ( predicate pushdown)→
QGM-Rewriting: Kriterien (1)
● jeder extra JOIN muss verlustlos sein– left outer join/inner join ... finden über constraints:
● RI (relational integrity: FK-Beziehungen zwischen tables)● PK (primary key: JOIN on PK)● D (distinct clauses: Duplikate kompensieren)
● jedes View-Prädikat– passt zu (einem) oder– subsummiert ein Query-Prädikat (x>10 beinhaltet x>20)
● jedes Query-Prädikat– passt zu (einem) oder– lässt sich aus View-Prädikaten und Rejoins berechnen
Query Graph Model (QGM) (2)● View1: create view usedcards as
select customer.name as cname, cardtype, expire fromcustomer, address, paymentwhere idcustomer = fk_idcustomer AND idpayment = fk_idpayment AND cardtype = 'visa';
● links mal als echtes QGM/rechts ausführlich
– (nicht mehr ganz äquivalent zum Join Graph)
Erweitertes Beispiel
● (Webshop mit denormalisiertem Sale-Listing)
Query Graph Model (QGM) (3)● View2: create view salesbycardandmonth as
select customer.name as cname, month(date) as month, year(date) as year, sum(singleprice*number) as monthsum from
customer, address, payment, salewhere idcustomer = fk_idcustomer AND
idpayment = fk_idpaymentsale AND idaddress = fk_idaddresssale
group by customer.name, month(date),year(date);
● (für wieviel hat ein Customer pro Monat/Jahr eingekauft)
QGM-Rewriting: exact, group by● Query3: select customer.name as cname, year(date) as year,
sum(singleprice*number) as yearsum fromcustomer, address, payment, salewhere idcustomer = fk_idcustomer AND
idpayment = fk_idpaymentsale AND idaddress = fk_idaddresssale
group by customer.name, cardtype, year(date);
● (für wieviel hat ein Customer pro Jahr eingekauft)
QGM-Rewriting: group by, child pull-up● Query4: select customer.name as cname, month(date) as month,
year(date) as year, sum(singleprice*number) as monthsum fromcustomer, address, payment, salewhere idcustomer = fk_idcustomer AND
idpayment = fk_idpaymentsale AND idaddress = fk_idaddresssale AND customer.name LIKE 'A%'
group by customer.name, month(date), year(date);
● (für wieviel hat ein Customer namens 'A%' pro Jahr eingekauft)
QGM-Rewriting: fail● Query5: select customer.name as cname, month(date) as month,
year(date) as year, sum(singleprice*number) as monthsum fromcustomer, address, payment, salewhere idcustomer = fk_idcustomer AND
idpayment = fk_idpaymentsale AND idaddress = fk_idaddresssale AND cardtype = 'visa'
group by customer.name, month(date), year(date);
● (für wieviel hat ein Customer mit VISA pro Jahr eingekauft)
QGM-Rewriting: Kriterien (2)
● jede Query-Aggregierung– passt zu (einer) oder– ist von einer View-Aggregierung ableitbar:
● sum(jahr) ist von sum(monat) ableitbar (Hierarchie)● count(*) ist als sum(count()) ableitbar● max(x) ist als max(max()) ableitbar● ... (immer dann, wenn View feiner granuliert ist)
QGM: offene Punkte
● Wie funktioniert das Matching?– expression translation (IBM):
● ein Ausdruck wird top-down durch den QGM verfolgt und durch die Kind-Ausdrücke ersetzt
● ... und irgendwann matcht er ein Äquivalent in Query oder nicht ...– column equivalence classes (MS):
● Erstellen von Äquivalenzklassen für Query/View● Einzelabgleich● (nur Translation über Joins nötig, da kein QGM)
... noch ein Feld für sich
Ermitteln des optimalen QEP (1)
● Kriterium:– Ermitteln darf nicht länger dauern als Zeitersparnis
● Oracle: Join Graph (ΔJoin-Graph ... multi query-block)1) für jede Relation Liste relevanter MV speichern2) Schnittmenge/Vereinigung
● MAV (verkleinert Datenmenge) vor MJV ● Schleife bis kein Rewrite mehr erfolgreich● Kardinalitätsheuristik bei konkurrierenden MV● Tabellenverhalten der MVs optimiert weiter (zB Indizes)
3) Berechnung Kosten des Rewrite ↔ Kosten Query im Einsatz, seit 10g auch Superaggregation
Ermitteln des optimalen QEP (2)
● IBM: QGM (multi query-blocks)– leider keine Details über QEP-Einbettung– im Einsatz
● Microsoft: expression matching (single query-block)– kann keine Rejoins– unterstützt (derzeit) keine Superaggregation– optimiert nur auf Ebene eines einzigen SPJG-Ausdrucks– benutzt filter-tree/table-signature zum schnellen Finden– im Einsatz
Ziele?● erreichte Ziele in den DBMS:
– IBM/MS behaupten Performancegewinn● Statistiken von MS
– Oracle bietet sogar aktive Unterstützung bei Finden von Query Rewrite-Fehlern
● Zukünftige Ziele wären:– Rewrite unter Nutzung mehrerer MV– Selbsterstellung von MV
Fragen
?