3. DB-Pufferverwaltung

Transkript

1 . D-Pufferverwaltung Rolle der D-Pufferverwaltung in einem Datenbanksystem Ziel: Realisierung einer effizienten, seitenbasierten Verarbeitungsplattform im Hauptspeicher - größtmögliche Vermeidung von physischer Ein-/Ausgabe - Ersetzungsverfahren ohne und mit Kontextwissen INDE PERSONAL WHERE ANR = K Transaktionsprogramme, die auf die Datenbank zugreifen TA TA TA n Rolle der D-Pufferverwaltung - Ablauf des Zugriffs auf den D-Puffer Datenbanksystem (vereinfacht) - Vergleich mit ähnlicher unktionalität in etriebssystemen (S) Lokalität - Maße für Lokalität - Charakterisierung durch LRU-Stacktiefen-Verteilung Und Referenzdichtekurven Speicherzuteilung und Suche im D-Puffer Seitenersetzungsverfahren - Klassifikation von Ersetzungsverfahren - LRU, IO, CLOCK, GCLOCK, LRD, LRU-K... Stelle Seite P i bereit Gib Seite P i frei Lies Seite P i Schreibe Seite P i Transaktionsverwaltung und Zugriffspfadroutinen logische Seitenreferenzen D-Pufferverwaltung D-Puffer physische Seitenreferenzen Externspeicherverwaltung Ersetzungsverfahren Einbezug von Kontextwissen D-Caching - Klassifikation der Verfahren - DProxy - DCache Kanalprogramme Plattenzugriffe. Effelsberg, W., Härder, T.: Principles of Database uffer Management, in: ACM Transactions on Database Systems 9:, Dec. 98, pp

2 Seitenreferenzstrings Eigenschaften von D-Referenzstrings Jede Datenanforderung ist eine logische Seitenreferenz Typische Referenzmuster in DS Aufgabe der D-Pufferverwaltung: Minimierung der physischen Seitenreferenzen. Sequentielle Suche Referenzstring R = <r, r,... r i,... r n > mit r i = ( T i, D i, S i ) T i zugreifende Transaktion D i referenzierte D-Partition S i referenzierte D-Seite estimmung von Ausschnitten aus R bezüglich bestimmter Transaktionen, Transaktions-Typen und D-Partitionen sinnvoll zur Analyse des Referenzverhaltens S i S j S k S l sp.: Durchsuchen ganzer Satztypen (Relationen). Hierarchische Pfade Wie kann Referenzstring-Information verwendet werden für - Charakterisierung des Referenzverhaltens? - estimmung von Lokalität und Sequentialität? - Unterstützung einer effektiven Seitenersetzung? sp.: Suchen mit Hilfe von *-äumen. Zyklische Pfade sp.: Abarbeiten von Sets ((:n)-eziehungen), Suchen in DTT-/Datenseiten - -

3 Vergleich mit S-unktionen Sequentialität Ersetzungsalgorithmen im D-Puffer in Software implementiert Seitenersetzung in Adreßräumen bei Virtuellem Speicher ist HW-gestützt Seitenreferenz vs. Adressierung nach einem IX-Aufruf kann eine D-Seite mehrfach bis zum UNIX referenziert werden unterschiedliches Seitenreferenzverhalten andere Ersetzungsverfahren? Können Dateipuffer des S als D-Puffer eingesetzt werden?. Zugriff auf Dateipuffer ist teuer (SVC: supervisor call). D-spezifische Referenzmuster können nicht gezielt genutzt werden S-Ersetzungsverfahren sind z.. nicht auf zyklisch sequentielle oder baumartige Zugriffsfolgen abgestimmt. Normale Dateisysteme bieten keine geeignete Schnittstelle für Prefetching In DMS ist aufgrund von Seiteninhalten oder Referenzmustern eine Voraussage des Referenzverhaltens (z.. bei Tabellen-Scans) möglich; Prefetching erzielt in solchen ällen eine enorme Leistungssteigerung. Selektives Ausschreiben von Seiten zu bestimmten Zeitpunkten (z.. für Logging) nicht immer möglich in existierenden Dateisystemen DVS muß eigene Pufferverwaltung realisieren SRS weisen typischerweise Phasen von Sequentialität und Lokalität auf Sequentielle Zugriffsfolge (SZ): Zwei aufeinanderfolgende Referenzen r i und r i+ gehören zu einer sequentiellen Zugriffsfolge, falls S i+ S i = 0 oder d. h., aufeinanderfolgende Zugriffe referenzieren benachbarte D-Seiten Algorithmus - Seitenreferenzstring wird vollständig durchmustert; alternativ kann die olge der ankommenden Referenzen analysiert werden - Solange obige edingung erfüllt ist, gehören alle aufeinanderfolgenden Referenzen zu einer SZ, sonst beginnt eine neue SZ Länge einer sequentiellen Zugriffsfolge (LSZ): - LSZ ist die Anzahl der verschiedenen in SZ referenzierten Seiten - sp.:referenzstring A A D E E H enthält (AA) mit LSZ() =, (DEE) mit LSZ() = und (H) mit LSZ() = Maß für Sequentialität: - Die kumulative Verteilung der SZ-Längen LSZ(i) wird berechnet S(x) = Pr(SZ-Länge <= x) - ür obiges sp. gilt: S()=0., S()=0.67, S()=.0 ei Sequentialität Optimierung durch (asynchrones) Prefetching von D-Seiten möglich - - 6

