#54 Key Value Store Redis: Einsatzmöglichkeiten, Fallstricke, Datenstrukturen, HyperLogLog und (flüchtige) Persistenz

Redis - Der open source, in-memory data structure server

Viele Software-Engineers haben bereits von Redis gelesen. Primär im Anwendungsfall eines Caches. Doch das ist bei weitem nicht alles, was Redis unter der Haube hat. In dieser Episode schauen wir uns den Data Structure Server mal genauer an. Was ist Redis? Welche Datentypen unterstützt dieser? Was ist Geospatial und HyperLogLog? Kann Redis meine Daten auch persistieren? Welche Use-Cases gibt es neben dem Caching? Wer ist eigentlich der Kopf hinter Redis? Und wie kann ich Redis erweitern, falls ich noch mehr Funktionalität brauche? All das und noch viel mehr Hintergrundwissen zu Redis in dieser Episode.

Bonus: Wann unser Co-Host Andy und wann Andreas genannt wird und was Clippy von Word mit Redis zu tun hat.

Sprungmarken

(00:00:00) Intro

(00:00:49) Die Datenbank Redis, wie wir zu dem Thema kommen und warum andere oft Redis wollen

(00:03:32) Was ist Redis?

(00:06:51) Wie sicher sind meine Daten im In-Memory-Store Redis?

(00:08:07) Was ist Geospatial im Kontext von Redis?

(00:09:34) Was ist HyperLogLog?

(00:12:13) Was sind BitMaps und BitFields?

(00:14:19) In Redis fängt alles mit einem Key an: Key-Value

(00:17:07) Warum sollte ich Redis nehmen und nicht eine MySQL-Datenbank?

(00:19:21) Persistenz-Modelle in Redis: RDB und AOF

(00:25:49) Redis Cluster und Leader-Follower Architektur

(00:26:55) Wie Andy zu Redis kam

(00:31:36) Use-Cases von Redis: Caching, Delayed writes

(00:34:26) Ist Redis eine Datenbank?

(00:36:08) Salvatore Sanfilippo, antirez, der Autor von Redis

(00:40:09) Fallstricke von Redis: Persistenz, Key-Struktur, Verschachtelte Datenstrukturen

(00:43:16) Lua Scripting in Redis

(00:45:26) Neue Daten-Strukturen durch Redis Modules

(00:48:00) Redis Protokoll und Kommunikation mit Redis

(00:49:52) Kommerzieller Support von Redis und Firmen-Konstrukt hinter Redis mit RedisLabs

(00:55:27) Redis in der Cloud-Welt: GCP Memory Store, AWS ElastiCache, Azure Cache for Redis

(00:59:36) Andys Lieblings-Datenbank und nicht erwähnte Themen: Cluster, Streams, twemproxy, Redis Sentinel

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:05 - 00:00:43)

A, O, F, R, D, B und L, M, P, S, Q, L, D, E, L und B, G, safe. Entschuldigung, da ging es wohl mit mir durch. Das war nun nicht der Song mit freundlichen Grüßen von der Band die Fantastischen Vier, sondern alles Begriffe von meiner Lieblingsdatenbank. Sofern die Technologie als Datenbank bezeichnet werden kann. Heute geht es um den Datenschruktur-Server Redis. Aber nicht nur, was Redis ist, sondern mit einer Menge Wissen drumherum. Was ist HyperLogLog? Welche Use Cases hat Redis neben Caching? Was sind klassische Fallstricke beim Einsatz von Redis? Und wer ist eigentlich der Kopf hinter dieser Technologie? Das und noch viel mehr in der nächsten Stunde. Los geht's!

Wolfi Gassler (00:00:50 - 00:01:21)

So Andi, nachdem wir in der letzten Episode über die Zukunft gesprochen haben, in der Episode 53, blicken wir heute mal in die Vergangenheit, beziehungsweise du kannst mir jetzt beweisen, ob das wirklich die Vergangenheit ist oder ob das noch ein Thema ist, was aktuell ist, aber es ist eines deiner Lieblingsthemen und zwar geht es um Redis. Du bist ja ein alter Redis-Fanat, du hast Vorträge auf Konferenzen gehalten, du bist durch die ganze Welt gedingelt mit deinem Radies-Vortrag. Also wirst du mir heute mal beweisen müssen, ob Radies wirklich noch zukunftssicher ist oder ob das irgendwas aus der Vergangenheit ist.

Andy Grunwald (00:01:22 - 00:01:24)

Ein paar Leute aus meinem Kegel-Club.

Wolfi Gassler (00:01:24 - 00:01:32)

Ich frage mich immer, wie du das Kegeln reinbringen kannst. Das ist mir ein Rätsel, aber bitte. Ich bin gespannt, wo ihr Radies verwendet im Kegel-Club.

Andy Grunwald (00:01:32 - 00:02:41)

Also ja, mein Name ist ja Andreas. Mein Spitzname ist ja eigentlich Andi. Und dann ist es ja immer so, wie nennt man dich denn eigentlich? Und nur meine Frau und mein Vater nennen mich Andreas, wenn ich irgendeine Scheiße gebaut habe. Das war also so ein Indikator dafür. Der Rest der Welt nennt mich eigentlich Andi. Ein paar Leute aus meinem Kegel-Club nennen mich oft Anti, weil ich oft gegen etwas bin. Und man könnte schon fast sagen, viele Leute in der Technik sind Apple-Fanboys. Der Anti, könnte man sagen, ist eigentlich ein Redis-Fanboy. Und da ist jetzt die Frage, bin ich immer noch ein Redis-Fanboy? Weiß ich nicht ganz, aber warum, werde ich dir sagen. Auf jeden Fall. hatten wir uns bei der Vorbereitung zu dieser Episode darüber unterhalten, was denn wir für ein Thema besprechen. Und da hast du gesagt, ich fände das Thema Redis mal spannend. Und ich habe mich gefragt, Moment mal, ein Doktor der Informatik, der sogar beim Fachschul Datenbanken seinen Doktortitel absolviert hat, findet eine Podcast-Episode über Redis spannend. Das würde mich jetzt mal tierisch interessieren. Was findest du am Thema Redis spannend?

Wolfi Gassler (00:02:42 - 00:02:50)

Ja, du sagst ja immer, Redis kann alles und Redis ist so toll und das will ich mir jetzt mal anhören. Und da kann ja dann natürlich meine ganzen Datenbankfragen loswerden.

Andy Grunwald (00:02:50 - 00:03:08)

Ich glaube, ich habe noch nie bei einer Datenbank gesagt, Redis kann alles. Ich sage immer, jeder denkt, wir bräuchten Redis und merken dann relativ schnell, dass sie oft nicht genau wissen, wie sie ihre Daten speichern wollen oder abfragen wollen. Und dann rennt man auf den Probleme und dann bin ich wieder schuld.

Wolfi Gassler (00:03:10 - 00:03:18)

Warum sagen denn Leute, sie brauchen Redis? Was sind in deiner Meinung nach die Anwendungsfelder? Warum sollte jemand auf die Idee kommen, Redis zu verwenden?

Andy Grunwald (00:03:18 - 00:03:26)

Ich glaube, der größte Treiber ist, dass sie es oft im Internet gelesen haben. Auf Hacker News, auf Reddit. Nicht zu verwechseln mit Redis.

Wolfi Gassler (00:03:27 - 00:03:32)

Ja, aber du bist ja schlauer als die ganzen Online-Geschichten. Also warum macht es denn Sinn?

Andy Grunwald (00:03:32 - 00:03:41)

Über die Anwendungsfälle und wo es wirklich Sinn macht, würden wir gleich drauf kommen. Aber erstmal muss man, glaube ich, verstehen, was eigentlich Redis ist und wo darüber diese Episode eigentlich geht.

Wolfi Gassler (00:03:42 - 00:03:44)

Also es ist keine Datenbank. Können wir uns da schon drauf einigen?

Andy Grunwald (00:03:44 - 00:03:48)

Ah, ich glaub da gehen wir gleich nochmal ein bisschen in den Streit.

Wolfi Gassler (00:03:48 - 00:03:50)

Okay, dann schieß mal los. Was ist Redis?

Andy Grunwald (00:03:50 - 00:04:38)

Also Redis bezeichnet sich selbst als Open Source In-Memory Data Store. Ist also eine eigene Applikation, die hostet man, betreibt man und da kann man Daten gegenschmeißen und die werden gespeichert. Wenn man im ganzen Spektrum SQL- und NoSQL-Datenbanken unterwegs ist, beziehungsweise die Buzzwords mal gehört hat, würde man sagen, Redis wird in das Spektrum der NoSQL-Datenbanken zählen. Und es ist primär memory-bound. Das bedeutet, Redis selbst konsumiert am meisten die Ressource RAM gegenüber anderen Datenbanken, die sehr viel CPU und Disk oder Network oder sowas konsumieren. Falls man also irgendwie nach Bottlenecks suchen würde, würde man gegebenenfalls oft erstmal auf den RAM gucken, weil Redis würde ich als primär memory-bound bezeichnen. Weil es aber auch ein In-Memory-Datastore ist.

Wolfi Gassler (00:04:38 - 00:04:50)

Also ich glaube, die wenigsten Datenbanken sind network-bound und haben irgendwie Probleme mit dem Netzwerktraffic. Aber okay, zur Abgrenzung mal, es ist auf jeden Fall memory-bound, weil alles eben speichert, demnach gespeichert wird. Sehe ich das richtig?

Andy Grunwald (00:04:50 - 00:05:10)

Da siehst du richtig, dass die wenigsten Datenbanken network-bound sind. Da kann man jetzt auch drüber diskutieren, ist Kafka eine Datenbank? Und wenn du mal sehr große Kafka-Cluster-Reshuffeln gesehen hast, dann merkst du relativ schnell, dass auch die network-bound sein können. Oder so ein Hadoop-Cluster oder ähnliches. Also wenn es um ein paar mehr Daten geht, dann ist sowas relativ schnell network-bound, das sag ich dir.

Wolfi Gassler (00:05:11 - 00:05:12)

Okay, bind given.

Andy Grunwald (00:05:12 - 00:06:38)

Aber was das super interessante ist, und da bin ich ja wieder ein Fanboy von, Redis bezeichnet sich selbst ja noch nichtmals als Datenbank, sondern als Data Structure Server. Und warum ist das geil? Die meisten NoSQL-Datenbanken supporten irgendwie Dokumente und da kannst du da Strings drin speichern oder wie Memcache nur Key Values, wo Value dann auch entweder nur Raw Bits sind oder so. Redis hat aber Support für native Datentypen. Das bedeutet, du kannst dort Strings, also ganz normale Zeichenketten, speichern, Listen, Hashmaps, Sets oder Sorted Sets. Für die Leute, die nicht ganz versiert in den ganzen Datentypen sind, mal eine sehr high-level Beschreibung. Sets sind eigentlich Listen mit unique values. Also jeder Wert in deinem Set kommt nur einmal vor, wohingegen du denselben Wert mehrfach in eine Liste schreiben möchtest. Sorted Sets ist das gleiche wie ein Set, eine Unique Value, nur mit einem sogenannten Score, also eigentlich einer Zahl versehen und dann kannst du das sortieren. Jetzt könnte man sagen, ja im Moment ein Data Structure Server mit Strings, Listen, Hashmaps und Sets und Sorted Sets ist ein bisschen schwach, oder? Ist richtig. Und jetzt kommt ja die Königsklasse, weswegen Redis auch sehr oft gefeiert wird. Das ganze Ding hat nämlich noch Support für speziellere Datenstrukturen, wie zum Beispiel Geospatial, Bitmaps oder das, was den meisten Leuten nicht sagen wird, HyperLogLog.

