Cachen mit Sqlite als Zusatzdatenbank

In dynamischen PHP Applikationen wird cachen immer sinnvoller.
Das haben auch Developer von vielen Titeln begriffen.

Da geht es auch um die Unterstützung von Techniken die Pagespeed fördern wie z.B. der Einsatz von Images über einen direkten Einsatz als  Base64 - codiertes Image.

Bei dieser Technik wird statt einem Link zu einem Image der Imageinhalt base64 codiert direkt in den Inhalt eingesetzt.

Natürlich muss dazu das Image codiert werden.

Die Frage ist - macht man es einmal oder immer wieder erneut.

Jede Codierung erfordert einen Filezugriff auf das Image und die Umwandlung selbst.

Das kostet aber etwas Zeit - warum also legt man die codierte Version nicht einfach ab ?

Genau das machen einige und zwar als File.

Das aber erfordert natürlich dann die Prüfung ob es eine codierte Version gibt, wenn nein, gibt es denn eine nicht codierte Version, wenn ja, codieren und in den Inhalt einfügen und ablegen.

Ein  umfangreiches Web kann damit eine ziemliche Anzahl von Files erzeugen, deren Anzahl sogar derart ansteigen kann, das allein eine Prüfung ob es die Datei gibt den Vorteil vom caching aufzehren kann.
Im Extremfall kann es auch zu einem Überlauf kommen, wenn die Anzahl der Dateien das maximal mögliche pro Ordner überschreitet.

Warum speichert man die codierte Version nicht einfach in einer DB ab ?

Mysql hätte man ja - aber wäre Mysql sinnvoll ?

Nein - Mysql wird als Dienst ausgeführt und in der Regel teilen sich diverse Domains diesen Dienst.

Hat man 20 Bilder auf einer Seite hat man 20 Abfragen zusätzlich.

Damit könnte die Gesamtperformance sinken.

Aber Sqlite gehört zum normalen Standardumfang und das schöne daran ist - man kann so viele DB's anlegen wie sein Webspace verkraften kann.
Und - es ist nur ein File pro Db.

Mit einer simplen Sql:



CREATE TABLE shared_array (offset TEXT, value BLOB, datum INTEGER, strlen INTEGER, extension TEXT);
CREATE UNIQUE INDEX offsetindex ON shared_array(offset ASC);



kann man eine Tabelle anlegen und nutzen.

Sqlite hat unter dem Strich zudem den Vorteil, das es im reinen Lesebetrieb schneller als Mysql ist und schneller als wenn man einen normalen Filezugriff ausführt.

Mit einer kleinen Klasse und nur 6 Funktionen kann diese Tabellenstruktur für alles mögliche verwendet werden nicht nur für Images.
Wir setzen es z.B. auch für XML oder ganzen RSS Feeds ein, die Zeit gesteuert erneuert werden müssen und verwenden für jede Nutzungsart eine eigene Sqlite - Tabelle.

Als Key dient das Feld offset und das ist normal der komplette Pfad zu einer Originaldatei und zwar MD5 verschlüsselt.
Da Sqlite Transaktionen ausführt passiert auch rein nichts, wenn z.B. zufällig 2 Besucher eine Seite ansteuern in der ein paar Images neu zu cachen wären.

Wer sich eine solche Klasse schreiben will sollte auf keinen Fall für den DB Zugriff eine fertige komplexe Datenbanklasse einsetzen, die wäre deutlich langsamer als eine direkte Sql Ausführung über PDO innerhalb der Funktionen.

Sqlite selbst arbeitet natürlich wie alle DB Systeme mit eigenem Caching.
Bei Standardimages die häufig in den Webseiten auftauchen, kann man davon ausgehen das die meisten Zugriffe direkt aus dem RAM bedient werden - das ist natürlich dann extrem schnell.

Tatsächlich liegt die durchschnittliche Leistung trotz des höheren Aufwandes um ein mehrfaches höher als bei einer ordinären Ablage als File  und einem Zugriff darauf.