Query Result Caching

Optimierung des

Datenbankzugriffs

Andreas Hubmer info@cenarion.com

19.11.2012

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