Wolfi Gassler (00:06:38 - 00:06:57)

Okay, bevor wir in die speziellen Datenstrukturen einsteigen. Also, wenn ich das zusammenfassen kann, ich kann da drinnen einfach mal Zeug abspeichern. Strings, Listen, Hashmaps, Sets oder auch komplexere Datentypen. Das heißt, ich brauche in meiner Applikation keine MySQL-Datenbank, sondern kann das Zeug einfach direkt da drin abspeichern und dann bin ich safe.

Andy Grunwald (00:06:57 - 00:07:02)

Du kannst es einfach dann abspeichern. Safe und Datenbanken ist ja immer so eine Frage.

Wolfi Gassler (00:07:02 - 00:07:03)

Ja, die Datenbanken sind safe.

Andy Grunwald (00:07:03 - 00:07:16)

Die Daten werden erstmal im RAM abgelegt. Das bedeutet, Wenn, ohne spezielle Konfiguration und Persistenz, kommen wir aber gleich noch zu, der Server also neu startet, sind deine Daten weg, weil sie halt im RAM abgelegt wurden.

Wolfi Gassler (00:07:17 - 00:07:18)

Also es ist ein besserer Cache.

Andy Grunwald (00:07:18 - 00:07:49)

Der Aufgang macht es mir heute aber auch wieder schwierig. Von Haus aus... Der meiste Use Case für Redis ist ein In-Memory-Cache. Meines Erachtens nach nutzt man dadurch aber nicht das Potenzial von Redis. Also Redis kann auch Daten auf Festplatte persistieren. Das bedeutet, du kannst es auch so konfigurieren, dass deine Daten safe sind. Von Haus aus, ohne speziellere Anpassungen, sind deine Daten in einer relationalen Datenbank, die genau dafür ausgelegt ist, sicherer.

Wolfi Gassler (00:07:50 - 00:07:57)

Das heißt, für einen Shop oder wenn ich eine Bank zum Beispiel implementieren will mit Konten, dann verwende ich keinen Redis?

Andy Grunwald (00:07:57 - 00:08:06)

Doch, kannst du. Du musst halt nur Persistenz anschalten und da vielleicht eine spezielle Art von Persistenz. Kommen wir aber gleich zu zwischen den zwei Arten von Persistenz bei Redis.

Wolfi Gassler (00:08:06 - 00:08:13)

Okay, bin gespannt. Dann hast du erwähnt Geospatial, Hyper-Log-Log. Was ist jetzt dieses Zeug?

Andy Grunwald (00:08:13 - 00:08:58)

Geospatial hat das schon im Namen. Geografische Daten und Koordinaten. Und zwar kannst du nativ in Redis Koordinaten, also Längen und Breiten gerade, Longitude und Latitude auf Englisch, speichern und natürlich auch mit denen suchen. Der Klassiker ist irgendwie so Nearby suchen, wenn du ein Radius hast oder eine Boundingbox. Gib mir alle Locations in einem 5km-Radius von der Location, wo ich gerade bin und dann returniert der Redis-Server dir einfach die entsprechenden Koordinaten mit der Distanz. Also sowas kannst du natürlich auch in relationalen Datenbanken machen. In der Regel kombinierst du da aber in deinem Query Cosinus und Sinus und wie die alle heißen, die Funktionen, um dann halt deine Radius-Query zu machen. Und sowas kann halt Redis von Haus aus.

Wolfi Gassler (00:08:58 - 00:09:06)

Also man muss erst die Datenbanken in Schutz nehmen, die haben mittlerweile schon auch Funktionen dafür. Gerade Postgres war da schon immer historisch sehr, sehr stark in dem Bereich.

Andy Grunwald (00:09:06 - 00:09:07)

MySQL aber nicht, oder?

Wolfi Gassler (00:09:07 - 00:09:14)

MySQL ist ein bisschen schwieriger, hat aber auch Funktionen dafür, aber ist jetzt sicher nicht so leistungsstark wie Postgres.

Andy Grunwald (00:09:14 - 00:09:18)

Gerade nachgeguckt, MySQL 8 hat einen Spatial Data Type.

Wolfi Gassler (00:09:18 - 00:09:20)

Und auch einen Index dafür.

Andy Grunwald (00:09:20 - 00:09:21)

Wieder was gelernt.

Wolfi Gassler (00:09:21 - 00:09:37)

Die Frage ist dann immer, wie gut das auch supported wird, wie du eben sagst, so Queries, wo man dann automatisch den Radius und so weiter mit einbauen kann. Das ist in Postgres sicher am besten supported, aber das kann man demnach dann auch in Redis machen. Und was ist jetzt dieses HyperLogLog?

Andy Grunwald (00:09:37 - 00:10:45)

HyperLogLog ist eine Datenstruktur zur Schätzung der Anzahl von Elementen innerhalb einer Menge. Jetzt würde man sagen, hä? Okay, wenn ich eine Liste habe und ich habe da fünf Elemente, wieso gibt er mir nicht einfach fünf zurück? Bei fünf Elementen ist das relativ einfach, da nimmt man dann vielleicht einfach eine Liste. Aber was ist denn, wenn man eine sehr, sehr, sehr große Liste hat? Und mit sehr, sehr groß meine ich wirklich ein paar Milliarden oder sogar Trilliarden Elemente innerhalb einer Liste. Dann ist es nämlich algorithmisch gar nicht mehr so einfach zu sagen, wie viele Elemente sind denn in der Liste, ohne durch diese ganz lange Liste durchzugehen. Und wer unsere Episode zur Landau- oder zur Big-O-Nutation gehört hat, der weiß dann, umso länger die Liste wird, umso länger dauert die Ermittlung der Anzahl der Elemente in der Liste. Hyper-Log-Log ist nun also ein Algorithmus, der dir nicht die genaue Anzahl in dieser Menge zurückgibt, sondern es ist eine proba... Wie heißt dieses scheiß Wort?

Wolfi Gassler (00:10:45 - 00:10:50)

Probabilistisch.

Andy Grunwald (00:10:50 - 00:11:20)

Es macht halt ein Estimate, ja? Um zu sagen, wie viele Elemente sind denn in dieser Menge? Und dabei wird die Genauigkeit gegen eine effiziente Speichernutzung getauscht. Also HyperLogLog selbst nutzt maximal 12 Kilobyte, kann aber dafür, die die Anzahl von Sets zurückgeben, mit 2 hoch 64 einträgen. 2 hoch 64 ist eine Zahl mit 20 Stellen.

Wolfi Gassler (00:11:21 - 00:11:22)

Also groß.

Andy Grunwald (00:11:22 - 00:11:31)

Sehr groß. Also HyperLogLog ist wirklich nur ein Algorithmus für sehr große Datenmengen. Und da, wo es darum geht, wie viele Elemente habe ich denn jetzt hier in meinem Set.

Wolfi Gassler (00:11:32 - 00:11:38)

Also das, was in klassischen Datenbanken der Optimierer eh automatisch weiß, weil er Statistiken von allem mithält.

Andy Grunwald (00:11:38 - 00:11:46)

Richtig, aber auch die Ermittlung dieser Statistiken wird halt dann bei jedem Query, bei jedem Insert und Co. mitberechnet, was dann wieder auf die Performance geht.

Wolfi Gassler (00:11:46 - 00:11:49)

Und was ist dann ein Anwendungsfall für sowas? Wann brauche ich sowas?

Andy Grunwald (00:11:49 - 00:12:14)

Ein Anwendungsfall wäre zum Beispiel, dass du die eindeutigen Suchbegriffe auf einer High-Traffic-Website tracken möchtest. Stell dir vor Google und Google möchte einfach wissen, Wie viele Unique-Suchbegriffe wurden in der letzten Stunde gemacht? Und dabei würden sie einfach jeden Suchbegriff in die HyperLogLog-Datenstruktur in Redis inserten. Und dann könnten die einfach sagen, HyperLogLog, gib mir mal die Anzahl der Elemente. Dann hätten sie diese Antwort.

Wolfi Gassler (00:12:14 - 00:12:19)

Du hast am Anfang auch Bitmaps erwähnt. Kannst du noch kurz erklären, was Bitmaps sind?

Andy Grunwald (00:12:19 - 00:12:21)

Hast du schon mal File-Permissions auf einem Linux-System gesetzt?

Wolfi Gassler (00:12:22 - 00:12:24)

In den letzten zehn Minuten wahrscheinlich nicht.

Andy Grunwald (00:12:24 - 00:12:31)

Aber sehr wahrscheinlich schon mal ein paar in den letzten Wochen, oder? Also dieses ChangeMod 0777 und dann auf irgendeine Datei.

Wolfi Gassler (00:12:31 - 00:12:31)

Natürlich.

Andy Grunwald (00:12:32 - 00:13:03)

Wenn du mal irgendwelche Permission Error hattest, dann setzt du eh immer alles auf 777. Alle Systemadministratoren und Security-Menschen, bitte einmal weghören. Dieses 0777 kann als Bitvektor repräsentiert werden. Und das kannst du zum Beispiel genau in einer Bitmap speichern, wo jedes einzelne Bit eine spezielle Permission darstellt. Natürlich kannst du sowas natürlich auch durch einen ganz klassischen String oder so darstellen, aber es ist natürlich deutlich effizienter, wenn du eine spezielle Datenstruktur dafür hast, die genau auf sowas ausgelegt ist.

Wolfi Gassler (00:13:03 - 00:13:18)

Aber wie läuft das jetzt? Habe ich dann da einen Bitmap-Vektor pro Eintrag oder speichere ich da ein großes Bitmap ab, was dann jedes Bit ein File darstellt oder sowas zum Beispiel oder einen Eintrag darstellt?

Andy Grunwald (00:13:18 - 00:13:23)

Ja, das kommt ja ganz drauf an, wie du deine Datenstruktur selbst maintainst und wie groß dein Bitvektor ist.

Wolfi Gassler (00:13:23 - 00:13:41)

Also wenn wir da mal dieses klassische Beispiel nehmen, wobei man gerade überlegt, eigentlich dieses Geschlechtsbeispiel mit männlich-weiblich, das wir auf der Uni auf- und abgebetet haben, immer als Beispiel für Bitmaps und andere Indexstrukturen, ist eigentlich auch ziemlich veraltet. Gibt es eigentlich ein gutes Beispiel, was 0 und 1 hat?

Andy Grunwald (00:13:41 - 00:14:19)

In der Redis-Dokumentation gibt es ein Beispiel genau dafür, weil es gibt nämlich auch noch eine spezielle Datenstruktur, die nennt sich Bitfields, und die sind genau für 0 und 1 Elemente ausgelegt und deren Beispiel ist, du möchtest wissen, welcher IoT-Sensor in der letzten Stunde gesendet hat. Und da erstellen die dir ein Bit-Field für jede Stunde und dann kannst du sagen, okay, Sensor 500 hat in der letzten Stunde gesendet und somit setzen die das Bit auf 1. Also wenn du wirklich nur 0 und 1 tracken möchtest, dann kannst du allein ein Bit-Field nehmen und wenn du halt wirklich einen richtigen Bit-Vektor brauchst, dann würdest du halt eine Bitmap nehmen.