4 Lokalität Erhöhte Wiederbenutzungswahrscheinlichkeit für gerade referenzierte Seiten (gradueller egriff) Grundlegende Voraussetzung für - effektive D-Pufferverwaltung (Seitenersetzung) - Einsatz von Speicherhierarchien Wie kann man Lokalität messen? Working-Set-Modell Referenzstring A A C A A C D E G H w = 8 Window size w t w = 8 t Working set size W W (t, w=8) = W (t, w=8) = 8 Aktuelle Lokalität: AL ( t, w ) = Wtw (, ) w Durchschnittliche Lokalität: Lw ( ) = n t = AL ( t, w ) n Relative Referenzmatrix (DOA-Last) ca Transaktionen, Million Seitenreferenzen auf ca verschiedene Seiten P P P P P P6 P7 P8 P9 P0 P P P Total TT TT TT TT TT TT6 TT TT8 TT9 TT0 TT TT Total partition size (%) % referenced

5 LRU-Stacktiefenverteilung eispiel: Ermittlung der Stacktiefen-Verteilung Wie läßt sich Lokalität charakterisieren? - LRU-Stacktiefenverteilung liefert Maß für die Lokalität (präziser als Working-Set-Ansatz) Referenzstring: A A C A A A C D E A E LRU-Stack: - LRU-Stack enthält alle bereits referenzierten Seiten in der Reihenfolge ihres Zugriffsalters estimmung der Stacktiefenverteilung: - pro Stackposition wird Zähler geführt - Rereferenz einer Seite führt zur Zählererhöhung für die jeweilige Stackposition A C D E Stacktiefen-Verteilung Wiederbenutzungswahrscheinlichkeit (%) Lokalität wahlfreie Zugriffsverteilung Stacktiefe Stacktiefe Zählerwerte entsprechen der Wiederbenutzungshäufigkeit ür LRU-Seitenersetzung kann aus der Stacktiefenverteilung für eine bestimmte Puffergröße unmittelbar die Trefferrate (bzw. ehlseitenrate) bestimmt werden - 9-0

6 Reale LRU-Stacktiefen-Verteilungen % 0 0 LRU-Stacktiefen-Verteilung von Mix0 Länge des Strings: 066 logische Referenzen Anzahl verschiedener Seiten im String: relative Häufigkeit der Stacktiefe LRU-Stacktiefe % LRU-Stacktiefen-Verteilung von Mix0 Länge des Strings: 9997 logische Referenzen Anzahl verschiedener Seiten im String: 0 relative Häufigkeit der Stacktiefe LRU-Stacktiefe. W. Effelsberg, T. Härder: Principles of Database uffer Management, ACM Transactions on Database Systems, Vol. 9, No., Dec. 98, pp Referenzdichte-Kurven - Referenzdichte-Kurven % % TA TA TA TA TA TA Relative Häufigkeit der Seitentypen im eispiel = Daten und Indexstrukturen: 9,8 % = Adressumsetztabellen: 6, % = reispeicher-verwaltung: 0, %

7 Partitionierungsmöglichkeiten: eigener Pufferbereich pro Transaktion TA-Typ-bezogene Pufferbereiche Seitentyp-bezogene Pufferbereiche D-(Partitions)spezifische Pufferbereiche - Dynamische Pufferallokation Working-Set-Ansatz (WS) Pro Pufferpartition P soll Working-Set im Puffer bleiben; Seiten, die nicht zum Working-Set gehören, können ersetzt werden ei ehlseitenbedingung muß Working-Set bekannt sein, um Ersetzungskandidat zu bestimmen - enstergröße (Window Size) pro Partition: w (P) - Referenzzähler pro Partition: RZ (P) - letzter Referenzzeitpunkt für Seite i: LRZ (P, i) - ersetzbar sind solche Seiten, für die RZ (P) LRZ (P, i) > w (P) enstergröße kritischer Parameter Thrashing-Gefahr P: A A C A A G H A P: Referenzstring D E E - Speicherzuteilung im D-Puffer global ( gemeinsamer Pufferbereich) lokal / partitionierte Pufferbereiche statisch dynamisch gleichförmige Partitionen angepaßte Partitionen

