Caching für Data Analysis Seminar Data Warehousing und Mining WS 99/00 Pascal Mayer 14.11.1999

Inhaltsverzeichnis 1. Einleitung und Motivation 2. Klassifizierung 3. Dynamischer Cache 4. Replacement Strategie 5. Granularität 5.1 Semantische Regionen 5.2 Chunks 6. Aktiver Cache 7. Zusammenfassung 8. Literaturverzeichnis

1. Einleitung und Motivation Verschiedene Gründe motivieren neue und bessere Cache Managers für OLAP Anwendungen zu entwickeln: rel. statischer Datenstamm bei OLAP Datenmenge wird immer grösser Queries werden immer komplexer Lokalität von OLAP Queries Es gilt den (teuren) Cachespeicher effektiv auszunutzen und die (teuer) berechneten Daten effektiv wiederzuverwenden.

2. Klassifizierung Caching Schemas können nach folgenden Kriterien klassifiziert werden I. statisch versus dynamisch II. Granularität I. statischer Ansatz dynamischer Ansatz unabhängig von Queries backend, serverside precomputing aggregated tables middle tier laufende Anpassung

2. Klassifizierung II. Granularität (Beispiele) page/table query statische Schemas basieren oft auf page Granulariät Clients berechnen relevante Pages einfacher LRU Algorithmus als Ersetzungsstrategie ausreichend query enthalten-Beziehung wird ausgenutzt semantic region Raum durch Bedingungen in Regionen unterteilt Grösse und Form der Regionen sind unterschiedlich Grösse und Form kann sich im Laufe der Zeit ändern chunk Spezialisierung des Konzepts der semantischen Regionen Berücksichtigung von Aggregationen uniforme statische Regionen

3. Dynamischer Cache Replacement und Admission Algorithmen spielen eine zentrale Rolle in der Entwicklung von Cache Managers. begrenzte Kapazität erfordert Ersetzungsstrategie der Nutzen von Daten kann aus verschiedenen Parametern (Ausführungszeit, Zugriffsrate…) berechnet werden Durch die Änderung der Organisation der Daten im Cache und deren Granularität kann die Effizients des Caches erhöht werden Ansätze: Semantische Regionen Chunks Aktiver Cache

4. Replacement und Admission Als Basis für die weiteren Ausführungen wird die Replacement Strategie des WATCHMAN Cache Mangers vorgestellt. WATCHMAN (WArehouse inTelligent caCHe MANager) Granularität: caching ganzer Resultat Mengen einzelner Queries Replacement Strategie: zwei Algorithmen - Replacement: Welches Resultat-Set soll für das neue ausgelagert werden? - Admission: Nutzen der Daten genügend gross, dass sich die Auslagerung alter Daten lohnt? Performance Metrik für die Bestimmung des Nutzens eines abgerufenen Sets

Nutzen von cached Daten Der Nutzen eines Resultat Sets RS einer Query Q hängt z.B. von folgenden Parametern ab mittlere Zugriffsrate auf Q Grösse des Sets RS Kosten für die Ausführung von Q Verbindungsaufbau zum Server WATCHMAN berechnet den Profit (Nutzen) eines Result Sets anhand der folgenden Performance Metrik: mittlere Zugriffsrate x Ausführungszeit profit(RS) = Grösse “Wieviel Ausführungszeit wird bei der Speicherung des Result Sets eingespart im Verhältnis zu seiner Grösse?”

Beispiel Replacement Beispiel: Wir erhalten ein Result Set und möchten es im Cache speichern. Annahme: Das Result Set ist im Cache noch nicht vorhanden und der Cache ist voll. Replacement Algorithmus: Cache: Eingabe: Grösse des Result Set Sortiere Sets nach Profit: Ausgabe: Liste der besten Kandidaten

Beispiel Admission Admission Algorithmus: Cache: Eingabe: Result Set RS Kandidaten Berechne den Æ Profit der Kandidaten: if (Profit(RS) > Profit(Æ Kandidaten)) ersetze die Kandidaten mit dem neuen Set Cache neu: In unserem Beispiel wird das neue Result Set gespeichert.

Mittlere Zugriffsrate Frage: Wie berechnen wir die mittlere Zugriffsrate? WATCHMAN schätzt die Zugriffsrate aufgrund der K letzten Zugriffe auf das entsprechende Result Set. K Ausführungszeit = Zeitjetzt - Zeitk-ter Zugriff