Wolfi Gassler (00:14:20 - 00:14:31)

Aber wie ist jetzt der Anwendungsfall? Speichert er einen großen Vektor ab oder ich habe immer ein Key, ich rufe ja alles anhand eines Primary Keys ab, oder? Es ist alles in Redis anhand von dem Primary Key gespeichert.

Andy Grunwald (00:14:31 - 00:14:53)

Ja, bei einer Bitmap hast du den Key und dann hast du noch ein Offset und dann eine Value und der Offset kann bis zu 2 hoch 32 sein und das repräsentiert Bitmaps in der Größe von 512 MB. Das bedeutet, dein Bitmap-Vector kann eine ganze Menge sein. Und wenn du von mir aus deine File-Permissions so viel machen möchtest, kannst du es halt auch machen.

Wolfi Gassler (00:14:53 - 00:15:00)

Aber das wird dann zu einem Key gespeichert. Ich habe einen Key und dann habe ich 512 MB einen Bitvector dazu.

Andy Grunwald (00:15:00 - 00:15:08)

Ganz genau. In Redis fängt erstmal generell alles mit einem Key an. Und diesen Key musst du auch kennen oder dir halt irgendwie zusammensetzen.

Wolfi Gassler (00:15:08 - 00:15:22)

Also es ist eine Key-Value-Datenstruktur und der Value kann dann aber verschiedene Formate annehmen. Das kann dann eben geospatial sein oder eine Bitmap oder ein String oder auch eine Map dann intern nochmal.

Andy Grunwald (00:15:22 - 00:15:30)

Ganz genau. Es ist eine klassische Key-Value-Datenstruktur wie Memcached zum Beispiel, wo halt aber Value dann ein spezieller Datentyp sein kann.

Wolfi Gassler (00:15:31 - 00:15:40)

Also wenn ich dann zum Beispiel Maps verwende als Format, dann habe ich eigentlich eine Map von einer Map, oder? Weil ich einen Key Lookup habe und als Value habe ich dann eigentlich nochmal eine Map.

Andy Grunwald (00:15:40 - 00:15:52)

Das ist richtig, wenn du die erste Dimension, weil die erste Dimension ist ja dann der Redis-Server. Also der Redis-Server selbst, wenn du so ein bisschen so möchtest, ist eine sehr, sehr große Generic Map.

Wolfi Gassler (00:15:52 - 00:16:00)

Ja, also ich habe zwei Lookups dann. Ich habe einmal den ersten Primary Key Lookup und dann kann ich nochmal einen Lookup in der Map haben im Value.

Andy Grunwald (00:16:00 - 00:16:31)

Ja, richtig, obwohl du natürlich den ersten Lookup, der ist ja transparent für dich, weil das ist ja dann die Funktionalität des Redis-Servers, wie du das abfragst. Du kannst ja zum Beispiel sagen, du hast einen speziellen Befehl, um das fünfte Element in einer Liste zu kriegen, zum Beispiel. Und wenn du das machst, dann sagst du dem Redis-Server ja bereits, dass deine Datenstruktur, auf die du zugreifen möchtest, eine Liste ist. Und somit gibst du dem ja den Key mit. Somit ist der erste Lookup in deiner Generic Map dem Redis-Server ja transparent für dich und davon kriegst du ja eigentlich gar nichts mit.

Wolfi Gassler (00:16:31 - 00:16:40)

Also ihr fragt dann zum Beispiel ab, gib mir den fünften Freund von Andi und Andi ist der Primary Key und dann bekomme ich das fünfte Element, den fünften Freund.

Andy Grunwald (00:16:40 - 00:16:45)

Ganz genau. Und das ist dann eine Zeichenkette, weil innerhalb einer Liste man Zeichenkennt speichern kann.

Wolfi Gassler (00:16:45 - 00:17:00)

Das heißt aber, wenn man es jetzt wieder im Vergleich setzt zu klassischen Datenbanken, ich habe keinen Sekundärindex, den ich hinzufügen kann. Ich kann nicht mehrere Indizes hinzufügen. Ich habe immer einen Lookup anhand des Primary Keys, also anhand meines Keys, den ich festlege.

Andy Grunwald (00:17:00 - 00:17:08)

Ganz genau. Du musst halt deinen Key, auf den du zugreifst, musst du halt kennen bzw. irgendwie stabil berechnen können.

Wolfi Gassler (00:17:08 - 00:17:15)

Warum sollt ihr denn überhaupt Redis verwenden, wenn ihr das auch in der MySQL speichern könnte? Kann das ja alles auch in der MySQL Datenbank speichern.

Andy Grunwald (00:17:15 - 00:17:54)

Prinzipiell kannst du erstmal alles tun, was du möchtest. Der große Unterschied ist halt, dass je nach Abfrage und je nach verwendetem Datentyp deine Abfragezeit bei Redis konstant ist, wohingegen bei MySQL natürlich ab und zu mal auf der Festplatte nochmal rumgesprungen werden muss, je nach Datengröße, je nach WHERE-Statement, GROUP BY und so weiter und so fort ist die Abfrage unter Umständen nicht konstant, wo du hingegen natürlich bei Redis alles primär im RAM gespeichert hast, somit der Zugriff natürlich enorm schnell ist und wie gesagt durch den HashMap-Lookup bei sehr vielen Befehlen halt eine konstante Response-Zeit von sehr sub millisecond teilweise hast.

Wolfi Gassler (00:17:54 - 00:18:59)

Ich habe ja zur Vorbereitung von dieser Episode mir natürlich Performance-Statistiken rausgesucht und Blog-Einträge studiert, MySQL vs. Redis, in der Hoffnung, dass ich irgendwas finde, dass MySQL eh gleich schnell ist wie Redis. Ich bin nur leider enttäuscht worden. Alle Statistiken, die ich gefunden habe, waren ungefähr, dass MySQL doppelt so viel Zeit pro Anfrage braucht wie Redis, so im Schnitt, wenn ich so diese Graphen vergleiche. Ist natürlich ein unfairer Vergleich, muss man auch sagen, Datenbank ist für was anderes gedacht oder eine MySQL Datenbank ist für was anderes gedacht und ihr habt da natürlich Transaktionen, Sicherheit, dass das auf der Festplatte auch landet, gespeichert ist, Garantien. Aber ich muss mich leider enttäuschen, habe nichts Gegenteiliges gefunden, obwohl ich im Kopf gehabt habe, dass es mal sehr knapp war für manche Use Cases, aber habe leider nichts mehr dazu gefunden. Also wer wirklich sehr, sehr schnellen Zugriff braucht und auf die restlichen Sachen verzichten kann, was eine klassische Relationale Datenbank anbietet, das heißt Transaktionen, die ganze Sicherheit, User Verwaltung, komplexe SQL Queries, Indices, der ist natürlich mit Redis gut bedient und kann da sehr viel Speed natürlich rausholen.

Andy Grunwald (00:18:59 - 00:19:05)

Es ist natürlich ein völlig unfairer Vergleich. Du vergleichst ja ungefähr gerade ein Gewächshaus mit einem Tesla.

Wolfi Gassler (00:19:05 - 00:19:09)

Jetzt bin ich gespannt was das ist, aber vielleicht beantworte ich es lieber nicht.

Andy Grunwald (00:19:09 - 00:19:20)

Naja also MySQL Datenbank hat einen Query Parser, der hat Transaktionen, ACID, allem drum und dran. Was dann gegebenenfalls bei Redis nicht der Fall ist.

Wolfi Gassler (00:19:21 - 00:19:35)

Aber jetzt hast du schon so groß behauptet, du kannst da eh Persistenz speichern und du würdest so eine Bank implementieren. Bin ich gespannt, was für eine Bank dir den Auftrag geben würde, wenn du sagst, du implementierst das mit Redis. Aber wie schaut denn das jetzt aus mit der Persistenz?

Andy Grunwald (00:19:36 - 00:19:44)

Also generell habe ich ja gesagt, Redis speichert alles im RAM und der RAM ist natürlich mehr oder weniger als flüchtig markiert. Flüchtig bedeutet, ich speichere...

Wolfi Gassler (00:19:44 - 00:19:45)

Eher mehr als weniger, aber ja.

Andy Grunwald (00:19:46 - 00:20:42)

Ich speichere was in Redis, starte den Redis-Server neu und dann sind deine Daten einfach weg, weil, wie gesagt, der RAM ist flüchtig. Persistenz gibt es aber auf zwei Arten. Und zwar gibt es einmal das Format Redis-Database und einmal das Append-Only-File. Das Redis-Database, in Kurzform RDB, besagt, Wenn innerhalb von einem Zeitintervall eine gewisse Anzahl an Keys modifiziert wurden, dann dampfe bitte die ganze Datenbank einmal auf Disk. Das bedeutet, wenn innerhalb von 10 Minuten mehr als 40 Keys modifiziert wurden, dann nehme die ganze Datenbank und dampfe sie auf Disk. Das hat natürlich den Vorteil, dass du für 10 Minuten sauschnelle Performance kriegst, weil halt alles im Rahmen ist. Du hast aber auch den Nachteil, dass du ein 10-Minuten-Fenster hast, wo du einen potenziellen Data-Loss für die letzten 10 Minuten beziehungsweise für die Änderungen der letzten 10 Minuten hast.

Wolfi Gassler (00:20:42 - 00:20:47)

Und wie erklärst du das der Bank, deinem Auftraggeber, dass du nur 10 Minuten sicher bist?

Andy Grunwald (00:20:48 - 00:22:17)

Ich würde auch keine Bank in Redis implementieren, aber der Bank würde ich sagen, nimm doch lieber Append-Only-File. Und Append-Only-File besagt, jeder Befehl, jeder Schreibbefehl, der an Redis gesendet wird, wird erstmal in ein File appendet, also das bedeutet SetCounter1, SetCounter1, SetCounter1, dann hättest du auf den KeyCounter den Value 3 und in dem Append-Only-File hast du dreimal untereinander SetCounter1 stehen. Eine kleine Korrektur, es muss natürlich Increment Counter heißen und nicht Set Counter. Wenn du jetzt den Redis-Server neu startest und der Redis-Server sieht, ah da ist ein Append-Only-File, dann nimmt er sich das, liest das und arbeitet die Befehle von oben ab. Somit hast du eigentlich ein komplettes, ja man könnte fast sagen Transaction-Log vom Redis-Server. Jetzt ist es natürlich so, wenn du sehr sehr viele Operationen hast, dass das Append-Only-Log sehr sehr lang wird und somit der Reboot von einem Redis-Server sehr sehr lange dauern kann, weil jeder einzelne Befehl abgearbeitet wird. Du kannst auch das Append-Only-File kompakten lassen. Das ist ein Prozess, der geht über dein Append-Only-File, schaut sich die ganze Sache an und würde dann diese dreimal SetCounter1 auf SetCounter3 modifizieren, dass du somit die Befehle einfach kompaktest, dass somit der Restart von einem Redis-Server zum Beispiel schneller ist. Und jetzt kommt der Clou, du kannst natürlich auch das Redis-Database-Format mit dem Append-Only-File kombinieren.

Wolfi Gassler (00:22:17 - 00:22:31)

