02
FEB09Die Welt um MemCache
Der Namensraum
Simple gesagt, gehen wir einfach hin und sagen z.B. alle Querys (alle Schlüssel) die auf die Tabelle “user_tabelle” gemacht werden, sollen in einem seperaten Array abgespeichert werden. Wenn sich jetzt ein Benutzer löscht oder sich neu registriert dann durchlaufen wir einfach das Array und löschen alle Schlüssel die in diesem “Namensraum” liegen, somit werden dann nach der Aktion alle Querys die mit der Tabelle zusammen hängen gelöscht und wir haben immer frische, neue Ergebnisse :) Man kann die Namensräume entweder auch in der Datenbank abspeichern aber ich finde das ablegen im Memcache von vorteil, wenn wir schon Memcache haben dann müssen wir es auch ausnutzen :) Hier mal ein Beispiel wie das ganze aussehen könnte:
1 2 3 4 5 6 7 8 |
// Namensraumarray für user_tabelle Array { [0] => d2c11766b5677c274b07661ba261a42e, [1] => 23c6de8b91e30d1fadd5c57d25d7d095 } |
Wieso kein QueryCache von MySQL?
Ich habe leider keine guten Erfahrungen mit dem QueryCache von MySQL gemacht. Es heißt ja:
Wenn eine Tabelle geändert wird, werden alle Abfragen, die die
Tabelle verwenden, ungültig und insofern aus dem Cache entfernt.
Ich habe damals mehrmals den QueryCache getestet aber manchmal hing er richtig … kp warum das so ist/war aber von 4 Inserts hat er bei einem mal nicht den Cache geleert und das ist an dieser Stelle der Horror. Zudem hat man mit Memcache die Möglichkeit auch komplette HTML Segmente einer Seite abzuspeichern.
Ich hoffe ich habe euch mit diesem Beitrag einen kleinen denkanstoß gegeben, den ich damals nicht hatte und bei uns die Köpfe geraucht haben :)
1 Kommentare
Hallo Dennis,
bin grad eher durch Zufall auf deinen Blog gestoßen.
Ich setze mich gerade selbst mit Memcache auseinander, da es für mein Projekt wohl mehr oder weniger von essentieller Bedeutung sein wird, da wir zur Zeit ein CMS nutzen, welches – gelinde gesagt – unter aller Sau ist…
Wie dem auch sei – es ist unter Umständen besser gewisse Dinge nicht zu cachen, unter anderem ziemlich sicher die Userdaten.
Du nimmst als Beispiel die Abfrage:
SELECT * FROM user_tabelle;woraus ich den Eindruck habe, dass du sämtliche Userregistrationsdaten zwischenspeicherst. Wir haben ebenfalls über 100.000 User im Forum registriert, entspricht etwa 20MB unkomprimierten Speicherplatz (Forum: Woltlab Burning Board). Was meinste, wie lange Memcache braucht, diese Daten wieder auszusprucken um diese für PHP verfügbar zu machen? Mehr Zeit, als eine simple DB-Abfrage bezogen auf einen speziellen User, dessen Daten du abfragen willst – dessen kannst du dir sicher sein.
Okay, nun glaube ich nicht wirklich, dass du es wirklich so machst und die gesamte User-Tabelle im Cache speicherst, das wäre in der Tat ineffektiv und etwas, nunja, dumm ums krass zu formulieren. Besser ist es, wenn du da ein anderes Beispiel für eine sinnvolle Nutzung von Memcache nutzt, wie z.B.:
Cachen von Gruppendaten und deren Zugriffsrechte
Cachen der letzten 20 News, Downloads, Artikel, die auf der Hauptseite angezeigt werden sollen
Cachen der letzten aktiven Postings der vergangenen Stunde
Cachen von CM-Systemeinstellungen
usw. Also eher kleinere Sachen, die so gut wie nie geändert werden müssen oder derer Änderungsfrequenz 30-60 Sekunden betragen darf, bevor jemandem Auffällt, dass die Daten nicht mehr stimmen können (beispiel: News können ruhig 30 sek. inkl. Kommentarzähler gecached werden, ohne dass großartig jemanden auffällt, dass statt 10 Kommentaren schon 12 vorhanden sind). Oder: Cachen von Daten, die innerhalb einer vergangenen (halben) Stunde aufgerufen wurden, da sich die User meist für solche Daten interessieren. Alles was jedoch schon sehr alt ist (also >1 Stunde) muss aus dem Cache gelöscht werden um speicherplatz frei und das System damit schneller und effizienter zu machen.
Es sind insbesondere im Falle von Systemeinstellungen und Ähnlichem Daten, die “ständig” aufgerufen und zwingend gebraucht, aber seltenst geändert werden.
Andersherum gesagt: Man sollte niemals jeden Furz zwischenspeichern, wichtig ist, dass viele ständig, wenig selten aufgerufene Daten gecached werden.
Das wird aus deinem Artikel – den ich ansonstens vollkommen okay finde – nicht deutlich.
Und im Ãœbrigen: Es ist nicht zwingend notwendig in “Schlüsseln” per MD5 zu speichern.
Variablen werden als variable, Arrays als serialisierte Strings gespeichert. Der Name des “Schlüssels” ist dabei vollkommen frei wählbar – es dürfen auch Namen im Klartext sein (was ich zumindest definitiv bevorzuge, weil ich alleine auf dem System arbeite). Und: Sie müssen definitiv eindeutig sein, ansonsten werden vorhandene Daten schlicht überschrieben. Diese “Schlüsselvergabe” per MD5-Checksum könnte eventuell sogar im schlimmsten Falle zum Problem werden, da du auch mit verschiedenen Werten die gleichen MD5-Checksums erzeugen kannst – was zwar Zufall, aber nicht auszuschliessen ist.
Arbeitet man auf einem System mit mehreren Websites und will nicht, dass die im Cache gespeicherten Daten allen frei zugänglich sind, sollte man sich irgend ein “codewort” ausdenken, dieses md5-verschlüsseln und einem Schlüssel mit Klartextnamen voranstellen.
Beispiel:
d2c11766b5677c274b07661ba261a42e_dbquery_usertable
Das kann man zwar auch bruteforcen, aber die Aussicht auf erfolg ist recht gering, weil man in der Schlüsselvergabe sehr sehr flexibel sein kann – also auch zwei komplette md5 Schlüssel – oder in Teilen – verwenden kann…
Ich könnt noch mehr drüber schreiben, aber ich lasses mal.
Mein Fazit zu Memcache ist jedenfalls:
Speichere nur die Daten zwischen, die sehr oft gebraucht werden. Speichere sie schlau und Systemschonend und bestenfalls so, dass sie direkt an den User ohne weitere Berechnungen durch PHP weitergegeben werden können (beispielsweise BB-Codeparser VOR dem Speichern im Cache durchführen!) Erst dann ist Memcache sinnvoll nutzbar.
Kommentar schreiben