2 Sachen fallen mir dazu ein...

[kayozz]

1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das würde die Länge des Keys ziemlich reduzieren.

2. Ist die direkte Integration von Memcached eine recht nette Idee. Dadurch erspart sich der Entwickler den Aufwand in der Anwendungslogik:
a) Versuch das Ergebnis über Memcached abzurufen
b) Kein Ergebnis? Dann über die Datenbank abrufen
c) Wenn das Ergebnis nicht von Memcached kam, dann jetzt in Memcached speichern
d) Nach einem Update/Insert den Eintrag aus dem Cache leeren
Ausserdem beschleunigt sich so das Speichern der Datensätze in Memcached, da das direkt auf dem Server passiert.

Aber: Ich sehe ein großes Problem beim aktuell halten des Caches:
Nehmen wir mal an, ich habe einen Cache auf der Tabelle User. Jetzt wird ein User geändert und ich möchte den Cache löschen. Wie mache ich das?
Programmierer A hat ein einer Stelle im Programm "SELECT id, name FROM users" abgefragt
Programmierer B hat an einer anderen Stelle "SELECT id, name, email FROM users" abgefragt.
Da habe ich doch keine Möglichkeit den Cache gezielt zu leeren, weil ich ja nicht weiß, welche Queries alle gecached wurden.

Wenn das ganze schon natlos in die Datenbank integriert ist, dann wäre der logische Schritt, zu protokollieren, welcher Datensatz aktuell gerade in welchen Caches vorhanden ist und, bei einer Änderung, die betreffenden Caches dann zu leeren.
Allerdings müsste bei jedem INSERT oder DELETE alle Caches, die Daten aus der betreffenden Tabelle halten ebenfalls geleert, bzw. idealerweise in einem Hintergrundthread aktualisiert werden, um die neusten Änderungen ebenfalls zu berücksichtigen.

[scroogie]

In der Regel arbeitet man bei memcached mit Prefixen auf dem Key. Man würde also db_tablename_{$queryhash} als Schlüssel nehmen. Bei einem verändernden Query auf die Tabelle löscht man dann alle Einträge die mit db_tablename_ anfangen.

Der Autor hat sich allerdings für Pseudo-Befehle in Kommentaren entschieden. Man schreibt z.B. /* cache:refresh */ an den Anfang eines Queries.

Beides hat meiner Meinung nach anwendungsspezifische Vor- und Nachteile.

[ssssssssssssssssssss]

macht das nich oracle so?
also queries cachen und als key den hash verwenden?
scheint ganz gut zu funktionieren vor allem mit prepared statemens :)

[Dumpfbacke]

kayozz schrieb:
--------------------------------------------------------------------------------
> 1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das
> würde die Länge des Keys ziemlich reduzieren.
Ist wohl eher die Frage, wieviel Rechenleistung es kostet für jeden Querie einen Hash zu berechnen.

> 2. Ist die direkte Integration von Memcached eine recht nette Idee. Dadurch
> erspart sich der Entwickler den Aufwand in der Anwendungslogik:
Für den Entwickler sollte sich gar nichts ändern.
Wenn der Cache gut gemacht wurde, bekommt der Entwickler vom Cache selber gar nichts mit.

> a) Versuch das Ergebnis über Memcached abzurufen
> b) Kein Ergebnis? Dann über die Datenbank abrufen
> c) Wenn das Ergebnis nicht von Memcached kam, dann jetzt in Memcached
> speichern
> d) Nach einem Update/Insert den Eintrag aus dem Cache leeren
> Ausserdem beschleunigt sich so das Speichern der Datensätze in Memcached,
> da das direkt auf dem Server passiert.
Du hast eben das Prinzip eines Caches beschrieben. Diese Technik wurde bereits in DOS benutzt (Smartdrive) und wird in jeder CPU in Form des 1. und 2. Level Caches genutzt ;).

mfg

[VirtualInsanity]

kayozz schrieb:
--------------------------------------------------------------------------------
> 1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das
> würde die Länge des Keys ziemlich reduzieren.
>

Wäre das nicht theoretisch ein Risiko?
Stimmt der Hashwert zweier verschiedener Queries zufällig überein (auch wenns noch so unwahrscheinlich ist), dann müsste es doch zu unvorhersehbaren Fehlern kommen oder?

[Dumpfbacke]

VirtualInsanity schrieb:
--------------------------------------------------------------------------------
> kayozz schrieb:
> ---------------------------------------------------------------------------
> -----
> > 1. Warum der Query als Key und nicht z.B. der MD5 Wert des Queries? Das
> > würde die Länge des Keys ziemlich reduzieren.
> >
>
> Wäre das nicht theoretisch ein Risiko?
> Stimmt der Hashwert zweier verschiedener Queries zufällig überein (auch
> wenns noch so unwahrscheinlich ist), dann müsste es doch zu
> unvorhersehbaren Fehlern kommen oder?
Theoretisch ja, allerdings kannst du da auch gleich überlegen, wie oft ein Bit umfällt und das Probleme verursachen könnte ;).

Das Ergebnis wäre in beiden Fällen nicht mehr richtig.

[VirtualInsanity]

Dumpfbacke schrieb:
--------------------------------------------------------------------------------
> Das Ergebnis wäre in beiden Fällen nicht mehr richtig.

So oft wie Fehler in meinem Code auftreten... da muss das mit den Bits schon sehr oft passieren. :-D

[kayozz]

Rein theoretisch sind Collisions in MD5 möglich.
D.H zu einem MD5 Hash für den String "SELECT * FROM employees" lässt sich, mit gewissen Aufwand ein weiterer String berechnen, der den selben Hash generiert. Allerdings würde dieser String dann wohl eher aus Datenmüll bestehen.

Ich lehne mich mal aus dem Fenster, und behaupte es gibt keine 2 gültigen SQL-Statements, die den selben MD5 Hash besitzen und bleibe bei der Behauptung, bis mir jemand das Gegenteil beweist. Punkt.
Man muss ja bedenken, dass man einen Befehl findet, der
a) vom Parser als fehlerfreies SQL erkannt wird
b) Tabellen/Spalten referenziert, die es auch wirklich in der Datenbank gibt

[nil]

Das ist falsch. Es gibt logischerweise unendlich viele gültige SQL-Statements, und selbst wenn man eine Größenbeschränkung definiert (sinnvoll) trotzdem noch deutlich mehr als 2^128. Daher gibt es selbstverständlich Kollisionen.

Beispiel:
select *
from table
where columna = a
and columnb = b
and columnc = c
and columnd = d;

a,b,c,d 32 bit, d.h. es gibt bereits von dieser abfrage 2^128 mögliche Ausprägungen. Und etwa 4 Mrd. mal mehr wenn man nur eine Spalte dazu nimmt.

Daher ist es völlig logisch dass es Kollisionen geben MUSS, die sinnvolles SQL darstellen.

q.e.d.

[murdog]

So ein hashzugriff gestaltet man normalerweise so:

Die Statements werden mit ihrem Hashwert (MD5 oder ähnliches) und Query gespeichert. Dabei gibt es natürlich Kollisionen.
Beim wieder rausfinden greift man dann zuerst mit HashWert zu und bekommt eine Liste von Treffern die dem Hash entsprechen. Diese Liste geht man nun durch und macht ein exakten Vergleich auf das Query.
Das reduziert zwar nicht die größe der Keys, reduziert aber ganz erheblich die Zugriffszeit da nicht alle Queries exakt verglichen werden müssen, sondern über den Hash eine schnelle Vorauswahl möglich ist.