Wird das Ganze dann langsamer im Betrieb? Weil ich muss da ja ständig in irgendeiner Datei schreiben, die dann auf die Platte wahrscheinlich gespeichert wird. Also ich muss wahrscheinlich nicht warten drauf, weil ich kein klassisches Transaktionssystem habe, aber ich muss das natürlich irgendwie rauspushen.

Andy Grunwald (00:22:31 - 00:23:31)

Ja, langsamer ist immer so ein komisches Wort, besonders wenn wir über Performance sprechen. Ich würde mich mal aus dem Fenster lehnen und sagen, natürlich hat AppendOnlyFile ein Overhead. Aber dieser Overhead wird bei weitem nicht eine Sekunde sein. Und das bringt mich zu meiner nächsten Frage, ist das relevant für dich? Weil das kommt wirklich ganz stark auf die Detailimplementierung von Redis an. Was sie ja machen könnten ist, Redis könnte ja bei aktivierter AppendOnlyFile Persistierung beim Start zwei Threads hochfahren. Einmal den Haupt-Thread von Redis, der nimmt die Schreibbefehle entgegen und führt diese aus und der zweite Thread kümmert sich nur um die Persistierung des Schreibbefehls. Und somit hättest du mit Inter-Thread-Kommunikation dein Overhead wieder minimiert, weil du das Append-Only-File natürlich in den zweiten Thread schreiben würdest. Nachteil wäre natürlich dann in der Hinsicht, dass du wieder ein minimales Zeitfenster hättest, wo du Datenverlust hast. Aber ganz im Ernst, ich glaube dieses Zeitfenster wäre so klein, Das garantiert dir MySQL auch nicht.

Wolfi Gassler (00:23:31 - 00:24:22)

Aber man muss natürlich schon immer bedenken, dass wenn du jetzt sagst, du hast einen Hauptspeicher und du lastest den Hauptspeicher voll aus, indem du da voll draufknallst, speicherst und 100% auslastest, im Idealfall, dann müsstest du theoretisch in der gleichen Geschwindigkeit auch auf die Platte schreiben können, was natürlich nicht möglich ist. Dann wird automatisch die Platte zum Bottleneck oder dir wird der Cache volllaufen oder der Buffer volllaufen, mit dem du auf die Festplatte schreibst. Also das Szenario geht natürlich dann nur, dass du auch viele Lesezugriffe hast und weniger Schreibzugriffe, dass das im Hintergrund immer rauspipen kann, was ja aber in der Realität wahrscheinlich bei den meisten Use Cases der Fall ist, weil du willst ja viel öfters lesen als schreiben hoffentlich. Weil wenn du 100% nur schreibst, ist die Frage, ob Redis die richtige Struktur, die richtige Datenstruktur oder der richtige Speicherserver dafür ist.

Andy Grunwald (00:24:22 - 00:24:39)

Aber wenn ich dir jetzt nur mal zuhöre und keine kritischen Gegenfragen stellen würde, würde ich sagen, oh, Redis würde ich ja niemals einsetzen. Wolfgang, von wie viel Schreibzugriffen reden wir denn hier, dass die Platte nicht mehr nachkommt, ein String, irgendwas zwischen 100 Zeichen dauerhaft auf die Platte zu schreiben?

Wolfi Gassler (00:24:39 - 00:24:50)

Also die meisten Workloads sind hoffentlich read-heavy und damit hast du dieses Problem nicht. Aber wenn du jetzt davon ausgehst, dass du es voll auslasten willst, dann hast du da natürlich auch wieder ein Bottleneck.

Andy Grunwald (00:24:50 - 00:25:23)

Und wenn, angenommen, wir hätten einen Use Case, der knallt an das Schreiblimit der Festplatte. Du hast da natürlich auch noch ein paar Buffer, die du erstmal füllen musst. Es geht ja nicht immer sofort drauf, sondern der hat natürlich auch Write Caches etc. Also da hängen noch ein paar technische Layer zwischen. Das ist die erste Baustelle, die zweite Baustelle. Wenn du wirklich so ein Use Case hast, dann schadest du deine Schreibzugriffe sowieso über mehrere Redis-Nodes und dann wendest du ein Algorithmus wie Consistent Hashing an, wo du einfach deine Schreibzugriffe über mehrere Redis-Server schadest.

Wolfi Gassler (00:25:24 - 00:25:31)

Aber das wende ich ja sowieso an, egal ob ich jetzt eine klassische relationale Datenbank Redis oder sonst was verwende, wenn ich das klassische Sharding-Algorithmus.

Andy Grunwald (00:25:32 - 00:25:48)

Ja, richtig, aber durch die Verteilung der Schreibzugriffe und durch Consistent Hashing solltest du deine Schreibzugriffe recht gut balancieren können und somit sehr, sehr schnell deine einzelnen Platten entlasten. Aber das geht schon wieder hier in High-Performance-Optimierung, wo natürlich auch Redis angewendet wird, gar keine Frage.

Wolfi Gassler (00:25:49 - 00:25:55)

Hat Redis irgendwie so eine Cluster-Variante oder setzt ihr das eigentlich immer auf einem Single-Host ein?

Andy Grunwald (00:25:55 - 00:26:38)

Architekturtechnisch hat Redis ein Cluster. Ist noch gar nicht so alt. Hab ich selbst noch nicht genutzt, weil das Cluster-Konzept ein bisschen anders ist. Das würde ich jetzt für diese Episode erst mal zur Seite schieben. Da können wir mal eine eigene Episode machen, was eigentlich ein Cluster ist und warum zum Beispiel das Redis-Cluster-Konzept eher Client-heavy ist gegenüber einem Cassandra-Cluster eher Server-heavy. Aber die klassische Architektur, die man bei Redis fährt, ist eigentlich ein Leader-Follower-Prinzip. Das bedeutet, du hast einen Write Leader und hast verschiedene Follower, die die Daten replizieren. Und dann legst du deine Lesezugriffe primär auf die Follower und deine Schreibzugriffe auf den Leader. Und somit hast du dann natürlich ganz klassische Replikation.

Wolfi Gassler (00:26:38 - 00:26:43)

Muss ich für diese Replikation dann dieses Event-Only-File haben?

Andy Grunwald (00:26:43 - 00:26:43)

Nein, musst du nicht.

Wolfi Gassler (00:26:44 - 00:26:47)

Und die Replikation läuft dann asynchron oder wie läuft die ab?

Andy Grunwald (00:26:47 - 00:26:55)

Ja genau, kannst natürlich verschiedene Buffer noch konfigurieren und wie lange darf das hinterher hängen und so weiter und so fort.

Wolfi Gassler (00:26:56 - 00:27:04)

Wie bist denn du eigentlich in die ganze Redis Schiene reingetrifftet und was war dein Anwendungsfall, wo du dann Redis lieben gelernt hast?

Andy Grunwald (00:27:04 - 00:27:44)

Es ist also schon ein bisschen her, wir haben ja jetzt 2023, das bedeutet, das war, das ist knapp zehn Jahre her, in meinem, kurz nachdem ich bei Trivago angefangen habe, kam die Systemadministrator zu uns, Und die hatten sehr, sehr viel Knowledge im Bereich MySQL, aber wir hatten halt auch Redis in verschiedenen Situationen eingesetzt. Und irgendwann sagten die zu uns, hör mal, unser Monitoring-System spuckt halt in ganz komischen Intervallen immer so eine 500 aus auf der Webseite. Das bedeutet Server-Error. Und wir verstehen nicht, warum. Kann sich das mal wer ansehen. Und dann bin ich da tiefer rein, tiefer rein, tiefer rein, tiefer rein. Und im Endeffekt hat sich herausgestellt, unsere Redis-Datenbank skaliert nicht.

Wolfi Gassler (00:27:45 - 00:27:47)

Das heißt, du hast Redis gar nicht eingeführt damals?

Andy Grunwald (00:27:47 - 00:29:32)

Nee, Redis war schon da. Der Haupteinsatz von Caching-Systemen war Memcache damals und ich glaube, wir hatten ein oder zwei Redis-Instanzen. Als ich dann gegangen bin, war das Bild andersrum. Auf jeden Fall Grund, von diesen kontinuierlichen Outages auf der Webseite war eigentlich folgender. Wir hatten einen großen Redis-Server, weil der hatte so 150, 180 Gigabyte Daten in einer Redis-Instanz. Die wurden alle im Rahmen gehalten und wir hatten Persistenz aktiviert über das Redis-Database-Format. Und ich hatte gerade gesagt, wenn innerhalb von 10 Minuten 40 Keys geändert werden, dann nimmt er diese ganze Datenbank und schreibt die auf Disk. Diese 10 Minuten und diese 40 Keys kann man natürlich konfigurieren. Du kannst auch 60 Minuten und 3000 Keys draus machen, aber ist ja irrelevant. Der Punkt ist, umso mehr man schreibt in sehr kurzer Zeit, umso öfter wird die ganze Datenbank auf Platze persistiert. Und um eine Datenbank zu persistieren, brauchst du ja eine Kopie der Daten mehr oder weniger, beziehungsweise du musst wissen, ich möchte jetzt persistieren und du musst ja wissen, welche Daten sollen denn persistiert werden. Was Redis intern gemacht hat, der hat sich also diese 180 Gigabyte Datenbank genommen, hat diese Pagetable mit den ganzen Pointern und allem drum und dran kopiert, Und hat dann die auf Platte geschrieben. Und diese Page-Table-Kopiererei hat bei 180 GB irgendwas so um die 3 bis 4 Sekunden bei uns damals gedauert. Und das hat der alle 10 Minuten gemacht, weil wir ihm sehr sehr viel Daten geschrieben haben. Und in dieser Zeit hat der komplette Redis-Server geblockt, und geblockt meine ich, der hat keine neuen Client Connections angenommen, der hat keine Befehle mehr angenommen, der hat einfach geblockt, weil Redis immer noch bei sehr, sehr vielen Befehlen Singles-Reddit agiert. Das bedeutet, auf einem CPU, auf einer CPU, der arbeitet das ab und benutzt bei vielen Operationen gar nicht die kompletten Möglichkeiten von modernen Servern.

Wolfi Gassler (00:29:33 - 00:29:41)

Ja wobei du an sich immer nen snapshot fahren musst und da musst du einfach mal blocken für den snapshot ist es fast nötig.

Andy Grunwald (00:29:41 - 00:30:24)

Das ist korrekt aber das war damals der grund warum unsere website halt ab und zu mal 500 ausgesprochen hat beziehungsweise ab und zu. Nämlich nur abends zu Primetime, wenn der Traffic heavy war. Und das war so ein bisschen doof, weil ich konnte es nicht reproduzieren und ich habe es super lange nicht verstanden. Und dann bin ich halt so tief nach Redis rein und habe mich da mehr und mehr und mehr mit beschäftigt. Wir haben auch Segmentation Falls gefunden auf FreeBSD, die haben wir dann mit dem Autor noch gefixt und allem drum und dran. Da kann ich auch mal den Pull-Request nochmal in den Shownotes verlinken. Sehr interessant, wie wir das dann gedebugt haben. Auf jeden Fall ist dann irgendwie die ganze Sache entstanden und es ist primär mit einer Hassliebe entstanden, aber inzwischen habe ich mich halt so tief eingearbeitet, dass ich diese Datenbank echt lieben gelernt habe.

Wolfi Gassler (00:30:24 - 00:30:26)

Und wie hast du es damals gelöst dann?

