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

?