View
1.053
Download
3
Tags:
Embed Size (px)
Citation preview
Inhalt
• Problemstellung
• Tabellen-Cache
– DBProxy
• Objekt-Cache
– 1st-/2
nd-Level Cache
– Query Cache
2
Überlastung
Problemstellung
3
DB-Server
Application- Server
Application- Server
Application- Server
Lösung 1: Datenbank
skalieren
4
DB-Server
Application- Server
Application- Server
Application- Server
DB-Server • Synchronisation • Lizenzen
DB-Cache
DB-Cache
DB-Cache
Lösung 2: Caching
5
DB-Server
Application- Server
Application- Server
Application- Server
• Entlastet DB • Beschleunigt Zugriff
Query Result Caching
• Ziel
– Hohe Cache-Hit-Rate
• Self-Management
– Schnelles Query-Matching
– Konsistenz
– Unabhängig von DB-Implementierung
• Tabellen-Cache vs. Objekt-Cache
6
Tabellen-Cache: DBProxy
• Materialized-Views in lokaler DB
• Implementiert als JDBC-Treiber
7
Query
Query am Cache ausführen
Ergebnis
Lokale DB
ja Query
Rewrite DB-Call
Insert? Cache Insert
Ergebnis
ja
nein
nein
Treffer?
DBProxy: Lokale DB
• Pro gecachter Tabelle eine lokale
Kopie
– horizontal und vertikal unvollständig
• Pro gecachter Join-Query eine lokale
Tabelle
8
Beispiel
Id Preis Anzahl
1 14 8
2 15 22
5 16 13
7 NULL 18
8 NULL 20
9
Q1: SELECT Id, Preis, Anzahl FROM produkt WHERE Preis BETWEEN 14 AND 16
Q2: SELECT Id, Anzahl FROM produkt WHERE Anzahl BETWEEN 10 AND 20
Lokale Kopie einer Tabelle produkt:
Im Cache:
SELECT Id FROM produkt WHERE Anzahl BETWEEN 10 AND 15
Query Matching
• Gecachte Queries beschreiben Cache-
Inhalt
• Query Containment
– i.A. nicht lösbar
– aber für einfache Queries entscheidbar
• Schneller: Template-basiert
10
Konsistenz
• Update-Queries (update, delete, insert)
– werden am DB-Server ausgeführt
– werden vom DB-Server an die Proxies
weitergegeben
• Verzögerte Konsistenz
• Monotone Zustandsübergänge
• Sichtbarkeit von Updates
• Transaktionen nicht unterstützt
11
Praxis: Objekt-Cache
• Objektrelationaler Mapper (ORM)
– Entity: Klasse, die persistiert wird
• Transaktion pro Anwendungsfall
• RAM oder Festplatte
• Wichtig: Jeder DB-Zugriff geht über
den ORM
12
Überblick
13
DB-Server
Application Server
Transaktion
2nd- Level Cache
1st-Level
Transaktion 1st-Level
Transaktion 1st-Level
1st-Level-Cache
• Hash-Tabelle pro Entity-Klasse
• Schlüssel: Objekt-ID =
Tabellenschlüssel
• Werte: Objektinstanzen
• Im Rahmen einer Transaktion
– Kein Synchronisationsbedarf zu anderen
Application-Servern
14
1st-Level-Cache: Beispiel
Applikations-Code
BEGIN TX
SELECT p FROM person AS p
WHERE p.id=1
SELECT p FROM person AS p
WHERE p.id=1
p.setFirma(‘Cenarion‘)
END TX
15
Was tatsächlich geschieht
BEGIN TX
SELECT * FROM person
WHERE id=1
personCache.put(1, p)
personCache.get(1)
UPDATE person SET firma=…
END TX
Puffer für Schreibzugriffe
• Update, Insert, Delete erst mit
Transaktionsende
• Ausnahme:
– Objekt vom Typ A wurde verändert: Vor
einer DB-Query über A müssen die
Änderungen persistiert werden
– Manueller Flush
16
2nd
-Level-Cache
• Pro Application Server
– Für alle Transaktionen gemeinsam
• Ebenso ID → Objekt
• Wird befüllt beim Lesen (SELECT) und
Commit (UPDATE, INSERT, DELETE)
17
2nd
-Level-Cache: Konsistenz
• Strategien:
– Read-Only
– Read-Write: keine serialisierbare
Transaktion
– Transaktional: 2PC (teuer)
• Mehrere Application-Server
– Synchronisation wie bei verteilter DB
(außer Read-Only)
– Veraltete Daten, TTL setzen
18
Query Cache
• SELECT … WHERE nonId=‘value‘
– Objekt-ID notwendig für 1st/2nd-Level-
Cache
• Schlüssel: Query
• Werte: Objekt-IDs
– Mit diesen 1st/2
nd-Level-Cache befragen
• Pro Application Server
19
Query Cache: Konsistenz
• Bei Änderungen an einer Tabelle A
werden alle gecachten Ergebnisse für
Queries über A ungültig
• Mittels Timestamp
– Timestamp pro Tabelle und gecachter
Query
– Viel Locking notwendig
• Synchronisation der Tabellen-
Timestamps
20
Verwendungstipps (1)
• Zuerst andere Optimierungen (zB:
Indizes)
• 1st-Level-Cache ist immer aktiv
• 2nd
-Level-Cache:
– Wenn viele Lesezugriffe vorkommen
– Veraltete Daten ohne
Transaktionsunterstützung
– Pro Entity entscheiden
– Performance messen (Speicherbedarf,
Beschleunigung, DB-Entlastung) 21
Verwendungstipps (2)
• Query-Cache:
– Nur mit 2nd
-Level-Cache gemeinsam
– Tabellen mit (fast) nur Lesezugriff
– Bei natürlichen Schlüsseln
(≠Primärschlüssel)
• Speicherbedarf
– Objekte+Referenzen
• Keine direkten DB-Manipulationen per
SQL
22
Referenzen
• [1] Khalil Amiri, Sanghyun Park, Renu Tewari, Sriram Padmanabhan: DBProxy: A dynamic
data cache for Web applications. ICDE 2003: 821-831
• [2] Charles Garrod, Amit Manjhi, Anastasia Ailamaki, Bruce M. Maggs, Todd C. Mowry,
Christopher Olston, Anthony Tomasic: Scalable query result caching for web
applications. PVLDB 1(1): 550-561 (2008)
• [3] JPA offiziell: http://docs.oracle.com/javaee/6/tutorial/doc/bnbpy.html
• [4] JPA Tutorial: http://en.wikibooks.org/wiki/Java_Persistence
23
Zusammenfassung
• Problem: DB-Überlastung
• Lösung: Caching am Application-
Server
• Herausforderung Synchronisierung
– Caching besonders sinnvoll bei weniger
strikten Anforderungen
• Vorteil Objekt-Cache:
– Näher an der Applikation – leichter zu
steuern
• Self-Management ist eine Vision 24