Andy Grunwald (00:30:26 - 00:31:36)

Das war nicht eine Lösung. Auf der einen Seite habe ich mir angesehen, was für Daten schreiben wir und welche Komplexität haben diese Schreib- und Lesezugriffe. Das bedeutet Landennotation, O von N, O-Notation. Das Schöne an Redis ist, in der Redis-Dokumentation steht zu jedem Befehl die Zeitkomplexität von diesem Befehl und ich habe mir ganz genau angesehen, welche Schreibbefehle und welche Lesebefehle nehmen wir und habe die zeitlich optimiert, so dass auf der einen Seite die Ausführung von den einzelnen Befehlen schneller ist und auf der anderen Seite habe ich mir angesehen, was wird eigentlich in dieser sehr großen Redis-Instanz gespeichert und habe die einzelnen Use-Cases getrennt auf verschiedene Redis-Instanzen. Use-Cases, die wirklich Datenpersistenz brauchen, die habe ich da gelassen. Use-Cases, die klassisches Caching haben, das bedeutet, die dann wirklich einfach mal bei einem Neustart weg sein können, habe ich auf einen anderen Redis-Server verschoben, damit man einfach a, eine kleinere Datenmenge pro Redis-Server hat und somit dieser Copy von der Pagetable nicht mehr so lange braucht. Also ich habe, wenn man ganz einfach drüber spricht, die komplette Datenarchitektur von den Redis-Servern umgeschmissen und den Use Case dahin geschoben, wohin er gehört.

Wolfi Gassler (00:31:36 - 00:31:54)

Jetzt wenn wir dann zurückkommen zu meiner ganz initialen Frage, ist ja schon eine Zeit her. Was sind denn jetzt dann die idealen Use Cases dafür? Jetzt hast du einen Use Case erklärt, der nicht funktioniert hat, beziehungsweise dass du es dann alles verschoben hast. Was wären jetzt so klassische Use Cases, wo du sagst, okay, Redis wäre eine gute Lösung dafür?

Andy Grunwald (00:31:55 - 00:34:24)

Also der ganz klassische Use-Case ist erstmal Caching oder zum Beispiel das Speichern von Web-Sessions. Ich glaube, das ist so der Use-Case, der in vielen Content-Management-Systemen eingesetzt wird. Fast jedes Content-Management-System hat irgendwie ein reddes Cache-Adapter. Läuft eigentlich so, wie viele Cache-Systeme laufen. Es kommt eine Anfrage rein, der Code checkt, ist was im Cache, macht eine Abfrage an Redis. Wenn ja, retunier den Cache. Wenn nein, frag bitte in der SQL-Datenbank ab, schreib diese Daten in Redis und retunier dann. Ja, damit der nächste Zugriff zum Beispiel schneller läuft. Das ist so der Standard-Use-Case. Was man aber auch sehr schön machen kann, ist, stellt euch mal vor, ihr habt eine sehr, sehr, sehr große Datenbank-Tabelle. Und auf dieser Datenbank-Tabelle sind auch ein paar Indizes drauf. Schreibzugriffe auf diese Datenbank-Tabelle werden langsamer, umso mehr Daten da drin sind, weil bei den meisten Schreibzugriffen muss der Index neu gebildet werden. Abhängig natürlich vom Index. Was ihr also jetzt vermeiden wollt, ist, dass ihr während eines Request-Response-Behaviors in diese Datenbank-Tabelle schreibt, weil bei steigendem Traffic werden die Schreibzugriffe langsamer und somit wird die API-Response zum Beispiel langsamer. Was man jetzt zum Beispiel machen kann, ist, ihr schreibt diese Daten, die eigentlich in die Tabelle geschrieben werden, in Redis, weil die Schreibzugriffe sind da sehr schnell, habt einen Cronjob, der schaut alle paar Minuten in Redis nach, holt sich die Daten in Redis und schreibt sie dann in die Datenbanktabelle zurück, weil da ist die Schreibgeschwindigkeit ja egal, ihr seid ja im Cronjob. Und falls ihr jetzt irgendwo eine Webview habt im Admin-Panel, die diese Daten aus dieser sehr großen Datenbank-Tabelle rausnimmt und anzeigt, lest ihr einmal aus der Datenbank-Tabelle und aus dem Redis. Weil auch die Leseoperationen aus dem Redis sind ja schnell und merge diese Daten. Somit kann man natürlich so ein Delay-Write, wenn du so möchtest, so ein Delay-Datastore aufbauen, ohne irgendwie die User-Experience zu vernachlässigen. Ein anderer Use Case ist aber auch klassische Message Queues oder beziehungsweise eher PubSub, hatten wir in Episode 52 auch drüber gesprochen. Asynchrone Verarbeitung und PubSub, weil Redis supportet auch PubSubs oder sogar neuerdings auch Streams. Wer so ein bisschen an Kafka denkt, sich aber nicht das Schiff Kafka hinstellen möchte und nicht jedes Kernfeature von Kafka braucht, kann zum Beispiel auch Redis Streams nutzen. Also da gibt es verschiedene Anwendungsfälle. Welche Anwendungsfälle hast du schon so gesehen?

Wolfi Gassler (00:34:24 - 00:34:26)

Ja, für mich ist Redis sowieso nur ein Cache.

Andy Grunwald (00:34:26 - 00:34:29)

Bedeutet das für dich, Redis ist keine Datenbank?

Wolfi Gassler (00:34:29 - 00:34:32)

Ja, kommt drauf an, wie du Datenbank definierst. Wie definierst du Datenbank?

Andy Grunwald (00:34:32 - 00:34:38)

Ich habe keinen Doktor in Datenbanken. Also wie definiert der Doktor der Datenbanken denn das Wort Datenbanken?

Wolfi Gassler (00:34:38 - 00:34:46)

Ja, ich habe da eine sehr unwissenschaftliche Definition. Für mich ist es eine Datenbank. Ich speichere irgendwo was rein, kann dem vertrauen, dass es da drin liegt und kann es auch wieder rausholen.

Andy Grunwald (00:34:46 - 00:34:49)

Redis mit Append-Only-File ist dann also eine Datenbank?

Wolfi Gassler (00:34:50 - 00:34:52)

Ja, keine sichere, aber eine Datenbank, ja.

Andy Grunwald (00:34:53 - 00:35:28)

Als Meinungsverstärker habe ich mir nochmal die Definition von Wikipedia rausgeholt. Eine Datenbank ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe einer Datenbank ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen bedarfsgerechten Darstellungsformen für Benutzer- und Anwendungsprogramme bereitzustellen. Über den zweiten Teil in unterschiedlichen bedarfsgerechten Darstellungsformen bereitzustellen, Das ist diskutierbar jetzt für Redis, weil du hast ja keine Quiri-Sprache, sowas wie SQL.

Wolfi Gassler (00:35:28 - 00:35:47)

Ja, und auch der andere Teil, dauerhaft zu speichern, widerspruchsfrei, das zielt halt auf die ganzen Transaktionen ab, dass du ACID-Garantien hast. Und solche Dinge hast du natürlich mit Redis nur bedingt, beziehungsweise, wie gesagt, du kannst halt nicht hundertprozentige Garantie geben, wie so eine ACID-Property natürlich von einer relationalen Datenbank dir geben kann.

Andy Grunwald (00:35:48 - 00:35:51)

Ja, das ist aber dann jetzt kein Problem von Redis, sondern von jeder NoSQL-Datenbank.

Wolfi Gassler (00:35:52 - 00:36:01)

Es gibt auch NoSQL mit Transaktionen, aber eher wenige. Und das stimmt schon, du hast natürlich die ganzen Probleme in anderen Datenbanksystemen genauso.

Andy Grunwald (00:36:01 - 00:36:03)

Also ist Redis jetzt eine halbe Datenbank, oder?

Wolfi Gassler (00:36:03 - 00:36:05)

Ja, so Datenbankisch.

Andy Grunwald (00:36:05 - 00:36:08)

Datenbankisch, okay. Lasse ich mich drauf ein.

Wolfi Gassler (00:36:08 - 00:36:36)

Aber jetzt bist du ja als echter Fanboy nicht nur ein großer Fanboy von Redis, sondern auch ein großer Fanboy vom Core-Entwickler oder dem Erfinder von Redis. Und ihr glaubt gar nicht, ich habe von Andi schon so oft diesen Namen gehört, dass sogar ich mittlerweile diesen Typen kenne, obwohl ich noch nie mit Redis gearbeitet habe so richtig und auch noch nie von diesem Typen irgendwas im Detail mitbekommen hab sondern nur weil andi weiß dass dieser salvadore einfach der größte king ever is andi warum ich glaube die.

Andy Grunwald (00:36:36 - 00:36:41)

Apple jünger die huldigen auf steve jobs oder als größten innovator und so weiter.

Wolfi Gassler (00:36:41 - 00:36:54)

Oder ja nicht nur die apple jünger wahrscheinlich aber vor allem die und die readys jünger und jüngerinnen, Verehren Salvatore Sanfilippo, so heißt der gute Kerl.

Andy Grunwald (00:36:54 - 00:37:04)

Könnte man so sagen. Also Salvatore Sanfilippo, Spitzname Antires, ist einer der wenigen Personen, die konstant positiv auf Hacker-News wegkommen.

Wolfi Gassler (00:37:05 - 00:37:06)

Und das muss man mal schaffen.

Andy Grunwald (00:37:06 - 00:38:03)

Also, die Hacker-News-Audienz ist immer sehr, sehr kritisch und findet überall Nachteile. Aber er hat halt mal was auf den Tisch gelegt mit Redis. Und zwar ist AntiRaz der ursprüngliche Autor von Redis und hat das Projekt eigentlich ähnlich wie Guido van Rossum mit Python oder Linus Torvalds mit Linux sehr, sehr lange als ... One-Man-Show. Als BDFL ... BD was? Benevolent Dictator for Life. So heißt es ja, wenn eine Person immer noch unglaublich starke Influenz auf ein Open-Source-Projekt hat. Er hat auf jeden Fall das Projekt super lange getrieben und ist dadurch natürlich auch sehr bekannt geworden als ein sehr, sehr guter C-Programmierer. Denn viele Leute sagen, C muss man nicht mehr lernen und so weiter. Viel zu viele Fehler und C ist super unlesbar. Öffnet mal den Redis-Source-Code. Das ist für mich so ein Beweis, dass man auch lesbaren C-Code schreiben kann.

Wolfi Gassler (00:38:03 - 00:38:10)

Außerdem mein z ist super man kann sich man kann sich in keiner anderen sprache so schön selber ins knie schießen das ist wunderbar.

Andy Grunwald (00:38:10 - 00:39:00)

Das ist nicht falsch das ist richtig wie dem auch sei er wurde dafür bekannt für seine sehr sehr guten implementierungen aber auch für sehr sehr gut durchdachte designs und Gute Verschriftlichung dieser Konzepte. Das bedeutet, immer wenn er ein neues, großes Feature in Redis implementiert hat, hat er so eine Art riesen Design-Dokument dafür geschrieben. Alle Trade-Offs. Was sind die Nachteile? Was sind die Vorteile? Wie könnte man das implementieren? Warum ist die andere Implementierung nicht so gut? Und das war immer super interessant zu lesen. Also wer sich ein bisschen mit Software-Design auseinandersetzen möchte, und damit meine ich jetzt gar nicht große Software-Architekturen, sondern wie verschriftlicht man eigentlich eine Implementierung von einem Algorithmus in einem vorhandenen System, der sollte sich die Design-Papers mal von Salvatore Sanfilippo ansehen. Entweder auf seinem Blog antires.com oder teilweise sogar noch in der Redis-Dokumentation.