8 Suche im D-Puffer Seitenersetzungsverfahren Sequentielles Durchsuchen der Pufferrahmen Klassifikation - sehr hoher Suchaufwand Verfahrensklassen - Gefahr vieler Paging-ehler bei virtuellen Speichern Nutzung von Hilfsstrukturen (Eintrag pro Pufferrahmen) preplanning prefetching demand fetching. unsortierte oder sortierte Tabelle Programmanalyse, physische Datenstruktu- keine Vorausaktionen. Tabelle mit verketteten Einträgen - geringere Änderungskosten Vorabuntersuchung des Datenbedarfs rierung, Clusterbildung, Verarbeitungswissen - Anordnung in LRU-Reihenfolge möglich. Suchbäume (z.. AVL-, m-weg-äume) große ehlrate, datenmodellbezogen Lokalitätserhaltung. Hash-Tabelle mit Überlaufketten - beste Lösung ungenaue Obermengen (hierarchisch), spekulative Entscheidungen im D-Puffer h (P i ) = k Grundannahme bei Ersetzungsverfahren: k P j P i P k - A A C A C A C D H Referenzen jüngste Vergangenheit nächste Zukunft Referenzverhalten ähnlich - - 6

9 Referenzverhalten und Ersetzungsverfahren ehandlung geänderter Seiten im D-Puffer Referenzverhalten in DS - typischerweise hohe Lokalität: Optimierung durch Ersetzungsverfahren - manchmal Sequentialität oder zufällige Arbeitslast (RANDOM-Referenzen) Prinzipielle Zusammenhänge, welche die ehlseitenrate bestimmen Ersetzung einer geänderten Seite erfordert ihr vorheriges (synchrones) Zurückschreiben in die D Antwortzeitverschlechterung Abhängigkeit zur gewählten Ausschreibstrategie: ehlseitenrate 00% R/R R/OPT ORCE: alle Änderungen einer Transaktion werden spätestens beim EOT in die D zurückgeschrieben ( write-through ) + i. allg. stets ungeänderte Seiten zur Ersetzung vorhanden + vereinfachte Recovery (nach Rechnerausfall sind alle Änderungen beendeter TA bereits in die D eingebracht) - hoher E/A-Overhead L/OPT L/R - starke Antwortzeiterhöhung für Änderungstransaktionen D # Rahmen im D-Puffer NOORCE: kein Durchschreiben der Änderungen bei EOT (verzögertes Ausschreiben, deferred write-back ) + Seite kann mehrfach geändert werden, bevor ein Ausschreiben erfolgt D = D-Größe in löcken (geringerer E/A-Overhead, bessere Antwortzeiten) Kombinationen: Referenzen: RANDOM RANDOM Lokalität Lokalität Ersetzung: RANDOM OPT RANDOM OPT + Vorausschauendes (asynchrones) Ausschreiben geänderter Seiten erlaubt auch bei NOORCE, vorwiegend ungeänderte Seiten zu ersetzen Synchrone D-Schreibvorgänge lassen sich weitgehend vermeiden Grenzfälle des Referenzverhaltens und der Ersetzungsverfahren zeigen Optimierungsmöglichkeiten auf - 7-8

10 Kriterien für die Auswahl der zu ersetzenden Pufferseite Least requently Used und irst-in irst-out Verfahren OPT RANDOM LU IO LRU CLOCK GCLOCK Alter - - Kriterien letzte Referenz - - Referenzhäufigkeit - - andere Kriterien Vorauswissen x --- x Algorithmus LU - Referenzzähler pro Seite wird bei jeder Seitenreferenz inkrementiert - Ersetzung der Seite mit der geringsten Referenzhäufigkeit RZ 6 Alter einer Seite wird nicht berücksichtigt! Algorithmus IO - Die älteste Seite im D-Puffer wird ersetzt - Referenzen während des Pufferaufenthaltes werden nicht berücksichtigt LRD (V) LRD (V) LRU-K - 9 Nur für strikt sequentielles Referenzierungsverhalten geeignet - 0

11 Least Recently Used (LRU) CLOCK (Second Chance) eispiel (Puffergröße ):. Referenz der Seite C A C D LRU-Stack C A D Algorithmus - Erweiterung von IO - Referenzbit pro Seite, das bei Zugriff gesetzt wird - Ersetzung erfolgt nur bei zurückgesetztem it, sonst erfolgt Zurücksetzen des its 0. Referenz der Seite E 0 A E A C 0 D C Unterscheidung zwischen Least Recently Referenced Least Recently Unfixed und annähernde erücksichtigung des letzten Referenzierungszeitpunkts t IX IX UNIX UNIX A A - -

