Eine Semesterarbeit von Sebastian Galenski (2. Semester – WWI 00 B) SQL Query Result Caching Oder wie man häufig gestellte Datenbankabfragen performanter

eine Semesterarbeit von

Sebastian Galenski

(2. Semester – WWI 00 B)

SQL Query Result CachingOder wie man häufig gestellte Datenbankabfragen performanter bekommt

Sebastian Galenski - WWI 00 B

SQL Query Result Caching

Oder wie man häufig gestellte Datenbankabfragen performanter bekommt

>> Gliederung <<

1. Queries – Was ist im folgenden mit „Queries“ gemeint ?

2. Caching – Warum werden Queries gecached ?

3. Techniken

4. Caching auf dem „local filesystem“

5. Vergleich – „mit / ohne“ dem hier vorgestellten Caching-Verfahren

6. Beispiel – aus der Praxis

7. Fazit – Schluss

1. Queries




Was ist im folgenden mit „Queries“ gemeint ?




>> 1. Queries <<

• Ergebnismenge einer Datenbankabfrage

• Also die Ergebnistabelle, einer SQL-Abfrage

• aufgebaut wie eine normale Tabelle

• Entitätsmenge – also eine Ansammlung von Entitäten und deren Attribute

2. Caching




Warum werden Queries gecached ?




>> 2. Caching <<

Bei hoch dynamischen Web-Seiten -> bis zu 15 SQL-Abfragen

3 Gründe um sich ein Caching der Queries zu überlegen:• Der Datenbank Server ist entfernt• Hoher Traffic • Abfragen sind wiederkehrend, sie ändern sich

• zu bestimmten Zeiten • bei einer Interaktion mit dem Redakteur / Admin

Diese kosten hauptsächlich Zeit

Performance-Gewinn bei der Generierung wird angestrebt

3. Techniken







>> 3. Techniken <<

Es gibt zwei generelle Techniken:

• man kann sich auf den Datenbank-Server verlassen und auf dessen Caching hoffen

• man programmiert selbst ein Caching mit Hilfe des lokalen Filesystems

4. Caching auf dem „local filesystem“







>> 4. Caching auf dem „local filesystem“ <<

Die Theorie I:

• Vermittler zwischen Datenbank-Server und Webanwendung• SQL-Abfrage und das Wissen über dessen Lifetime an das

Cachemodul übergeben• Identifier für den entsprechenden CacheFile• Datenbankname und MD5-Prüfsumme über das SQL-

Statement

Datenbank : bzo_anzeigenTabelle : testanzeigenSQL-Statement : SELECT * FROM testanzeigenResultierender Cachefile : bzo_anzeigen_54a73ab20628171c7d650745aea5992a.cache





Die Theorie II:

• überprüft das Cachefile auf das Datum der letzten Änderung• Falls die Lifetime abgelaufen ist:

• SQL-Abfrage an die Datenbank • zurückkommende Ergebnisstabelle serialisieren

• Falls die Lifetime noch gültig ist:• den Inhalt des Cachefiles deserializieren (wandelt den

Fliesstext wieder in brauchbare Variablen um)





Vorteile:

• es spielt keine Rolle mehr, ob der DB-Server auf der gleichen Maschine oder auf einer entfernte Maschine läuft

• viele Billigprovider bieten zu ihren Hostingangeboten keine

Datenbank an. Kein Problem mehr, einfach die Webanwendung und den Cache dort ablegen und der Cache spielt für die Anwendung im Prinzip den Datenbank-Server

5. Vergleich




„mit / ohne“ dem hier vorgestellten Caching-Verfahren




>> 5. Vergleich <<

6. Beispiel




aus der Praxis

http://www.badische-zeitung.de




>> 6. Beispiel <<BZ-Online

• WebServer auf 3 NetBSD Maschinen im Cluster

• PHP• MySQL entfernt

aber im Cluster

ohne das Caching:4.5042 sec

mit dem Caching:0.3081 sec

7. Fazit – Schluss







>> 7. Fazit – Schluss <<

Vielen Dankfür Ihre Aufmerksamkeit

Infos, Download der Cache-Klasse für PHP/MySQLund diese Präsentation

finden Sie unter http://qrc.galenski.de

Documents

Eine Semesterarbeit von Sebastian Galenski (2. Semester – WWI 00 B) SQL Query Result Caching Oder wie man häufig gestellte Datenbankabfragen performanter