Advanced Data Warehousing: Caching und Chunking 2.Feb.2004 Christian Becker cbecker@informatik.hu-berlin.de
Übersicht Motivation Caching dynamisch statisch Watchman und der LNC-Algorithmus Chunking Zusammenfassung
Caching: Motivation Antwortzeiten von Datenbanken verbessern: Hauptspeicher schneller als sekundärer Speicher Daten sind grösser als Hauptspeicher schnellere Rechner, mehr schneller Speicher Time == Money oft benutzte Teile zwischenspeichern, Algorithmen: gesuchte Daten im sekundären Speicher finden ist langsam: Indexstrukturen oft wiederholte Daten im Hauptspeicher lange zwischenspeichern
Caching: Arten des Caching Arten des Caching: a) statisches Caching Festlegung im Vornherein materialisierte Sichten denormalisierte Schemata b) dynamisches Caching muss sich auf aktuelle Anfragen anpassen Fragen: Algorithmen und Granularität: Tupel -> Tabellen -> Queries -> Chunks
Caching: Fragen des Caching Wie cache ich etwas? (statisch vs. dynamisch) Unterstützung durch Tools, Erfahrung Wann cache ich etwas? Cache-Admission: selten üblich (technische Gründe) Wann schmeisse ich etwas aus dem Cache? Cache Replace: viele, LRU ist üblich... aber... Wie nutze ich den begrenzten Cache optimal? misses minimal und billig machen Rucksack-Problem Ziel: Trefferquote erhöhen Metrik zur Realitätsmodellierung finden!
Caching: Watchman und LNC Intelligenter Cache Manager für DWHousing cached auf Query-Ebene Problem: Query Reuse nicht unproblematisch nutzt Admission und Replace-Algorithmus Novum: L(east) N(ormalized) C(ost)-R/A Trefferquote und Kosten sind wichtig Trefferquote durch Statistik über vergangene Nutzung erhöhen Kosten durch spätes Ersetzen von kostspielige Queries sparen (Beispiel... join vs. project)
Caching: Metrik Statistische Werte für jedes set RS i : i - durchschnittliche Referenzrate: Durchschnitt der mittlere Referenzrate K über die Zeit i = K / (t-t K ) s i - Größe des Query-sets ist trivial c i - Kosten der Ausführung für die Query via Query-Optimizer oder DB-Statistik Metrik: profit(rs i )=( i *c i )/s i
Caching: LNC-R LNC-R soll unprofitable Queries zuerst entfernen um Cache-Nutzung zu optimieren: 1.Query wird eingefügt, ist grösser als freier Platz 2.LNC-R sortiert nach profit selektiert sets mit geringstem profit preferiert beim Löschen: größere mit gleichem profit weniger referierte vor mehr referierten
Caching: LNC-A LNC-A soll für Cache unprofitable Queries aussortieren: 1.Query kann eingefügt werden 2.LNC-R bestimmt Replacement-Kandidatenliste C 3.LNC-A lässt zu, wenn: profit(rs neu )>profit(c) ODER (Neuzugänge) e-profit(rs neu )>e-profit(c) mit e-profit=c i /s i Heuristik
Caching: LNC-A (2) Löschung eines sets beinhaltet Daten (K und i ) neue sets sind automatische Löschkandidaten Lösung: Aufbewahren der Referenzierungsdaten: 5 Minute-Regel unpassend bei Kostenmodell Cachegröße beschränkt Löschung dann, wenn der Profit des aufbewahrten Satzes der kleinste aller aktuell im Cache befindlichen ist.
Caching: Watchman Implementation Watchman in der Realität ist eine Bibliothek cached primär auf Query-Identität auf Äquivalenz anpassbar... NP vollständiges Problem verlässt sich bei Updates auf das DWH kann mit dem Buffermanager zur Redundanzvermeidung interagieren gibt es funktionierende DBMS mit Query Caching?!
Caching: Watchman Tests Tests und Umgebung: TPC/D, 30Mbyte (statt 1 Gbyte) und Set Query, 100Mbyte (statt 200 Mbyte) Oracle 7 auf HP9000/700 Kriterien: Hit-Ratio (HR), Profit (darauf basierend) Test auf Grössen von K (1-4): Verbesserung des gesamten Profits/der HR Test auf Buffer-Manager-Interaktion Test auf Cachespeichernutzung: LNC-RA: 98,5%; >96% LCN-R/LRU: 94,8%; >88%
OLAP: Dimensionen denormalisierte Schemata: Star, Snowflake (hierarchische) Dimensionen eines Würfels Fakten Jahr Quartal Monat Tag Land Region Stadt Stadtviertel Industrie Kategorie Produkt
Chunking: Prinzip Operationen: aggregation, drill down, (screening), slicing gleiche Daten immer wieder und/oder hierarchische Bewegung durch die Daten Zerlegen des Würfels in Subwürfel, die gecached werden können: Zerlegung nach Ordnung: semantisch Zerlegung in Bereiche: uniform inspiriert durch MOLAP (Arrays entsprechend Raumes gespeichert) Ort Zeit Produkt
Chunking: Funktionsweise und Vorteile feste Granularität! gute Nutzung des Cache-Speichers einfaches Query-Reusing: Q3 kann Teile aus Q1und Q2 nutzen uniforme semantische Regionen closure property: Eigenschaften bleiben Aggregationen einfach möglich Q3 Q1 aus drei Ort -Chunks kann ein Zeit -Chunk berechnet werden keine Redundanz Q2 Ort Zeit Produkt
Chunking: Erstellen der Chunks uniforme und semantische Chunks brauchen: diskrete Aufteilung der Bereiche Ordnung innerhalb der Hierarchie: Erstellung Domain Index saubere Abbildung der niedrigeren Hierarchielevels auf höhere Level L2 kann und soll aus L3 zusammengesetzt werden L1 Nonfood Food L2 Spielzeug Küchenzubehör Gemüse Obst L3 Karten Rennauto Roboter Siedler Löffel Pfanne Topf Kartoffeln Apfel Birne
Chunking: Erstellen der Chunks (2) Granularität bestimmen - Dimensionen Verwaltungsaufwand vs. Reuseability (Proportionalität!) Formel für Chunk-ID-Berechnung Chunknummer muss aus Dimensionskoordinaten berechenbar sein Ort Ort Zeit Produkt Zeit Produkt
Chunking: Queries ausführen Queries können auf Chunks im Cache zurückgreifen, wenn: sie ein Star-Join sind (recht grundlegend) sie auf höherer oder gleicher Hierarchieebene aggregieren ihre Projektionslisten ein Subset sind die Selektionen auf non-group BY-Attribute exakt übereinstimmen
Chunking: Queries ausführen 1. Bereich der Query wird festgestellt 2. nötige Chunks werden im Cache gesucht 3. nicht gefundene Chunks müssen berechnet werden 4. neue Chunks werden dem Cache beigefügt Replace-Algorithmus: Gewinn=Basistabellengrösse/Chunkanzahl auf dem Hierarchielevel (des gerade berechneten Chunks) initiales Gewicht=Gewinn wird bei jedem neuen Cache-Eintrag um dessen Gewinn gesenkt wird bei jedem Zugriff auf das ursprüngliche Gewinn gesetzt 5. Antwortset wird zusammengefügt
Chunking: Erweiterung Dateisystem Idee basiert auf Three-Tier-System: DW-Tools -> Multidimensional View -> RDBMS Dateisystem des RDBMS wird in Chunks organisiert: Chunk Index, Angabe von Chunks holt fehlende Chunks multidimensionales Clustering der Chunks zusammengehörige Daten liegen beieinander grosse Dimensionsanzahlen verhindern effizientes Clustern und Indizieren! (siehe MOLAP)
Chunking: Tests Tests und Umgebung: eigene Tests auf 4-dimensionalem Cube 1500 Queries, Hot Region (69%, 80%, 100%), Proximity modifiziertes PARADISE auf HP9000/700 Kriterien: Profit (Watchman) Durchschnittszeit der letzten 100 Queries Test: veränderte Cachegrösse Verbesserung, rapide ab 10% des Cube (reuse) Test: Lokalität, Range-Ratio, Replacement-Algorithmus
Caching und Chunking: Fazit Cache Replace- und Cache-Admission-Algorithmen verbessern Effizienz werf ich etwas zu früh/spät aus dem Cache, verursache ich Extrakosten Ansatz unabhängig von Cache-Level (gut!) semantische Caches haben interessante Ansätze Chunking unterstützt DWHousing enorm chunked Dateisysteme: können das unterstützen zu welchen Kosten? funktioniert MOLAP?
Fragen?
Literatur: WATCHMAN: A Data Warehouse Intelligent Cache Manager Peter Scheuermann, Junho Shim, Radek Vingralek; The VLDB Journal 1996 Caching Multidimensional Queries Using Chunks Prasad Deshpande, Karthikeyan Ramasamy, Amit Shukla, Jeffrey F. Naughton; 1998 Fundamentals of Data Warehouses Matthias Jarke, Maurizio Lenzerini, Yannis Vassiliou, Panos Vassiliadis; 2003 Springer-Verlag