12 Seitenersetzungsverfahren eispiel GCLOCK (Generalized CLOCK) Seitenreferenzfolge OPT LRU IO * * * * * * * * * * * * * * * * * * * * * * * * * CLOCK Algorithmus - Pro Seite wird Referenzzähler geführt (statt it) - Ersetzung nur von Seiten mit Zählerwert 0 - sonst erfolgt Dekrementierung des Zählers und etrachtung der nächsten Seite 0 0 Verfahrensparameter: - Initialwerte für Referenzzähler - Wahl des Dekrementes - Zähler-Inkrementierung bei erneuter Referenz - Vergabe von seitentyp- oder seitenspezifischen Gewichten - -

13 Least Reference Density (LRD) Least Reference Density () Algorithmus - Wenn eine Seite ersetzt werden muß, wird die Referenzdichte aller Seiten im D-Puffer bestimmt - Referenzdichte = Referenzhäufigkeit in einem bestimmten Referenzintervall - Ersetzungskandidat ist Seite mit geringster Referenzdichte Variante : konstante Intervallgröße - Künstliches Altern von Seiten: Ältere Referenzen werden bei der estimmung der Referenzdichte geringer bewertet - Periodisches Reduzieren der Referenzzähler, um Gewicht früher Referenzen zu reduzieren - Reduzierung von RZ durch Division oder Subtraktion: Variante : Referenzintervall entspricht Alter einer Seite erechnung der Referenzdichte: Globaler Zähler GZ: Gesamtanzahl aller Referenzen Einlagerungszeitpunkt EZ: GZ-Wert bei Einlesen der Seite Referenzzähler RZ oder RZ() i RZ() i = RZ() i = K RZ() i K K (K > ) falls RZ() i K K sonst ( K > 0, K 0) Referenzdichte RD() j = RZ() j GZ EZ() j A A A C D D E A A A C D D E t t t RZ EZ RD t t t A C D E RZ(A) RZ() RZ(C) RZ(D) RZ(E) RZ() - - 6

14 LRU-K Aufzeichnung der K letzten Referenzzeitpunkte (pro Seite im D-Puffer) - Aufwendigere Aufzeichnung gewährleistet aktuelle Ersetzungsinformation; Methode benötigt kein explizites Altern über Tuning-Parameter wie LRD-V - Gegeben sei bis zum etrachtungszeitpunkt t der Referenzstring r,r,..., r t. Rückwärtige K-Distanz b t (P, K) ist die in Referenzen gemessene Distanz rückwärts bis zur K-jüngsten Referenz auf Seite P: b t (P, K) = x, b t (P, K) =, wenn r t-x den Wert P besitzt und es genau K- andere Werte i mit t-x < i t mit r i = P gab. wenn P nicht wenigstens K mal in r,r,..., r t referenziert wurde Ersetzungverfahren Einbezug von Kontextwissen Ausnutzung von Kontextwissen bei mengenorientierten Anforderungen Verbesserung in relationalen DS möglich Zugriffspläne durch Anfrage-Optimierer - Zugriffscharakteristik/Menge der referenzierten Seiten kann bei der Erstellung von Plänen vorausgesagt/abgeschätzt werden - Zugriffsmuster enthält immer Zyklen/Loops (mindestens Kontrollseite Datenseite, nested loop join etc.) - Kostenvoranschläge für Zugriffspläne können verfügbare Rahmen eispiel (K=) C A A C C A Zeit berücksichtigen - ei Ausführung wird die Mindestrahmenzahl der Pufferverwaltung mitgeteilt Hot Set: Menge der Seiten im Referenzzyklus Prinzipieller Verlauf der ehlseitenrate (SR) bei speziellen Operationen SR Zur Ersetzung genügt es, die b t (P i, K) der Pufferseiten zu berücksichtigen! - Sonderbehandlung für Seiten mit weniger als K Referenzen erforderlich Hot Points - Wie hängt LRU-K mit LRD zusammen? Approximation der Referenzdichte? LRU- (d.h. K=) stellt i. allg. beste Lösung dar - ähnlich gute Ergebnisse wie für K >, jedoch einfachere Realisierung # Rahmen - Verfahren reagiert schneller auf Referenzschwankungen als bei größeren K. O Neil, E.J., O Neil, P.E., Weikum, G.: The LRU-K Page Replacement Algorithm for Database Disk uffering. Proc. ACM SIGMOD Conf. Washington. D.C

