Redis Cache

Was macht das Ding eigentlich?
Das ist doch eine Datenbank, oder?

Naja, so trival ist Redis nicht und man sollte es in Verbindung mit Mencached erwähnen. Erwähnen, nicht beides nutzen, denn beides ist mehr oder weniger das Gleiche. Die Vorteile des einen sind im Grunde die Nachteile des anderen. Kommt bei beiden sehr darauf an, was die eigene Software braucht und was man selbst haben / nutzen will.

Pauschal sagen "nutze es nicht" kann man da nicht, da wohl 99,9% aller User es nutzen im Sinne von, "deren CMS nutzt es" und dann haben die damit ja nichts zu tun, sondern die CMS-Entwickler. Die Frage wäre dann nur, was genau nutzt das CMS an oder mit Redis / Memcached.

Joomla z.B., die nutzen Redis oder auch andere nur als eben "RAM-Cache", als Ersatz für ihren File-Cache, den sie sonst als normalen Cache haben. Hier nutzen sie quasi nur die Vorteile des schnelleren RAM gegenüber der SSD oder HDD. Joomla nutzt aber nicht die Fähigkeiten, die Redis wirklich hätte. Vor allem die nicht, die Redis von Memcached unterscheiden. Warum? Weil Joomla es nicht braucht, also kein normales Joomla.

Beide Chaces sind Key-Value-Caches. Beide sind quasi gleich schnell, da bei RAM. Beide nutzen als Haupt-Typen "Stringes" und das ist auch das, was die meisten Anwendungen verwenden.

Hier ist nur ein kleiner Unterschied zwischen beiden Versionen. Bei Redis ist das maximale Limit für ein "Key-Value"-Paar 512 MB, bei Memcached sind es 1MB. Das sollte sich aber produktiv nicht allzugroß auswirken, denn die wenigsten Values dürften größer als 1MB sein.

Bestes Beispiel für die Nutzung der normale Key-Value-Objekte ist z.B. in PHP die Session. Die ist ja genau das, also eine Datei mit "Identifikations-String" (Key) und einem Inhalt (Value). Die sind dann halt nicht mehr auf der Platte, sondern im RAM.

Oder eben Filecaches. Die funktionieren ja genauso. Identifikator für den Dateinamen (meist ein Hash-Wert der URL) und eben ein Inhalt mit fertigem HTML. Beides eben in dem Fall dann als Key-Value im RAM. Genau das macht Joomla, sowohl mit File-Cache oder Component-Cache oder Modul-Cache. Die cachen da nur die fertigen Inhalte der Seite oder eben "Addons".

So, dieses "Key-Value" geht aber noch weiter. Bisher war es ja trivial nur als Cache für fertige Inhalte. Da kann man aber, wie der Name schon sagt, auch alles andere reinpumpen. Ich für meinen Fall mache das mit größeren Array-Daten, die auf jeder Seite benutzt werden. Warum also das Array ständig neu erzeugen lassen? Das ist ja auch nichts anderes als ein "Key-Value"-Paar. Also wenn nicht im Redis, dann direkt reinschreiben und nutzen. Wenn drinnen, dann nutzen. Das sind hier bei mir Daten, die ändern sich alleine nicht, nur wenn ich was ändere. Das könnte memcached aber auch.

Der Unterschied ist, dass Redis auch andere Typen kann, wie Listen, Sets, vorsortierte etc. Das kann mamcached alles nicht. Das speichert alles nur "dumm" und daher effizient ab. Braucht man also was "sortiertes", dann muss man es eben sortiert speichern, unter einem anderen Key, oder nachträglich sortieren. Redis kann das intern machen.

Ein anderer Vorteil von Redis, warum ich das z.B. für meine GEO-JSON nutze, sind dessen GEO-Fähigkeiten. Also Berechnungen von GEO-Daten, Umkreisen, Polygonen etc. Das kann eine neue Datenbank auch, auch PHP mit Umwegen. Ich meine nicht "Koordinaten" im Sinne von Float-Werten, sondern echte Geo-Punkte mit POINT(). Aber warum? Die Grunddaten (Locations) ändern sich nicht, nur die Abfragen, also ist das perfekt für Redis.

Abseits davon nutze ich Redis etwa für Matomo, wobei das auch wieder mit memcached gehen würde. Bei Matomo wird ja eigentlich jeder Request an den Tracker geschickt und der schiebt alles einzeln in die Datenbank. Das ist mit Cache anders. Da werden die Daten vom Tracker ins Redis geschrieben und nach einer definierten Anzahl per Bulk-Import in die Datenbank übernommen. Also bei z.B. 50 definierten "Elementen", ein SQL-Import für alle 50 und eben nicht, wie vorher, 50 einzelne. Im Grunde würde der Bulk-Import auch mit Files gehen. Macht Matomo ja z.B. mit Log-File-Importen. Nur Redis oder memcached ist eben nicht File, sondern RAM.