Wolfi Gassler (00:39:01 - 00:39:05)

Und der gute Kerl steht sowieso auf Schreiben, oder?

Andy Grunwald (00:39:05 - 00:39:36)

Der gute Kerl steht sowieso auf Schreiben. Und zwar programmiert er aktuell nicht mehr. Er hat einfach aufgehört, vor zwei Jahren Code zu schreiben und hat angefangen, einen Fiction-Roman zu schreiben. Und der erste Fiction-Roman wurde jetzt vor kurzem auch veröffentlicht, Mitte letzten Jahres. heißt wo ich weiß gar nicht ob man das richtig ausgesprochen hat auf jeden fall geht es halt um artificial intelligence um das änderung des klimas und programmierer und die interaktion zwischen menschen und technologie.

Wolfi Gassler (00:39:36 - 00:39:38)

Hast du es gelesen.

Andy Grunwald (00:39:38 - 00:39:44)

Nee es ist nicht auf englisch das buch ist in italienisch geschrieben und ich bin der italienischen sprache einfach nicht mächtig.

Wolfi Gassler (00:39:44 - 00:39:46)

Und da gibt es noch keine übersetzung ins englische.

Andy Grunwald (00:39:46 - 00:39:47)

Das weiß ich gerade gar nicht.

Wolfi Gassler (00:39:48 - 00:39:52)

Was bist du für ein Fanboy? Aber kannst du dann schön in den Shownotes nachreichen.

Andy Grunwald (00:39:52 - 00:39:54)

Mach ich, mach ich.

Wolfi Gassler (00:39:54 - 00:40:00)

Und warum hat dieser Salvatore damals Redis überhaupt erfunden? Wollte der auch ein Cash?

Andy Grunwald (00:40:00 - 00:40:10)

Da bin ich jetzt überfragt. Das weiß ich gar nicht, warum Redis einfach geschrieben wurde. Das wäre aber mal eine interessante Fragestellung. Also, liebe Hörerinnen und Hörer, falls ihr das wisst, lasst es uns mal wissen.

Wolfi Gassler (00:40:10 - 00:40:24)

So, jetzt haben wir so viele Vorteile schon besprochen. Gibt es irgendwelche Nachteile oder muss man irgendwo aufpassen, wenn man Redis verwendet? Vielleicht auch für Leute, die Redis schon verwenden. Du hast schon ein Beispiel erwähnt mit dem Snapshot, wenn man die Datenbank persistiert.

Andy Grunwald (00:40:24 - 00:40:26)

Ein paar Fallstricke gibt es auch.

Wolfi Gassler (00:40:26 - 00:40:29)

Jetzt sage ich auch schon Datenbank. Also wenn man Redis persistiert.

Andy Grunwald (00:40:29 - 00:41:23)

Ein paar Fallstricke gibt es auf jeden Fall schon. Also auf der einen Seite natürlich die richtige Persistierung, beziehungsweise sofern ihr denn Datenpersistierung braucht. Wenn ihr es nämlich nicht braucht, schaltet es bitte ab. Könnte einen guten Performance Boost geben, falls ihr es nicht braucht. Aber die richtige Einstellung von RDB, Redis Database oder Append-Only-File, macht schon eine ganze Menge aus, abhängig von euren internen Daten und Persistenzgarantien. Es ist aber auch so, dass man sich über die Art und Weise, wie man seine Daten denn wirklich speichert, schon recht viel Gedanken machen muss, denn Ihr fragt jedes Value, also eine Liste, eine set, sorted set, geospatial und so weiter und so fort, auf Basis des Keys ab. Ihr müsst also in der Lage sein, den Key konstant irgendwie zur Hand zu haben. Sei es denn ein Hash von irgendwas oder ein statischer Key, wie eingeloggte User in der letzten Stunde oder oder oder.

Wolfi Gassler (00:41:24 - 00:41:31)

Also ich kann da nicht mal schnell ne where clause schreiben, wo ich sage, where timestamp größer now minus 5 Tage oder so Sachen.

Andy Grunwald (00:41:32 - 00:41:40)

Das geht jetzt so nicht. Was du machen kannst ist, du kannst den Reddit Server fragen, gib mir mal alle Keys in deinem Server. Das Problem ist, da geht man.

Wolfi Gassler (00:41:40 - 00:41:41)

Das können viele sein.

Andy Grunwald (00:41:42 - 00:42:31)

Da geht man natürlich wieder in die Liste, hat eine Zeitkomplexität von O von N. Umso größer der Redis-Server, umso mehr Keys sich da gespeichert, desto länger braucht diese Abfrage. Und ich hatte schon Redis-Server, da hat diese Abfrage sieben Sekunden gebraucht. Ich habe vorhin gesagt, Redis ist an vielen Teilen Single-Threaded, was sehr gut und einfach zu verstehen ist, was aber bei solchen Abfragen enorm komplex sein kann und zum Nachteil, Und der Keys-Befehl wird auch eigentlich als Debugging-Befehl angesehen. Deswegen, du musst halt immer in der Lage sein, direkten Zugriff auf den Key zu haben. Und somit musst du den Key kennen. Ein weiterer Fallstrick ist, dass du keine verschachtelten Datenstrukturen haben kannst. Du kannst jetzt also nicht zum Beispiel eine Liste haben und dann als Einträge in die Liste nochmal Hashmaps. Das geht jetzt nicht.

Wolfi Gassler (00:42:32 - 00:42:35)

Also du kannst keine Verschachtelungen innerhalb von einem Value machen.

Andy Grunwald (00:42:35 - 00:43:16)

Ganz genau, du kannst halt keine Datenstrukturen mixen und zusammenschmeißen. Es gibt halt nur Top-Level-Datenstrukturen und die Values innerhalb einer Datenstruktur sind dann halt meist irgendwie Zeichenketten. Aber du kannst jetzt nicht eine Hashmap haben und dann als Value von einem Eintrag in einer Hashmap nochmal eine Liste. Das geht jetzt nicht. Also Beispiel, so klassische JavaScript-Objekte, die hast du als JSON. Das, was du da repräsentieren kannst, kannst du jetzt nicht nativ in Redis abspeichern. Was du natürlich schon kannst, ist, du kannst das JSON serialisieren und dann als String abspeichern, das geht halt schon. Aber du kannst halt nicht diese Verschachtelung in JavaScript-Objekten nativ durch Datenstruktur in Redis abbilden.

Wolfi Gassler (00:43:17 - 00:43:35)

Kann ich in Redis nur Daten speichern oder kann ich auch in irgendeiner Form Logik implementieren? Bei klassischen relationalen Datenbanken gibt es ja PLSQL oder solche Dinge oder Trigger oder kann auch Funktionen teilweise je nach Datenbank auch schreiben. Gibt es da irgendwas, wo ich Logik auslagern kann, damit ich irgendwas schneller machen kann?

Andy Grunwald (00:43:35 - 00:44:00)

Oh, Killerfrage, Killerfrage. Supported Redis Lua, Lua die Skript Sprache. Viele kennen Lua vielleicht aus den ersten Zeiten von World of Warcraft, dem Spiel. Weil da kann man nämlich auch eine ganze Menge Zeug skripten und das macht man alles mit Lua. Also wer ein bisschen so World of Warcraft Nerd war, der wird mit Lua bestimmt schon mal in Berührung gekommen sein.

Wolfi Gassler (00:44:01 - 00:44:07)

Ist ziemlich out oder? War mal eigentlich sehr gehypt und war auch nie bekannt irgendwie extrem schnell zu sein, wenn ich mich da richtig so erinnere.

Andy Grunwald (00:44:08 - 00:45:02)

Nee, das ist richtig, aber ich glaube Lua ist eine Sprache, die schon sehr sehr lange am Start ist. Du kannst ja auch zum Beispiel Nginx, den Webserver, mit Lua pimpen und dann Lua Submodules fahren und Subthreads und solche Geschichten. Also es gibt schon sehr, sehr viele Tools draußen, die eine native Lua Scripting Funktionalität drin haben. Redis hat es zum Beispiel auch und was du damit machen kannst ist, du kannst zum Beispiel eigene Commands implementieren. Falls du irgendwas brauchst, wie zum Beispiel mit einem Redis-Befehl mehrere Keys updaten oder du implementierst dir irgendwelche Lua-Funktionen, die anhand des Mondstandes irgendwelche Keys updaten oder ähnliches. Also all das, was bei Redis nicht nativ supported wird, kannst du mit Lua nachskripten. Und das Tolle ist, du kannst es zu Runtime injecten und zu Runtime auch ändern. Das bedeutet, ohne den Server irgendwie neu zu starten, kannst du da deine Funktion editieren.

Wolfi Gassler (00:45:02 - 00:45:12)

Ich bin schon gespannt, wenn du dann uns das Lua-Skript nachreichst, wo du den Mondstand abfragst. Da bin ich mal gespannt, wie du auf die Daten da zugreifst.

Andy Grunwald (00:45:12 - 00:45:18)

Wieso? Ich kann doch, wenn ich Redis abfeuere, kann ich doch in Lua ein API-Request an die Wetter-API machen?

Wolfi Gassler (00:45:18 - 00:45:29)

Klingt schon wieder sehr nach Overengineering. Wahrscheinlich kann das irgendein Datumsbefehl auch ausspucken. Aber okay, ich bin auch kein Spezialist in den Mondphasen, muss ich zugeben. Gibt's sonst irgendwie Erweiterungsmöglichkeiten?

Andy Grunwald (00:45:29 - 00:46:25)

Ich hatte grad erwähnt, dass ich ein mega Fan von Redis bin, weil das bei vielen Teilen recht einfach ist. Single-threaded, einfach zu verstehen. Vor einiger Zeit wurde eine Module-API implementiert, womit du in die vorhandenen Datenstrukturen, in die vorhandenen supporteten Datenstrukturen neue Datenstrukturen implementieren kannst. Es gibt jetzt eine Module-API, Redis Module schreiben, die werden in der Regel in C geschrieben. Kannst du natürlich dann auch mit in Go oder in Rust schreiben oder ähnliches durch diese Sprachbrücken. Auf jeden Fall bietet die Module API dir auch die Möglichkeit, neue Datentypen zu implementieren. Zum Beispiel gibt es Module, die implementieren Funktionalitäten für einen nativen JSON-Data-Type. Es gibt ein Search-Modul, das erlaubt dir Full-Text-Search. Ein Modul, was speziell für Datenstrukturen für Time-Series-Databases ausgelegt ist. Graph-Datenbanken. Gibt eigentlich alles, was Leute schon implementiert haben.

Wolfi Gassler (00:46:25 - 00:46:27)

Hast du mal schon so ein Modul verwendet?

Andy Grunwald (00:46:27 - 00:46:29)

Ich habe noch keins dieser Module verwendet, nein.

Wolfi Gassler (00:46:29 - 00:46:52)

