Strategie
Wie wir bereits gesehen haben, ist Caching immer auch mit Kosten verbunden. Einerseits bei der Server-Hardware andererseits aber auch mit Entwicklungsaufwand. Es sollten also nicht blind alle Datenbankabfragen irgendwo zwischengespeichert werden. Dazu müssen auch bereits vorhandene Caches mit bedacht werden.
Ein Beispiel:
|
1 |
SELECT text FROM translation WHERE key = 'foobar' AND lang = 'en' |
Wir wollen also eine Übersetzung aus der Datenbank. Die Abfrage findet bei jedem Seitenaufruf statt (also oft) und wir wollen optimieren. Erste Idee könnte ein MemCache sein, da Übersetzungen alle Server gleichermaßen benötigen und es auch ziemlich viele sind. Bringen wird das aber leider nichts. Die Datenbank ist selbst schlau genug hier die Daten im Query-Cache und Result-Cache vorzuhalten. Genügend RAM vorausgesetzt, kopiert sie sogar die komplette Tabelle und bedient alle Anfragen nur aus dem RAM. Das kann MemCache auch nicht schneller. Einen echten Gewinn erzielen wir also nur, wenn wir den Aufwand für’s Netzwerk entfernen und die Daten lokal vorhalten.
Eine weitere Frage, die geklärt werden muss, ist die Gültigkeit der Daten. Jeder Caching-Mechanismus erlaubt eine Time-To-Live (TTL), nach der die Daten verfallen. Für sinnvolles Caching müssen die Daten also wenigstens ein paar Minuten konstant bleiben (dürfen). Bei Übersetzungen ist das sicher gegeben, bei Statistiken muss ein Kompromiss gefunden werden zwischen Aktualität und Aufwand.
Ebenfalls nicht vergessen sollte man die Möglichkeit Daten schlicht direkt im Programm in einer Variable vorzuhalten. Sie sind dann zwar nur für ein Request gültig, aber häufig wird die Datenbank schon deutlich entlastet. Die meisten ORMs nutzen dieses Prinzip.
Die verschiedenen Schichten für Datenproduktion sind also:
- Variable
- lokaler Cache
- Cache im Netzwerk
- Datenbank
Je schwieriger die Daten zu beschaffen sind, umso mehr dieser Schichten werden lohnenswert.