Und hier sieht man dann auch Unterschiede beider Versionen, gerade, wenn sich bei so Dingen wie Matomo die Zugriffe schlagartig ändern. Sind da 50 definiert und es kommen nur 50 am Tag rein, dann gibt es nur einmal am Tag einen Import. Doof. Man muss den Wert also senken. Kommen dann aber z.B. bei den Silvester-Seiten Tausende binnen Minuten sind 50 zu wenig und man sollte erhöhen. Also die Sache Skalierung.

Redis skaliert horizontal, memcached hingegen vertikal. Horizontal ist eigentlich besser, aber komplizierter und limitiert von Hosts. Es selbst kann mit 16 Instanzen fahren, dann muss ein neuer Node her. Es kann also über verschiedene Hosts verteilt und repliziert werden, was memcached nicht kann. Jede der 16 Datenbanken, die Redis kann, ist aber für sich alleine. Wenn da eine Anfrage an DB 4 geht, die Daten aber in DB6 liegen, dann sind die "nicht vorhanden". Bei Abfragen schon wichtig, bei Inserts wie Matomo eher weniger. Dort kann es nur sein, dass dann z.B. DB 6 schneller voll ist und in MYSQL geschrieben wird als z.B. DB 3, auch wenn die vielleicht ältere Zugriffe hat. Spielt aber keine Rolle, Matomo sortiert das schon korrekt ein, bei einer Echtzeit-Ansicht schaut es aber erst mal komisch aus, gerade wenn es wenige Zugriffe sind und nur selten in die DB geschrieben wird.

Memcached hingegen skaliert eben vertikal, also da reicht es vollkommen aus, dem mehr RAM und CPUs zu geben. Ebenfalls ein Unterschied, wie man schon an den "mehr CPUs" erkennt, memcached ist Multi-Threaded, redis nicht.

Ebenfalls Redis, auch wenn beides RAM ist: Redis ist persistent. Man kann es also per Backup speichern und später auch wieder nutzen. Memcached-Daten sind bei einem Absturz weg. Das speichert auch Sicherungen, aber eben nicht bei einem plötzlichen "Strom aus".

Ebenso, wichtiger Unterschied: Redis ist Single-Threaded und per default ein Shared-Cache, memcached nicht. Ist hier bei den GEO-Daten ein großer Vorteil, denn die Daten sind bei ferien-netzwerk und auch hund-und-herrchen gleich. Also egal wer die da in DB0 einträgt, beide und eben alle anderen können sie nutzen. Wenn man das nicht möchte, dann muss man entweder die Datenbanken wechseln, also einer DB0, der andere DB1 oder mit Präfixen arbeiten. Das wird wohl Joomla per default tun, hoffe ich.

z.B. bei Session ist das so eine Sache, aber eben auch bei allen anderen Dingen. PHP kann ja eine Session reinschreiben mit Key "8a77155e4174c14be839135615138d". Wenn nun aber das CMS selbst irgendwo einen Hash berechnet und zufällig den gleichen Wert hat, wie die Session, dann würde der auch reinschreiben oder abfragen. Datenkollision oder falsche Daten sind die Folge. Um das zu verhindern, bekommt das Zeug dann eben einen Präfix, also Sessions ihren eigenen Raum, das CMS seinen eigenen etc.

Hm... also ich habe ja bei vielen Artikelseiten eine Farbauswahl mit 85 Farben.
Die werden im Code als Liste dargestellt und durch ein Array erzeugt.
Bei einigen Artikeln habe ich aus 2-3 Auswahlfelder, die ebenso erzeugt werden.

Wenn ich diese Listen also in Redis speichern könnte, sollte die Seite doch bedeutend schneller werden?

Im Prinzip ja, aber es wird da nicht viel schneller werden. Also unter dem Gesichtspunkt, was schneller für einen ist. Das Array, bzw. dessen Code zu parsen und dann aufzubauen dauert eine gewisse Zeit, Bruchteile einer Millisekunde. Sparen kann man dann mit Redis davon vielleicht 10-20% von diesem Bruchteil.

Ich rede hier bei meinem Fall von anderen Datenmengen und vor allem tief verschachtelten mehrdimensionalen Arrays. Meine "Ländertabelle.php" hat aktuell 2714 Zeilen Code. Enthalten ist nur ein Array, mehr nicht.

