Caching von Suchergebnissen zwecks Navigation (MySQL)

[Marc Staedtler]

Hallo Forum

ich habe folgende Frage, vielleicht weiss ja jemand von Euch Bescheid
und kann mir Informationen und/ oder einen Link dazu geben.

Ich möchte eine Suchfunktion realisieren, welche in der Regel eine hohe Zahl an Treffern liefern wird. D.h. ich muss eine Navigation durch die Ergebnissliste anbieten.
Das ist ja mit LIMIT auch einfach umzusetzen.

Jetzt habe ich aber folgende Frage dazu:

Ist MySQL so smart das Resultat der ersten Query der Suchanfrage zu Cachen, so dass bei Aufruf der gleichen Anfrage (nur mit anderen LIMIT-Werten) nicht wieder erneut die DB befragt wird?

Oder kann man das steuern ?

Oder lohnt sich der Einsatz einer temporären Tabelle um z.B. die Keys aus dem ersten Result zu speichern, also das Caching selbst zu bauen?

Oder gibt es andere Lösungsansätze ?

Ach ja das ganze soll mit PHP/ MySQL realisiert werden.

Schönen Tag Euch

Marc

[Philipp Hasenfratz]

Halihallo Marc

Ich möchte eine Suchfunktion realisieren, welche in der Regel eine hohe Zahl an Treffern liefern wird. D.h. ich muss eine Navigation durch die Ergebnissliste anbieten.

Der Recall ist ggf. zu gross.

Ist MySQL so smart das Resultat der ersten Query der Suchanfrage zu Cachen, so dass bei Aufruf der gleichen Anfrage (nur mit anderen LIMIT-Werten) nicht wieder erneut die DB befragt wird?

Nein, denn das würde gegen das Grundprinzip aller Datenbanken verstossen. Jede Abfrage
stellt eine momentane, vollständige Abbildung des Datenbestandes dar, die Vollständigkeit
wäre mit Caching nicht mehr gegeben. Ggf. wurden bereits Datensätze gelöst und diese
_dürfen_ nicht ausgegeben werden (Integrität). Ein derartiges Caching wie du es vor-
schlägst würde ich als Bug bezeichnen (obwohl es in deinem Fall sinnvoll wäre).

Oder kann man das steuern ?

IMHO nicht direkt.

Oder lohnt sich der Einsatz einer temporären Tabelle um z.B. die Keys aus dem ersten Result zu speichern, also das Caching selbst zu bauen?

Frage: Was willst du damit bezwecken? - Weniger intensive condition-searches (also
Selektion der "passenden" Datensätze), weniger Ressourcen, schnellere Abfragen, weniger
Speicherverbrauch... ?
bei dem einen oder anderen Fall macht eine temporäre Tabelle Sinn, aber ich denke das
dies stark davon abhängt, inwiefern du optimieren willst.

Oder gibt es andere Lösungsansätze ?

Die Datenbank wird einmal abgefragt und das Ergebnis in einer HEAP-Tabelle [1]
gespeichert. Den gesamten Datenbestand oder nur die Primary Keys in einer temporären
Datei speichern.

[1] http://www.mysql.com/doc/en/HEAP.html, die haben den Vorteil, dass sie auch
    zwischen Verbindungen existent bleiben, im Gegensatz zu temporären Tabellen.

Viele Grüsse

Philipp

[Odium]

Hallo,

du könntest ja auch die Ergebnisse in eine html-Datei schreiben.
Beim Aufruf der Suchergebnisseite könnte man testen ob eventuell eine aktualisierung in der Datenbasis stattgefunden hat.
Dazu müßte man natürlich die Scripte die für inserts verantwortlich sind entsprechende informationen schreiben lassen.

Anhand dieser Informationen könnte man entscheiden ob eine Suche in der DB durchgeführt werden muss oder ob ein include einer Datei genügt.

Odium

[Philipp Hasenfratz]

Halihallo Odium

du könntest ja auch die Ergebnisse in eine html-Datei schreiben.

Theoretisch möglich, praktisch würde ich das nicht empfehlen, da Marc sagte, dass es sich
um grosse Mengen an Suchresultaten handelt. Selbst bei kleinen Datenmengen müssten die
diese langsam über das Internet übertragen werden => Geschwindigkeit.

Beim Aufruf der Suchergebnisseite könnte man testen ob eventuell eine aktualisierung in der Datenbasis stattgefunden hat.

Wenn es um die Interität sehr richtig. Wenn es um die Performance geht ist das ggf.
unnötiger Overhead, denn dazu ist nochmals mindestens eine Datenbankabfrage nötig.

Dazu müßte man natürlich die Scripte die für inserts verantwortlich sind entsprechende informationen schreiben lassen.

Stichwort: erste Timestamp für MySQL-Systeme (letzte Änderung wird festgehalten). Marc
müsste mal entscheiden, ob das wirklich derart relevant ist (aber ja, ich habe ja damit
angefangen, ich weiss).

Viele Grüsse

Philipp

[Michael Schröpl]

Hi Marc,

Ist MySQL so smart das Resultat der ersten Query der Suchanfrage zu Cachen, so dass bei Aufruf der gleichen Anfrage (nur mit anderen LIMIT-Werten) nicht wieder erneut die DB befragt wird?

woher soll mySQL wissen, daß sich der Inhalt der Tabelle zwischenzeitlich nicht geändert hat?

Oder lohnt sich der Einsatz einer temporären Tabelle um z.B. die Keys aus dem ersten Result zu speichern, also das Caching selbst zu bauen?

Ich denke, nein.

Wenn Deine Tabelle gut geindext ist, dann besteht der wesentliche Teil des Aufwandes darin, auf diesen Indexbaum zuzugreifen.
Die Daten dieses Zugriffsbaums brauchst Du bei zwei "verwandten" Suchanfragen wiederum nicht vollständig, sondern jeweils nur den Abstiegspfad innerhalb dieses Baums, also eine logarithmisch kleine Teilmenge.
Diese kann das RDBMS sicherlich bequem cachen - überprüfe ggf. in der mySQL-Konfiguration, wie dort entsprechende Puffergrößen für Indexzugriffe eingestellt sind (ich rate mal, daß diese Parameter tabellentypbezogen ausfallen könnten, also spezifisch für myISAM etc.).

Oder gibt es andere Lösungsansätze ?

Bei solchen Fragen ist mein Vertrauen in die Umsetzung LRU-ähnlicher Algorithmen durch die Kombination aus RDBMS und Betriebssystem hoch genug, um mir hier keine eigenen Gedanken machen zu wollen. Diese stecke ich lieber in meine CREATE INDEX-Statements ...

Viele Grüße
      Michael

[Marc Staedtler]

Hallo nochmal

erstmal vielen Dank für Eure Antworten.
Werde mich wohl mal etwas mit dem INDEX bei MySQL beschäftigen müssen.
Habe ich noch nie benutzt, wird also Zeit.
Wenn jemand von Euch noch ein gutes (beispielgespicktes) Online-Tutorial dazu kennt würde ich mich über einen Link freuen
(eine Buchempfehlung wäre auch nicht schlecht).
Ansonsten werden ich mich jetzt mal ein wenig durch die MySQL-Doku wühlen und hoffen, dass ich es kapiere (wenn nicht melde ich mich natürlich wieder an dieser Stelle :).

Gute Nacht

Marc