15 Hot Set -Modell Seitenersetzung bei virtuellem Speicher Hot Point: abrupte Veränderung in der SR, z.. verursacht durch Schleife beim Verbund virtueller Speicher Hauptspeicher Hot Set Size (HSS): größter Hot Point kleiner als der verfügbare D-Puffer Anfrage-Optimierer berechnet HSS für die verschiedenen Zugriffspläne (Abschätzung der #Rahmen) D P SP virtuell SP real eispiel: P Kosteneinheiten/0 0 SELECT * ROM AT X, PERS Y WHERE X.ANR = Y.ANR AND... Magnetplatte Magnetplatte H S P 0 PERS in äußerer Schleife AT in äußerer Schleife Index-Scan für beide Relationen Page ault: P i (P ) in SP virtuell, aber nicht in SP real (HSP) Database ault: 0 0 # Rahmen P i (P ) nicht in SP virtuell, Seitenrahmen für P i jedoch in SP real Anwendungscharakteristika - erücksichtigung der HSS in den Gesamtkosten - Auswahl abhängig von verfügbarer D-Puffergröße - indung zur Laufzeit möglich Double Page ault: P i (P ) nicht in SP virtuell, ausgewählter Seitenrahmen nicht in SP real - 9-0

16 D-Caching D-Caching () Ziel: Unterstützung von Web-basierten D-Anwendungen - durch Abwicklung von D-(Teil-)Anfragen im Cache in AW-Nähe Anfrageergebnis-Caching (query result caching) On-demand Caching bei vorhandenen passenden Satzmengen - Im D-Cache muß Vollständigkeit (und Aktualität) der eingelagerten Satzmengen gewährleistet werden Wichtige Caching-Verfahren - Deklaratives Caching erfordert E-Metadaten, um den Cache dynamisch zu laden (Caching mehrerer QRs in gemeinsamen Tabellen) - On-demand Caching verwendet E-Metadaten und Hinweise der TA, um Daten dynamisch in den Cache zu füllen oder zu ersetzen Web- Server rowser-anforderungen von Clients Applikations- Server Applikations- Server D- Cache D- Cache ront-end-(e) D-Server D-Caching in der Nähe des Applikations-Servers Kunden WHERE Region= West Applikationslogik D- Server Kunden WHERE Region= Ost ack-end-(e) D-Server Ansätze - Replikation DA definiert, was im Cache zu halten ist E-Tabellen spiegeln die entsprechenden E-Tabellen wider Volle D- oder Tabellen-Replikation ist meist nicht wünschenswert - Materialisierte Sichten DA spezifiziert Sichtdefinitionen für Sichten, die im Cache gehalten werden sollen separate E-Tabelle für jede Sicht Was sind die richtigen Sichten? Wie läßt sich eine dynamische Anpassung des Cache-Inhalts an die TA-Last erreichen? Deklaratives und/oder On-demand Caching - eide egriffe werden in der Literatur zur Klassifikation verwendet - keine strikte Unterscheidung, Verfahrensübergänge fließend - eide Verfahren sind dynamisch und wollen adaptiv sein - Es werden E-Metadaten und Hinweise gebraucht (deklarativ), um zu wissen, was im Cache zu speichern ist - Werden zu speichernde Daten nicht im Cache gefunden, wird die Anfrage in der E-D beantwortet. Zugleich werden die entsprechenden Daten in den Cache geladen, damit die Anfrage beim nächsten Mal im Cache beantwortet werden kann (on-demand) - eschleunigung des lesenden D-Zugriffs - (bislang noch) Weiterleitung von Änderungsanweisungen zum E - Konsistenzprobleme -. Materialized Views werden (in IM-Publikationen) auch Automated Summary Tables (AST) oder Materiakized Query Tables (MQT) genannt.. Wir behalten die englischen eigriffe Cache, Cache Key, Cache Group usw. bei -

17 D-Caching () DProxy D-Caching Was ist zu entscheiden? - Was soll im Cache gehalten werden und wozu? Anfrageergebnisse (einzelne Tabellen/Sichten): Sie lassen Anfragen zu, die Untermengen als Ergebnis haben! Cache Groups (Cache-Gruppen), die aus mehreren zusammenhängenden Tabellen bestehen. Sie erlauben die Abwicklung von Anfragen mit einfachen Prädikaten und n Verbunden im Cache - Wie wird es spezifiziert? Liste von Anfragen Alle Anfragen, die eine spezifizierte Tabelle/Sicht betreffen Spezifikation von Cache Groups durch sog. Cache Constraints; das sind Cache Keys und Referential Cache Constraints (RCCs) - Wann werden Daten in den Cache geladen? vorab (statisch) on-demand; d. h., nachdem spezifizierte Daten nachgefragt wurden nach Analyse des edarfs? - Sind überlappende Daten im Cache zugelassen? Überlappende Sichten oder Cache Groups mit gemeinsamen Tabellen werden disjunkt gespeichert Problem: Caching + Replikation! - Wann werden Daten im Cache aktualisiert? zeitgleich zu ihrer Aktualisierung in der E-D? Relevante Änderungen werden innerhalb einer Zeitspanne δ propagiert irgendwann - Wann werden Daten im Cache ersetzt bzw. invalidiert? nie bei Speichermangel im Cache nach Ablauf eines Zeitintervalls ohne Referenzen - DProxy-Ansatz - Daten werden persistent in den E-D-Servern gespeichert - Als Hinweise sind zu spezifizieren: common schema tables - Daten, die im Cache gehalten werden, sind durch eine Liste von Anfragen in einem Cache-Index beschrieben Jede Anfrage liefert genau eine Tabelle zurück! - Aus Gründen der Speicherplatzeffizienz und zur Vermeidung von Replikation im Cache werden Anfrageergebnisse, wenn möglich, in derselben E-Tabelle gespeichert: Anfragen über dieselbe E-Tabelle Verbund-Anfragen über dieselbe Menge von E-Tabellen Sonst entstehen Replikate im Cache! - Anfragen für eine E-Tabelle beziehen sich auf unterschiedliche Spalten Anfragen können in ihrem Ergebnis überlappen ei Anfragen, die nicht alle Spaltenwerte zurückliefern, sind die Spalten mit NULL ( fake NULL values) aufzufüllen Wie lassen sich echte NULL-Werte darstellen?. Amiri, K., Park, S., Tewari, R., Padmanabhan, S.: DProxy: A Self-managing Data Cache for Edge-of-Network Web Applications, in: Proc. CIKM 00, pp

18 DProxy () DProxy () Anwendungsbeispiel - Vereinfachtes D-Schema eines Web-uchhändlers (nach TPC-W-enchmark) CUSTOMER ORDER ORDER_LINE ITEM C_ID C_UNAME C_PASSWD C_NAME C_LNAME C_ADDR_ID C_PHONE C_ C_SINCE C_LAST_VISIT C_LOGIN C_EXPIRATION C_DISCOUNT C_ALANCE C_YTD_PMT C_IRTHDATE C_DATA O_ID O_C_ID O_DATE O_SU_TOTAL O_TAX O_TOTAL O_SHIP_TYPE O_SHIP_DATE O_ILL_ADDR_ID O_SHIP_ADDR_ID O_STATUS OL_ID OL_O_ID OL_I_ID OL_QTY OL_DISCOUNT OL_COMMENT AUTHOR A_ID A_NAME A_LNAME A_MNAME A_DO A_IO I_ID I_TITLE I_A_ID I_PU_DATA I_PULISHER I_SUJECT I_DESC I_RELATED[-] I_THUMNAIL I_IMAGE I_SRP I_COST I_AVAIL I_STOCK I_ISN I_PAGE I_ACKING I_DIMENSION Verfahrensaspekte - elegung der ursprünglich leeren item-tabelle im Cache nach Einfügung der Ergebnisse von Q und Q - Anfragen werden so umgeschrieben, daß sie den Primärschlüssel i_id enthalten. So lassen sich Zeilenduplikate vermeiden E-item i_id i_cost i_srp NULL 8 60 NULL Retrieved by Q SELECT i_cost, i_srp ROM item WHERE i_cost ETWEEN AND 6 Retrieved by Q SELECT i_srp ROM item WHERE i_srp ETWEEN AND 0 Inserted by consistency protocol E-item-Tabelle hat 8 Spalten mit i_id als Primärschlüssel - Mögliche Anfragen hinsichtlich Kosten und Verkaufspreis (srp: suggested retail price) auf Tabelle item Q A : SELECT i_avail, i_cost ROM item WHERE i_cost < Q : SELECT i_avail, i_cost ROM item WHERE i_cost > Q N : SELECT i_srp, i_cost ROM item WHERE i_srp ETWEEN 0 AND 6 - Vor Einfügen vom Q -Ergebnis ist zu prüfen, ob E-item mit Spalten zu erweitern ist Optimierung: Definition einer umfassenden Tabelle mit Vorabwissen - Speicherung verschiedener Anfragen in einer E-Tabelle erzeugt unbelegte Spaltenwerte (NULL-Werte). Spätere Cache-Anfrage darf sie nicht benutzen - Einfügen von i_id=0 muß als Duplikat erkannt werden - - 6

19 DProxy () DProxy () Verfahrensaspekte (orts.) - Enthaltenseinstypen von Anfragen vollständig enthalten in einem früheren Anfrageergebnis (Sicht von Cache-Prädikat Q i ) Verfahrensaspekte (orts.) - Aktualisierung Wo wird aktualisiert? enthalten in der Vereinigung von mehreren früheren Ergebnissen (Sichten von Q i und Q j ) nur teilweise enthalten in einer oder mehreren im Cache gehaltenen Sichten Applikations- Server D- Cache D- Server - Komplexer Matching-Algorithmus Prädikate der im Cache gehaltenen Daten sind in einem Index gespeichert Enthaltensein von Q : Ergebnis von Q ist enthalten in dem von Q A, wenn das WHERE-Prädikat von Q das von Q A für alle möglichen Werte von item logisch impliziert Q.wherep => Q A.wherep äquivalent zur Anweisung Q.wherep AND (NOT (Q A.wherep)) ist nicht erfüllbar (i_cost < AND NOT (i_cost > )) Applikations- Server D- Cache ront-end-(e) D-Server ack-end-(e) D-Server Alle D-Caching-Ansätze sind nur sinnvoll, wenn sich die D-Daten nur langsam verändern δ-konsistenz wird gewährleistet: Relevante Änderungen in E-item werden nach E-item innerhalb einer Zeitspanne δ propagiert. i_id = {770, 880} wurden später in die E-D eingefügt. Cache-Prädikat Q verlangt das Propagieren dieser Sätze in die E-D - Ersetzung oder Invalidierung olglich ist Q nicht in Q A enthalten Ersetzung von Q darf nur i_id = {0, 60} aus E-item entfernen i. allg. sehr komplex, da Satzmengen, die durch überlappende Prädikate beschrieben werden, zu entfernen sind - 7-8

20 DCache DCache () DCache-Ansatz - Es sollen Anfragen mit einfachen Prädikaten und n Verbunden im Cache unterstützt werden. Das setzt voraus, daß der Cache-Mgr garantieren kann, daß bei einer Anfrageauswertung alle Sätze, die ein gegebenes Prädikat erfüllen, sich in der betreffenden E-Tabelle befinden daß in den n E-Tabellen alle zugehörigen Verbundpartner gespeichert sind Neue Herausforderung für Caching! - Wie wird die erste Anforderung spezifiziert? Hinreichende Schema-Information von allen E-Tabellen, von denen eine horizontale Partition als E-Tabelle gespeichert werden soll Einführung sog. Cache Keys (CK) Cache Key - kann für eine E-Tabelle spezifiziert werden - bezieht sich auf eine Spalte und dient als üllpunkt - besitzt die Eigenschaft bereichsvollständig (domain complete, DC) - Mechanismen zur Einschränkung sind lebenswichtig (~ Stoppwortliste) Definition: ereichsvollständigkeit einer Spalte Wenn ein Spaltenwert im Cache gefunden wird, garantiert der Cache-Mgr, daß alle Sätze mit diesem Wert sich im Cache befinden. UNIQUE-Spalten sind somit immer bereichsvollständig olglich wird die Auswertung eines Prädikats <ColName> = <value> durch eine solche Spalte unterstützt! eispiel - Tabelle CUST habe u. a. zwei UNIQUE-Spalten (U) Cnr und Cid sowie zwei Spalten CType und CLocation vom Typ NON UNIQUE (NU) - Im Cache seien für CUST CType und Cnr als Cache Keys deklariert - elegung im E: E_CUST Cnr CType CLocation Cid silver silver platinum unspec. gold gold... S LA SJ LA SJ S... NULL d07 a a07 a b - Im Cache sei die zugehörige Tabelle E-CUST zunächst leer. Eine Anfrage mit CType = gold wird im E ausgewertet und führt zu folgender elegung von E-CUST: E_CUST Cnr CType CLocation Cid... 6 gold gold SJ S - Erneute Anfragen mit CType = gold oder Cnr = oder Cnr = 6 werden im Cache ausgewertet, weil die Spalten DC sind und die Werte im Cache gefunden werden - Achtung: Cid ist eine U-Spalte und deswegen implizit DC. olglich wird eine Anfrage mit Cid = a im Cache ausgewertet, da der Wert a im Cache gefunden wird. Eine Anfrage mit diesem Prädikat hätte jedoch nicht zum Laden des Cache geführt, da Cid kein Cache Key ist - Cache-elegung nach einer Anfrage mit Cnr = 789 a b E_CUST Cnr CType CLocation Cid.... Altinel, M., ornhoevd, Ch., Krishnamurthy, S. Mohan, C., Pirahesh, H., Reinwald,.: Cache Tables: Paving the Way for an Adaptive Database Cache, in. Proc. VLD, erlin, gold gold silver silver SJ S NY LA - 0 a b NULL d07

21 DCache () DCache () CK-Regel - ür eine E-Tabelle dürfen n Cache Keys deklariert werden. - Höchstens ein Cache Key darf die Eigenschaft NU besitzen E_CUST Cnr CType CLocation Cid... 6 gold gold SJ S a b Cache Groups (orts.) - Zusammenhang zwischen E-Tabellen Wichtigste älle: eziehungen zwischen Primär-/remdschlüssel oder Owner-Member U->NU: Wenn ein PS-Wert im Cache gefunden wird, garantiert der Cache-Mgr, daß alle Sätze mit dem gleichen S-Wert im Cache sind Warum muß diese Einschränkung eingeführt werden? NU->U: Wenn ein S-Wert im Cache gefunden wird, ist der zugehörige Satz mit dem gleichen PS-Wert auch da Cache Groups - Wie wird der Zusammenhang zwischen E-Tabellen spezifiziert? Referential Cache Constraints beziehen sich auf Paare von Spalten (in der Regel verschiedener Tabellen) und sind vom Typ U->U, U->NU, NU->U, NU->NU (oder :, :n, n:, n:m) Alle Sätze im Cache erfüllen alle spezifizierten RCCs, d. h., wenn z.. NU->NU (oder U->NU) zwischen den Spalten A und von Tabelle S bzw. T spezifiziert ist, wird garantiert, daß alle T-Sätze mit einem Wert (=v i ) sich im Cache befinden, sobald ein S-Satz mit dem Wert (A=v i ) dort ist - Verknüpfung von Tabellen im Cache durch RCCs E-Tabelle mit einem Cache Key ist Wurzel-Tabelle einer Cache Group Sie kann mit anderen E-Tabellen ohne Cache Key über RCCs verknüpft sein So lassen sich Cache Groups bilden, die Verbundoperationen und, im all von NU->NU, Kreuzprodukte im Cache unterstützen edingung läßt sich nicht einschränken, da bei einem Verbund alle Verbundpartner da sein müssen! - -

22 DCache () Zusammenfassung Prinzip - Definition einer Cache Group über drei Tabellen A,, C und mit A.ck als Cache Key - Wertbasiertes Tabellenmodell im Cache: RCCs sind A.id->.id (U->NU) und A.cl->C.cl (NU->NU) RCCs können, müssen aber keine entsprechenden eziehungen in der E-D besitzen ck Referenzmuster in DS sind Mischformen - sequentielle, zyklische, wahlfreie Zugriff - Lokalität innerhalb und zwischen Transaktionen - bekannte Seiten mit hoher Referenzdichte Ohne Lokalität ist jede Optimierung der Seitenersetzung sinnlos (~ RANDOM) Suche im Puffer durch Hash-Verfahren id A U NU NU cl Speicherzuteilung: - global alle Pufferrahmen für alle Transaktionen (Einfachheit, Stabilität,...) - lokal Sonderbehandlung bestimmter TAs/Anfragen/ D-ereiche NU NU C ehandlung geänderter Seiten: NOORCE, asynchrones Ausschreiben Was passiert, wenn ein Anfrageprädikat A.ck = value bei leerem Cache ausgewertet wird? eispiel - Als E-D werde die des Web-uchhändlers verwaltet (mit ähnlichen Namen) - Cache Group: MC entspricht (U->NU)- und OC (NU->U)-eziehung CK: HAS_ORDER-MC Oid CType n CUST ORDER Cid HAS_ORDER-OC n Cid Iid ITEM n Aid AUTHOR WRITES-OC Aid Seitenersetzungsverfahren - zu genaue Verfahren sind schwierig einzustellen ( instabil) - Nutzung mehrerer Kriterien: Alter, letzte Referenz, Referenzhäufigkeit - CLOCK ~ LRU, aber einfachere Implementierung - GCLOCK, LRD, LRU-K relativ komplex - LRU- guter Kompromiß; vorletzter Referenzzeitpunkt bestimmt Opfer Erweiterte Ersetzungsverfahren - Nutzung von Zugriffsinformationen des Anfrage-Optimierers - Hot Set -Modell Double-Paging sollte vermieden werden HAS-MC HAS-OC n n n Oid ORDER_LINE Iid IS_ORDERED-OC D-Caching - will Skalierbarkeit und Leistungsverhalten bei Web-Anwendungen verbessern - Ansätze wie DProxy und DCache müssen Praxistauglichkeit noch erweisen - -