Weil erfahrungsgemäß, also wie gesagt, auch aus der MySQL-Welt wieder, diese Module haben sich irgendwie nie durchgesetzt, waren auch nie so stabil. Von der Datenbank erwartet man sich ja auch extreme Stabilität immer. Also falls jemand schon mal mit so Modulen gearbeitet hat, würde mich wirklich interessieren, wie stabil die auch sind, wie gut die funktionieren. Weil das ist normal immer dieses Problem, wenn es um Datenbanken geht. Der Kern ist immer sehr stabil und die Module sind dann so meh.

Andy Grunwald (00:46:53 - 00:47:50)

Ich sehe es ähnlich wie du. Wer schon mal mit PHP und mit PHP-Extensions gearbeitet hat, das ist immer so ein Hack-Mac und dann hat man ab und zu mal auch Segmentation-Faults, also irgendwie invalide Memory-Zugriffe oder oder oder. Und auch wenn man die Sprache oder den Redis-Server dann mal updaten möchte, dann musst du auch immer gucken, okay, ist das Modul, was du verwendest, wirklich kompatibel mit der neuen Version? Und in der Regel hängen die halt hinten dran und dann kann man zum Beispiel nicht auf die neueste Version updaten, aber obwohl man da ein Feature braucht, Also, das ist unter anderem auch ein Grund, warum ich bisher noch kein Modul verwendet habe. Nicht, weil ich nicht denke, dass die Funktionalität super wäre, doch falls ich wirklich den Bedarf von einer Time-Series-Database habe oder von einer Time-Series-Datenstruktur, dann überlege ich mir halt, ob ich mir nicht eine Time-Series-Datenbank daneben stelle. Dasselbe für eine Graph-Datenbank. Oder muss ich wirklich ein JSON abspeichern? so brauche ich das ganze jason und brauche ich das jason in dem sub key abfragbar oder speicherst du es einfach.

Wolfi Gassler (00:47:50 - 00:47:52)

Als string genau immer geht ja.

Andy Grunwald (00:47:52 - 00:48:00)

Oder als search da gucke ich auch ob ich mir nicht eine search engine wie ein elastic search und opensource dahin stelle oder oder oder.

Wolfi Gassler (00:48:01 - 00:48:35)

Jetzt hast du PHP schon erwähnt und du hast ja am Anfang erwähnt, dass so ein klassischer Use Case eigentlich die Session-Verwaltung ist, also das Session-Caching. Und jeder, der PHP verwendet, weiß ja auch, dass die Sessions normalerweise einfach in Dateien gespeichert werden. Aber sobald man PHP verteilt, also über mehrere Nodes hinweg, braucht man irgendwo einen zentralen Session-Speicher. Und da würde sich natürlich Redis anbieten. Wird, glaube ich, auch oft verwendet, wenn ich das richtig verstanden habe. Wie kann ich denn jetzt Redis aus PHP ansprechen? Brauche ich da einen eigenen Client? Wie kompliziert ist das jetzt ganz konkret, wenn ich da jetzt einen Redis-Server hochfahre? Wie kann ich denn mit dem kommunizieren?

Andy Grunwald (00:48:36 - 00:48:54)

Das ist sogar PHP-unabhängig. Prinzipiell gibt es für jede Programmiersprache Client-APIs, so wie auch einen MySQL-Connector oder eine MySQL-Library gibt es dann auch für Redis eine Library. Da baust du ebenfalls eine Connection auf, ähnlich wie bei MySQL oder Postgre oder ähnliches. Und dann kannst du ganz normal mit Textbefehlen mit Redis kommunizieren, weil das Protokoll.

Wolfi Gassler (00:48:54 - 00:49:06)

Aber ist das im Hintergrund irgendwie eine HTTP-API, die man ganz simpel anspricht, oder ist das schon irgendein binäres Protokoll, wo man dann wirklich auch vielleicht einen C-Client oder so braucht, wie jetzt bei MySQL?

Andy Grunwald (00:49:06 - 00:49:25)

Das Protokoll selbst ist, so viel ich weiß, ein Klartext-Protokoll, was du aber auch binär übertragen kannst. Das Einfachste ist, was du machen kannst, du startest dir einen Redis-Server und connectest via Telnet drauf und dann kannst du eigentlich schon mal loslegen. Also es ist nichts Kompliziertes. Ich würde mich aus dem Fenster lehnen und würde sagen, das HTTP-Protokoll ist komplexer als das Redis-Protokoll.

Wolfi Gassler (00:49:25 - 00:49:32)

Also du kannst im Prinzip dann auch den Client komplett in PHP nativ schreiben und brauchst jetzt keine externe CE, Bibliothek oder ähnliche Sachen.

Andy Grunwald (00:49:32 - 00:49:52)

Genau, weil es ist eigentlich nur, du öffnest einen Socket und sendest ein paar Zeichenketten rüber, die wirklich nicht komplex sind. Es ist natürlich schon bevorzugt, wenn du jetzt nicht gerade Interesse hast, das Redis-Protokoll nachzuimplementieren, würde ich schon empfehlen, nutze eine dieser Redis-Libraries. Aber in der Regel sind die Libraries dann nativ in der Sprache implementiert und.

Wolfi Gassler (00:49:52 - 00:50:16)

Nicht in C. Gut, jetzt habe ich da meinen Redis-Server. Wenn ich in einer Firma arbeite, gibt es ja oft diese Anforderungen, von oben gibt es da Support, das ist ja wieder Open Source. Wie verankert ist das Ganze? Bekomme ich da irgendwo Support, wenn ich einen Problemfall habe? Wie ist da die Tools-Landschaft rundherum? Also sprechen wir da jetzt von irgendeinem kleinen Open-Source-Projekt von dem guten Salvatore oder ist das eine ganze Industrie?

Andy Grunwald (00:50:17 - 00:52:53)

Also Redis würde ich inzwischen nicht mehr als kleines Open-Source-Projekt bezeichnen. Ich denke, das ist schon einer der meistgenutzten Datenstrukturen-Server auf der ganzen Welt. Ist aber auch so, dass sich mit der Zeit natürlich durch die Popularität des Redis-Servers dann natürlich auch ein Business herumgebaut hat. Primär eine Firma, die bis vor kurzem noch Redis Labs hieß. Inzwischen heißt diese Firma nicht mehr Redis Labs, sondern heißt wirklich Redis. Das war eine Firma, die hat ganz am Anfang als Hosted-Redis-Provider angefangen. Mitte 2015, also vor acht Jahren, haben sie es irgendwie geschafft, dass der Lead Developer, also Salvatore Sanfilippo, also Antires, für diese Firma arbeitet. Danach haben sie sukzessive mehr und mehr Core-Entwickler eingestellt, die wirklich am Redis-Core arbeiten, wo in der Regel Salvatore Sanfilippo am Anfang schon sehr stark die Hand drauf hatte. Und dadurch bekam Redis Labs dann den offiziellen Sponsor von dem Open Source Projekt und dann hat meines Erachtens nach so ein bisschen das Corporate Thinking angefangen. Da hat so ein bisschen die kleinste Violine der Welt die Regierung übernommen, nämlich das Geld. Und dann ging es so ein bisschen rund. Okay, irgendwie haben sie dann so ein Enterprise Deck gemacht und dann haben sie Redis Modules implementiert und dann haben sie so Online Marketplace gebaut, wo du Module zertifizieren lassen kannst und auch kaufen kannst. Und dann fing es an mit den Lizenzänderungen. Dann haben sie nämlich alle Redis-Module von AGPL auf die Lizenz von Apache 2 mit einer Common Clause geändert und später dann auf eine eigene Lizenz, auf die Redis-Source-Available-Lizenz, halt um irgendwie ein bisschen die Konkurrenz in Schach zu halten. Also da merkt man schon, okay, da will jemand wirklich ein paar Dollar verdienen. Natürlich hängen da hinten auch Venture Capital Leute dran, blabliblub. Und da muss ich zugeben, man hat schon den Einfluss von Redis, der Firma, also Redis Labs, auf das Projekt gemerkt. Die Schönheit des Open Source Projektes ist in meiner Ansicht nach, die ist immer noch da, aber die hat ein paar Knick, aber die hat ein Knick bekommen. Mehr und mehr Concurrency hat in Redis Einfluss erhalten. Redis-Modules. Die Konzepte, die großen Konzepte, die jetzt implementiert werden, hab ich das Gefühl, nicht mehr ganz genau so durchdacht, wie es mal vorher war. Salvatore, also Antirest, hat sich sehr viel Zeit genommen, die Konzepte niederzuschreiben, ein paar Wochen drüber nachzudenken. Und nicht klack, klack, klack, weil irgendein Kunde danach geschrien hat. Und das find ich jetzt schade, aber ... Ja gut, die Welt ist halt nicht immer so, wie ich sie haben möchte, was?

Wolfi Gassler (00:52:53 - 00:53:52)

Ich habe auch gerade in der Zwischenzeit mal die Datenbankindizes gecheckt, also die Rankings, wie beliebt Datenbanken sind. Als erster Dämpfer schon mal für mich, Redis kommt in diesen Datenbanklisten vor, das heißt scheinbar sehen andere Leute das auch als Datenbank an. Die B-Engines.com ist so, glaube ich, eine der bekanntesten. Die listen Redis auf Platz 6. Andere Indizes, die ich gefunden habe, da schwirrt Redis so auf Platz zwischen 8, ja, 9, so in der Gegend herum. Also es ist doch aus einer beliebten Datenbank und wenn man sich so anschaut rundherum, da schwirren so DB2 von IBM, Elasticsearch, MongoDB, Postgres klarerweise, MySQL, Oracle, Microsoft SQL Server, SQLite mittlerweile auch und Microsoft Access unter den Top 10. Also es ist schon ein Data Storage, der unter den Top 10 in allen Rankings eigentlich liegt und demnach natürlich auch einen großen Stellenwert hat, muss man schon sagen, ja. Und gibt es jetzt auch, wie lange schon?

Andy Grunwald (00:53:52 - 00:53:54)

Da muss ich jetzt wirklich nachgucken.

Wolfi Gassler (00:53:55 - 00:53:57)

Tu mal was für deine Episode und dein Geld.

Andy Grunwald (00:53:57 - 00:54:03)

Meine Güte. Für meine Episode. Du hast dir die gewünscht.

Wolfi Gassler (00:54:03 - 00:54:11)

Jetzt fang ich an zu googeln. Wenn ich schneller bin, bekomme ich ein Bier. Du lachst jetzt, ich meine das ernst. Ja. 2009, 10. Mai, Initial Release.

Andy Grunwald (00:54:11 - 00:54:14)

Moment, muss ich kontrollieren. Wann? 2009.

Wolfi Gassler (00:54:14 - 00:54:17)

Er ist korrekt. Natürlich, ich habe immer recht.

Andy Grunwald (00:54:17 - 00:54:17)

22. März 2009, First Comet.

Wolfi Gassler (00:54:20 - 00:54:23)

Okay, dann darfst du jetzt nochmal die Frage beantworten.

Andy Grunwald (00:54:23 - 00:54:43)

Ich hab grad, Redis selbst gibt's anscheinend seit 2009, ich hab grad mal das Git-Repository geklont und hab mal ein Git-Log minus minus reverse gemacht und der erste Comet war am 22. März 2009. An einem Sonntag. Dieser Mann hat es wohl wirklich am Wochenende gestartet zu hacken. War anscheinend ein Zeitprojekter.

Wolfi Gassler (00:54:43 - 00:54:54)