Oder auch bei mir, die ganzen Unterkünfte und Abfragen zu Feiertagen bzw. Ferienterminen wie Weihnachten, Silvester etc. Die bedürfen mehrerer Joins auf die kompletten Kalender und in denen sind fast eine Mio Datensätze. Erschwerend, enthalten sind da, wie der Name sagt, Buchungen. Ich brauche bei der Abfrage aber genau das Gegenteil, also was nicht gebucht, sondern frei ist. Bei den local-Dingen ebenso. Primär ist das für die Maps per JSON oder eben als Listen für "Objekte in der Umgebung". Die Abfragen sind also immer anders, der Grunddatenbestand, so lange kein neuer Kunde dazu kommt, aber gleich. Und da merkt man dann schon einen Unterschied, ob eine Seite für die Generierung 25 Queries absetzen muss, die jeweils diese fast 1 Mio Belegungen dabei hat oder ob sie das ignorieren kann, denn die Belegungen sind einmal abgefragt im Redis.

Was ich sagen will. Für Dein Vorhaben oben mit den Farben ist das überdimensioniert. Du müsstest ja Dein CMS dafür ändern. Redis oder Memcache sind ja keine On-The-Fly-Chaches wie Opcache oder so. Die kann man installieren und aktivieren und die tun nichts. Nichts, bis das CMS oder wer auch immer sie direkt anspricht. Also im Sinne von:

$redis = new Redis();

$redis->connect('host', port);

$redis->auth('pass');

$redis->set("foo", "bar");

echo $redis->get("foo");

Oder als LIST

$redis->lpush("farblist", "f01");

$redis->lpush("farblist", "f02");

$redis->lpush("farblist", "f03");

$redis->lpush("farblist", "f04");

$redis->lpush("farblist", "f05");

Und dann z.B. nur einen Teil davon abfragen

$farblistrange = $redis->lrange("farblist", 1, 2);

Dieses "range" ist z.B. ein typisches "Order BY yx Limit x, y" in MySQL oder array_slice() in PHP. Das braucht es in Redis quasi nicht, das macht es selbst. Das könnte memcache z.b. nicht, die machen nur das erste, set/get. Da könnte man natürlich auch ein Array reinpumpen als KEY = Arrayname und VALUE = serialisiertes Array, aber das ist dann eben nur ein String, der weiter verarbeitet werden muss, erst wieder ein Array werden muss, etc. So dann nicht sortiert, ausgeschnitten werden kann. Wie auch, ist ja ein String, der weiß ja nicht, in welcher Reihenfolge da was letztendlich ist, sein müsste.

Wenn Dein CMS allerdings die Funktionalität der Nutzung von Redis hat, dann würde ich das ausprobieren. Was denn genau darin landet, obliegt den Entwicklern des CMS, wie bei Joomla. Im einfachsten Fall eben ein File-Cache-Ersatz im RAM.

LOL Mein CMS ist ein osCommerce-Shop 2.3.4 aus der Steinzeit, an dem ich 12 Jahre unsachgemäss und nach Bauchgefühl und Alloholpegel rumgefummelt habe.
Und der trotzdem einer der schnellsten osC 2.3.4 auf dem Planeten ist... jede Millisekunde zählt

Eine Frage zu Redis noch
Wenn da z.B. 3-4 Leute gleichzeitig auf ein ERP zugreifen, dann bekommt jeder User eine eigene Instanz, ne?
Mein ERP ist... öhm... auch aus der Steinzeit. Von 1998. Aber es funktioniert klaglos. Allerdings joint der halt so ziemlich ALLES von ALLEM, auch bei der simpelsten Abfrage.
Ich trau mich aber nicht an dem Ding rumzufummeln, weil dieses Uraltprogramm tatsächlich das Rückgrat meiner Unternehmen darstellt.
Kann man Redis auch lokal auf einem NAS installieren und betreiben?

NAS keine Ahnung, hatte ich noch nie.

"User" in dem Sinne habe da keine Instanz, es gibt keine "User". Der User ist ja quasi das CMS, das sich verbindet. Die CMS kann man trennen, durch die verschiedenen Datenbanken 0-15. Der Connect entscheidet dann ja, mit welcher DB davon sich das CMS verbindet.

Wenn da auf einem Server 10 Webseiten sind, die alle Redis nutzen und alle ohne extra Präfix sich mit DB0 (default) verbinden, dann gibt es Datenchaos, denn Web0 könnte dann alle Keys abfragen, auch wenn die von Web1 oder Web2 sind.

Es sei denn, es wird in verschiedene Datenbanken getrennt oder der Server fährt mit verschiedenen Redis-Instanzen, also einer eigenen Instanz für jeden vHost. Dann sind die Hosts getrennt, aber die User der Seite nicht. Ist ja so gesehen nix anderes als "lege alle Dateien in Verzeichnis /vrz0" oder eben "db0".