5. Granularität Fragen: Wie können wir die redundante Speicherung überlappender Result Sets verhindern? Beispiel: Q1 Q2 Q1 Q2 Anfragen an DB Cache Wie können bereits gespeicherte Daten effizienter genutzt werden? Beispiel: Q1 ist im Cache Q2 kann aus dem Cache beantwortet werden Schnittmenge von Q3 nicht Q1 Q2 Q3

5.1 Semantische Regionen Ansatz: Wir gruppieren Result Sets in semantischen Regionen, welche die Units für das Cache Replacement und den Abruf von Informationen bilden. Beispiel: Wir möchten alle Angestellten finden, die über 50’000.- verdienen und jünger als 30 Jahre sind. Gesucht Gehalt 100’000 50’000 Alter

Aufteilung der Anfragen Annahme: Im Cache sind alle Angestellten gespeichert, die weniger als 100’000.- verdienen und alle die zwischen 25 und 28 Jahren sind. Gesucht Gehalt 100’000 100’000 Cache 50’000 50’000 Alter 15 30 15 30 Probe Query 15 30 100’000 50’000 Remainder 15 30 100’000 50’000

Probe und Remainder Query Strategie bei Anfragen: Queries werden in zwei unabhängige Teile gespalten probe query, gibt die Informationen, welche im Cache gespeichert sind, zurück remainder query, Anfrage an Server für die fehlenden Tuples Die semantischen Regionen werden abhängig von den Queries dynamisch neu definiert. Beispiel: Region after Q1 Regions after Q2 Regions after Q3

Replacement Für semantische Regionen eignet sich die Manhatten Distance Ersetzungsstrategie besonders gut. Def: Jeder semantischen Region wird der negative Wert der manhatten distance zwischen dem eigenen “Schwerpunkt” und dem “Schwerpunkt” der neuesten Region zugewiesen. Beispiel: Regions after Q2 Regions after Q3 -3 -4 -7 Region after Q1

5.2 Chunks Chunk basiertes Caching ist eine weiterentwickelte Variante der Semantic Region Strategie. Neu: der multi-dimensionale Raum wird in uniforme, statische Chunks aufgeteilt Product Region Time Ziel: Berücksichtigung von aggregierten Daten imCache.

Bildung von Chunks Frage: Wie wird der multi-dimensionale Raum in Chunks aufgeteilt? Ansatz: numerische Dimensionen werden gleichmässig unterteilt nicht-numerische Dimensionen erfordern die Speicherung zusätzlicher Informationen betreffend der Reihenfolge der unterschiedlichen Werte Country State City USA (0) Indien (1) WI (0) CA (1) Madison (0) Milwaukee (1)

Vorteil von Chunks Wir machen uns die hierarchische Strukur von OLAP Anfragen und das Closure Property von Chunks zunutze, um den Cache noch effektiver einsetzen zu könen. Beispiel für die hierarchische Strukur von OLAP Anfragen: USA WI CA Madison Milwaukee USA WI CA Madison Milwaukee Query 2 fordert Daten auf einer höheren (Product, Country) oder tieferen Ebene (Product, City) an Q1 Query 1 auf der Ebene (Product, State)

Closure Property Beispiel für das Closure Property: Die Aggregation der Chunks (0, 1, 2, 3) von (Product, Time) entspricht dem Chunk 0 von (Time). Product Time 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 In einer ersten Implementation des Cache Managers wurden aggregierte Daten nur für die Berechnung von Anfragen auf dem gleichen Level genutzt.

Replacement Strategie Benefit und Weight der “benefit” eines Chunks entspricht dem Bruchteils der Basistabelle, die das Chunk repräsentiert das “weight” eines cached Chunks bezieht sich auf den letzten Zugriff Beispiel: Wir möchten den durchschnittlichen Umsatz auf zwei verschiedenen Ebenen berechen Basistabelle Grösse: D Land Stadt Produkt Umsatz Italien Rom 1 100 Italien Rom 2 80 Italien Genua 2 60 Schweiz Basel 1 200 Schweiz Basel 2 120 Schweiz Zürich 2 100

Replacement Strategie Der durchschnittliche Umsatz gruppiert nach (Land): Land Æ Umsatz Italien 80 Schweiz 140 Anzahl Chunks: 2 D 2 benefit = nach (Land,Stadt): Land Stadt Umsatz Italien Rom 90 Italien Genua 60 Schweiz Basel 160 Schweiz Zürich 100 Anzahl Chunks: 4 benefit = D 4 Die Profit Metrik “benefit” berücksichtigt die Kosten für die Berechnung eines Chunks.