Da sieht man wieder deine Liebe für Overengineering. Du schaust da im Git-Repo nach. Ich gehe einfach auf die Wikipedia-Seite von Redis. Da steht Initial Release 10. Mai 2009. Vor 13 Jahren.

Andy Grunwald (00:54:54 - 00:54:58)

Ist Wikipedia als Quelle inzwischen in der Akademik angekommen? Darf man das benutzen?

Wolfi Gassler (00:54:59 - 00:55:02)

Man darf es immer benutzen, aber man darf es nur nicht als Quelle angeben.

Andy Grunwald (00:55:02 - 00:55:04)

So, und wieso tun wir das jetzt hier im Podcast?

Wolfi Gassler (00:55:04 - 00:55:07)

Ja, du hast es ja eh double gecheckt. Dafür haben wir dich hier.

Andy Grunwald (00:55:07 - 00:55:09)

Verstehe, verstehe, okay. Lass ich so durchgehen.

Wolfi Gassler (00:55:09 - 00:55:14)

Und ich habe jetzt auch gelernt, dass man, was? Git reverse, double reverse, was, wie war dieser Befehl?

Andy Grunwald (00:55:14 - 00:55:25)

Git log minus minus reverse. Schmeißt dir das Git log. Also Git log gibt dir in der Regel den letzten Comet ganz oben. Und wenn du Git log minus minus reverse rausspuckst, dreht der das ganze Ding um. Und somit hast du den ältesten Comet oben.

Wolfi Gassler (00:55:26 - 00:55:49)

Ja, wieder was gelernt. Jetzt waren wir gerade bei dem professionellen Support durch Redis Labs und das ist eine bekannte Datenbank, will ich nicht sagen, Datenstruktur, Datenspeicher, Server, egal. Wie schaut es denn mit dem ganzen professionellen Hosted-Angeboten aus? Cloud-Provider, kann ich das auf GCP, EWS einfach so irgendwo hochfahren, gemanagt?

Andy Grunwald (00:55:49 - 00:57:00)

Also sowas lassen die drei Hyperscaler Google Cloud, Amazon und Azure sich natürlich auch nicht entgehen. Die Antwort ist ja. Du kriegst dann einen gemanagten Redis bei GCP. Bei Google Cloud Platform heißt das Memorystore. Bei AWS heißt es ElastiCache und bei Azure heißt es Azure Cache for Redis. Da kannst du dir das ganz einfach nur zusammen klicken. Da muss man natürlich ein bisschen gucken, was du für eine Architektur möchtest, weil in der Regel haben die dieses klassische Leader-Follower-Prinzip. Ich bin mir gar nicht sicher, wer von den dreien wirklich ein Cluster anbietet, weil ein Cluster zu betreiben ist halt schon nochmal ein bisschen was anderes. Bei Redis Und du hörst es auch schon bei Azure im Namen. Deren primary use case ist dann Azure Cache. Ja, also als Cache use case. Da muss man auch ein bisschen gucken, bieten die alle irgendwie eine Persistenz an mit Redis Database, also RDB oder Append-Only-File. Aber das sind alles immer Details, die man sich sowieso mal reinziehen muss, wenn du einer dieser Hyperscale-Angebote wahrnimmst. Aber prinzipiell, wenn du Redis als Cache nimmst, nutze das. Das ist kein schlechtes Angebot. Zu den Preisen kann ich da nichts sagen, aber Redis selbst ist jetzt auch nicht superschwierig zu betreiben, weil es eine sehr gut geschriebene, sehr gut konfigurierte Software ist.

Wolfi Gassler (00:57:01 - 00:57:05)

Fällt dir was auf bei den drei Namen von GCP, Amazon und Azure?

Andy Grunwald (00:57:05 - 00:57:07)

Ja, zweimal Cache und einmal Memory.

Wolfi Gassler (00:57:07 - 00:57:11)

Da kommt nirgends Datenbank vor in diesen Namen. Die haben das verstanden.

Andy Grunwald (00:57:11 - 00:58:20)

Weiß ich nicht, weil Amazon zum Beispiel lässt die Cache, Da kannst du wählen zwischen Redis und Memcached. Und Memcached ist ganz klar keine Datenbank. Und bei Memorystore und GCP Memorystore kannst du auch Memcached oder Redis wählen. Also, deren Usecase ist halt eine ganz andere Geschichte. Und ich glaube, die sind halt so früh gestartet damit, ja, vielleicht war es damals wirklich noch nicht so die Datenbank, die es heute ist. Ich denke, aber ich würde mich darauf einlassen, wenn du sagst, okay, du hast jetzt hier jemanden, der wirklich PostGrid programmiert oder eine Oracle oder was weiß der Geile. Logisch, die Leute werden ganz klar sagen, Redis, geh mal weg mit deinem Kinderspielzeug. Geh mal aus deinem Sandkasten da raus und nutz mal eine richtige Datenbank. Bei solchen Leuten würde ich sagen, stimmt, ihr habt recht, weil ihr bewegt euch in Sphären. Ihr habt ein anderes Verständnis als Datenbanken. Für mich als ganz einfacher, simpler Programmierer, Ich möchte mit dem Ding kommunizieren und Daten abspeichern. Das ist für mich eine Datenbank. Und das macht Redis eigentlich ganz gut, glaub ich. Also von meinem dummen Verständnis an der Datenbank, Redis ist dann eine Datenbank. Und GCP, Amazon und Azure, ich glaube, da sind wir uns einig, die overengineeren ja auch, oder?

Wolfi Gassler (00:58:20 - 00:58:22)

Was hat das mit overengineering zu tun?

Andy Grunwald (00:58:22 - 00:58:37)

Die würden zum Beispiel Redis ja nie als Datenbank nehmen. Wenn ich sowas sehe wie BigQuery und Spanner, irgendwie eine Datenbank, die weltweit in so Billiseconds irgendwelche Daten speichern muss. Ich glaube, ich würde mich aus dem Fenster lehnen und sagen, die haben eine andere Antwort.

Wolfi Gassler (00:58:38 - 00:58:49)

Ich glaube, wir können das schon unter Datenbank lassen, aber die Konsistenzgarantien werden nicht gegeben. Aber um ehrlich zu sein, du brauchst sie in 99% der Fällen wahrscheinlich auch einfach nicht.

Andy Grunwald (00:58:49 - 00:58:51)

Wie sei denn, du bist eine Bank.

Wolfi Gassler (00:58:51 - 00:59:14)

Und ganz abgesehen davon würde mich mal interessieren, wie viele Leute in MySQL wirklich Transaktionen überhaupt verwenden. Ich glaube eigentlich, dass das auch irgendwo im 5% Bereich oder so liegt. Ich glaube, das ist so ähnlich, wie früher hat man bei Word immer behauptet, der klassische User, der verwendet so drei bis vier Prozent von dem Funktionsumfang von Word oder Excel. Und ich glaube, so ähnlich ist es oft bei Datenbanken auch.

Andy Grunwald (00:59:14 - 00:59:33)

Ich hatte gedacht, du sagst jetzt, der klassische Word-User sagt immer, Clippy nervt und hat es nie verwendet. Da würde ich eher sagen, super viele Leute haben Clippy verwendet, haben sich aber nie getraut, es zuzugeben. Und ob Leute nur drei bis vier Prozent der Excel-Funktionalität heutzutage nutzen, da würde ich mal ganz sicher sagen, die benutzen deutlich weniger.

Wolfi Gassler (00:59:33 - 00:59:43)

Ja, nur weil Clippy nicht mehr da ist zum Helfen. Aber bevor wir jetzt alle überfordern, weil niemand mehr so alt ist, dass er überhaupt Clippy kennt, beenden wir mal die ganze Datenbank-Diskussion, glaube ich.

Andy Grunwald (00:59:43 - 01:00:39)

Schade, ich hatte gedacht, wir sprechen jetzt darüber, wie man Clippy in VBA nachprogrammiert. Aber nein, kommen wir dem Wunsch von Wolfgang mal nach. Das war ein kleiner Einstieg in Redis, meine bisher immer noch favorisierte Datenbank oder Data Structure Server. Wer sehr viel lernen möchte über Implementierung von Algorithmen, C-Programmierung, Verschriftlichung von Programmierkonzepten, ich denke für diese Person ist Redis ein gutes Projekt, da mal ein bisschen tiefer einzusteigen. Wir haben aber auch bei weitem nicht alles erwähnt. Wir haben nicht über Redis-Streams gesprochen, nicht über Redis-Cluster, nicht um das Tooling drumherum gesprochen wie Trampoxy, Redis-Sentinel, High-Availability und so weiter und so fort. Vielleicht machen wir dazu irgendwann mal eine Episode. Ich hoffe auf jeden Fall, ich konnte ein bisschen meine Liebe und Passion für Redis mit euch teilen. Und ich hoffe, ein paar Leuten wurde auch etwas warm ums Herz. Mir auf jeden Fall.

Wolfi Gassler (01:00:39 - 01:00:58)

Bei dieser Romantik weiß ich gar nicht, wie ich weitermachen soll. Der Aufruf, wer paar negative Details zu Redis hat oder vielleicht auch negative Erfahrungen oder auch Nachteile, bitte gerne nur her damit. Wir werden die auch dementsprechend verteilen. Am besten auf Twitter, in die Kiosk wie immer oder bei E-Mail stetig at engineeringkiosk.de.

Andy Grunwald (01:00:58 - 01:01:14)

Und falls ihr zufällig auf irgendeiner Podcast-Plattform seid, Spotify, Google Podcasts, Apple Podcasts oder ähnliches, bewertet uns doch mal und lasst uns gegebenenfalls einen Kommentar da. Zum Beispiel, das kann man auf Apple ganz gut. Und uns würde sehr freuen, wenn ihr mal auf Folgen beziehungsweise Abonnieren drückt. Das hilft uns ungemein.

Wolfi Gassler (01:01:15 - 01:01:22)

Moment, musst du nicht noch irgendwie sagen, dass diese Glocke da, die Glocke ist doch auch immer wichtig, Kavikati. Ich verwende diese Plattformen ja nicht, ich bin ja Open Source User.

Andy Grunwald (01:01:22 - 01:01:24)

Ne, Glocke ist, glaube ich, auf YouTube.

Wolfi Gassler (01:01:24 - 01:01:27)

Ah, die Glocke gibt es auf Spotify meines Wissens auch.

Andy Grunwald (01:01:27 - 01:01:47)

Ja, wenn es eine Spotify-Glocke gibt, dann drückt auch die Glocke oder so. Das muss ich jetzt auch mal nachgucken, weiß ich jetzt nicht. Uns würde auf jeden Fall eine Bewertung freuen oder wenn ihr uns folgen würdet. Das hilft uns sehr. Wir sehen das alles in den Statistiken und da haben wir natürlich immer einen Motivationsboost, was uns auch in Phasen, wo wir mal nicht so gut drauf sind, dann immer sehr hilft.

Wolfi Gassler (01:01:47 - 01:01:50)

Obwohl man sich das gar nicht vorstellen kann, dass der Andi einmal schlecht gelaunt ist.

Andy Grunwald (01:01:50 - 01:01:56)

Kommt ab und zu auch vor. Ich bin auch nur ein Mensch. Wie dem auch sei, das war's von uns. Wir wünschen euch einen schönen Tag.

Wolfi Gassler (01:01:56 - 01:01:59)

Bis zum nächsten Mal und eine schöne Woche. Tschau. Tschö.