Query Result Caching. Optimierung des Datenbankzugriffs

Größe: px

Ab Seite anzeigen:

Download "Query Result Caching. Optimierung des Datenbankzugriffs"

Lars Beck
vor 5 Jahren
Abrufe

1 Query Result Caching Optimierung des Datenbankzugriffs Andreas Hubmer

2 Inhalt Problemstellung Tabellen-Cache DBProxy Objekt-Cache 1 st -/2 nd -Level Cache Query Cache 2

3 Problemstellung Application- Server Application- Server Application- Server DB-Server Überlastung 3

4 Lösung 1: Datenbank skalieren Application- Server Application- Server Application- Server DB-Server DB-Server Synchronisation Lizenzen 4

5 Lösung 2: Caching Application- Server DB-Cache Application- Server DB-Cache Application- Server DB-Cache DB-Server Entlastet DB Beschleunigt Zugriff 5

6 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

7 Tabellen-Cache: DBProxy Materialized-Views in lokaler DB Implementiert als JDBC-Treiber Ergebnis Query Ergebnis DB-Call Query Rewrite nein Treffer? ja Query am Cache ausführen nein Insert? ja Cache Insert Lokale DB 7

8 DBProxy: Lokale DB Pro gecachter Tabelle eine lokale Kopie horizontal und vertikal unvollständig Pro gecachter Join-Query eine lokale Tabelle 8

9 Beispiel Lokale Kopie einer Tabelle produkt: Id Preis Anzahl NULL 18 8 NULL 20 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 Im Cache: SELECT Id FROM produkt WHERE Anzahl BETWEEN 10 AND 15 9

10 Query Matching Gecachte Queries beschreiben Cache- Inhalt Query Containment i.a. nicht lösbar aber für einfache Queries entscheidbar Schneller: Template-basiert 10

11 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

12 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

13 Überblick Application Server Transaktion 1st-Level Transaktion 1st-Level 2 nd - Level Cache DB-Server Transaktion 1st-Level 13

14 1 st -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

15 1 st -Level-Cache: Beispiel Applikations-Code BEGIN TX SELECT p FROM person AS p WHERE p.id=1 Was tatsächlich geschieht BEGIN TX SELECT * FROM person WHERE id=1 personcache.put(1, p) SELECT p FROM person AS p WHERE p.id=1 p.setfirma( Cenarion ) personcache.get(1) END TX UPDATE person SET firma= END TX 15

16 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

17 2 nd -Level-Cache Pro Application Server Für alle Transaktionen gemeinsam Ebenso ID Objekt Wird befüllt beim Lesen und Commit 17

18 2 nd -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

19 Query Cache SELECT WHERE nonid= value Objekt-ID notwendig für 1st/2nd-Level-Cache Schlüssel: Query-Name + Parameter Werte: Objekt-Ids Mit diesen 1 st /2 nd -Level-Cache befragen Pro Application Server 19

20 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 bei mehreren Servern 20

21 Verwendungstipps (1) Zuerst andere Optimierungen (zb: Indizes) 1 st -Level-Cache ist immer aktiv 2 nd -Level-Cache: Wenn viele Lesezugriffe vorkommen Veraltete Daten ohne Transaktionsunterstützung Pro Entity entscheiden Performance messen (Speicherbedarf, Beschleunigung, DB-Entlastung) 21

22 Verwendungstipps (2) Query-Cache: Nur mit 2 nd -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

23 Referenzen [1] Khalil Amiri, Sanghyun Park, Renu Tewari, Sriram Padmanabhan: DBProxy: A dynamic data cache for Web applications. ICDE 2003: [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): (2008) [3] JPA offiziell: [4] JPA Tutorial: 23

24 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

Ähnliche Dokumente

Inhaltsverzeichnis. Bernd Müller, Harald Wehr. Java Persistence API 2. Hibernate, EclipseLink, OpenJPA und Erweiterungen ISBN:

Inhaltsverzeichnis. Bernd Müller, Harald Wehr. Java Persistence API 2. Hibernate, EclipseLink, OpenJPA und Erweiterungen ISBN: Inhaltsverzeichnis Bernd Müller, Harald Wehr Java Persistence API 2 Hibernate, EclipseLink, OpenJPA und Erweiterungen ISBN: 978-3-446-42693-1 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42693-1