Replacement Beispiel Cache: Eingabe: neues Chunk b:4 w:0 Clock b:4 w:4 Eingabe: neues Chunk b:3 w:0 weight > 0 at Clock ! weight = weight - benefit(neues Chunk) advance Clock Algorithmus: Cache: Clock b:4 w:0 b:4 w:1 weight <= 0 at Clock ! Chunk löschen neues Chunk einfügen weight updaten Algorithmus: Cache: b:4 w:1 b:3 w:3

Performance Gewinn Def. Die Cost Saving Ration sagt aus, wieviel Ausführungszeit durch Cache-Hits eingespart wird. Normales Query Caching hat eine CSR zwischen 0.2 und 0.4. Chunk Caching im Vergleich zu Query Caching: mittlere Antwortzeit 25% - 50% besser CSR zwischen 0.7 und 0.8 Benefit-LRU im Vergleich zu Simple-LRU: mit Chunks: mittlere Antwortzeit ca. 40% besser mit Queries: mittlere Antwortzeit nur ca. 5% besser CSR zwischen 0.5 und 0.6

6. Aktiver Cache Auf der Basis der chunk caching Strategie wurde ein “Aktiver Cache” entwickelt, mit dem Ziel aggregierten Daten besser zu nutzen. Probleme: in einem multi-dimensionalen Schema gibt es verschiedenen mögliche Levels der Aggregation, welche unterschiedlichen group-by Operationen entsprechen Beispiel: (1,2,1) Dimension Levels A A1, A0 = ALL B B2, B1, B0 = ALL C C1, C0 = ALL (1,2,0) (1,1,1) (0,2,1) (0,2,0)

6. Aktiver Cache Der konstengünstigste Weg wird berechnet, und die gewünschten Informationen aus den benötigten Chunks gefiltert. Die Neuorganisation der Daten am Backend in der Form eines chunked Filesystem unterstützt die Caching Strategie zusätzlich. Replacement: Chunks werden in nach zwei Typen klassifiziert - backend chunks und computed chunks backend chunks besitzen eine höhere Priorität backend chunks können computed chunks ersetzten, nicht jedoch umgekehrt Performance Gewinn: mittler Ausführungszeit 50% - 70% besser

7. Zusammenfassung Wie wir gesehen haben gibt es unterschiedliche Ansätze, den Cache zu verwalten. Hauptansatzpunkte: die Granulariät beeinflusst die Verwaltung des Cachespeichers in Bezug auf Geschwindigkeit und Ausnützung des vorhandenen Platzes die Replacement Strategie wird der gewählten Granularität angepasst eine Neuorganisation der Daten am Backend kann eine gewählte Strategie zusätzlich unterstützen (Chunked Filesystem)

Granularität Die Wahl der Caching Units löst sich von der intuitiven Granularität der Queries. Semantische Regionen Chunks Es wird versucht, durch die Organisation der Daten im Cache, spezifische Eigenschaften von OLAP-Anfragen zu nutzen. überlappende Datenmengen nicht redundant speichern hierarische Struktur von OLAP-Anfragen berücksichtigen

Replacement Strategie Folgende Replacement Strategien wurden vorgestellt: einfacher LRU profit-Replacement mit Admission Manhatten Distance benefit-LRU Replacement Strategien verwenden spezifische Eigenschaften der gewählten Granularität, um den Nutzen der gespeicherten Daten zu berechnen. Die verschiedenen Strategien sind deshalb nur schwer miteinander vergleichbar.

8. Literaturverzeichnis Peter Scheuermann, Junho Shim, Radek Vingralek. WATCHMAN: A Data Warehouse Intelligent Cache Manager. Proceedings of the 22nd VLDB Conference Bombay, 1996. Shaul Dar, Michael J. Franklin, Björn T. Jónsson, D. Srivastava, Michael Tan. Semantic Data Caching and Replacement. Proceeding of the 22nd VLDB Conference Bambay, 1996 Prasad M. Deshpande, Karthikeyan Ramasamy, Amit Shukla, Jeffrey F. Naughton. Caching Multidimensional Queries Using Chunks. Proceeding of the ACM SIGMOD Int. Conf. On Mgmt. Of Data, 1998 Prasad M. Deshpande, Jeffrey F. Naughton. Aggregate Aware Caching for Multi-Dimensional Queries. Proceeding of the 26nd VLDB Conference ….., 2000