Redka – Redis mit SQLite neu implementiert

• Redka verfolgt das Ziel, die Vorteile von Redis mit SQLite neu zu implementieren und dabei mit der Redis-API kompatibel zu bleiben
• Wichtige Merkmale:
  • Die Daten müssen nicht in die Größe des RAM passen
  • Unterstützung für ACID-Transaktionen
  • Bessere Datenabfrage- und Reporting-Funktionen über SQL-Views
  • Unterstützung sowohl für In-Process-Server (Go-API) als auch für Standalone-Server (RESP)
  • Unterstützung für Redis-kompatible Befehle und Protokolle
• Das Projekt befindet sich derzeit noch in Entwicklung; Informationen zum aktuellen Support-Status und zur Roadmap finden sich in den untenstehenden Dokumenten

Unterstützte Befehle

• Redka hat das Ziel, die fünf zentralen Redis-Datentypen String, List, Set, Hash und Sorted Set zu unterstützen
• String, Hash, Key-Management und Transaktionsbefehle werden bereits unterstützt, List, Set und Sorted Set befinden sich noch in Entwicklung
• Eine detaillierte Liste der Befehle findet sich im Originaltext

Installation

Standalone-Server

• Die zur jeweiligen Plattform passende Binärdatei von der Release-Seite herunterladen und ausführen
• Bei Verwendung von Docker das Image mit docker pull nalgeon/redka herunterladen

Go-Modul

• Das Modul mit go get github.com/nalgeon/redka installieren
• Als SQLite-Treiber github.com/mattn/go-sqlite3 oder modernc.org/sqlite verwenden

Verwendung

Standalone-Server

• Die heruntergeladene Binärdatei im Format redka [-h host] [-p port] [db-path] ausführen
  • Standardwerte sind Host localhost, Port 6379 und kein DB-Pfad (In-Memory)
• Bei Verwendung von Docker mit dem Befehl docker run starten. Weitere Optionen siehe Originaltext
• Nach dem Start des Servers kann die Verbindung über Redis-kompatible Clients wie redis-cli, redis-py oder go-redis erfolgen

In-Process-Server

• Mit der Funktion redka.Open() ein DB-Objekt erzeugen. Der Import des Treibers ist erforderlich
• Durch Aufruf der Methoden des Objekts redka.DB verschiedene Befehle ausführen
• Transaktionen mit den Methoden View (schreibgeschützt) und Update (schreibbar) verarbeiten

Persistenz

• Redka speichert Daten in der SQLite-Datenbank mithilfe der Tabellen rkey, rstring und rhash
• Über Views für die jeweiligen Datentypen (vstring, vhash usw.) lassen sich Daten per SQL abfragen

Performance

• Vergleich der Performance von Redis und Redka mit dem Tool redis-benchmark
  • Redka ist bei SET etwa 6-mal und bei GET etwa 2-mal langsamer
  • Zeigt dennoch eine Leistung von etwa 23K Writes und 57K Reads pro Sekunde
• Beim Ausführen in Containern kann es zu Leistungseinbußen kommen

Roadmap

• Für das Release 1.0 ist eine Implementierung geplant, die sich auf die Hauptfunktionen aus der Zeit von Redis 2.x konzentriert
  • Unterstützung für String, Hash, Key-Management und Transaktionen ist abgeschlossen
  • Sorted Set befindet sich in Entwicklung
  • List und Set sind geplant
• In zukünftigen Versionen sind Datentypen wie Stream, HyperLogLog und Geo sowie Pub/Sub vorgesehen
• Für Lua-Scripting, Authentifizierung/ACL, Multi-DB, Watch/Unwatch usw. ist keine Implementierung geplant
• Cluster- und Sentinel-Funktionen sollen ebenfalls nicht implementiert werden

Meinung von GN⁺

• Der Ansatz von Redka, weitgehend Redis-kompatibel zu sein und gleichzeitig Persistenz zu bieten, ist interessant. Auch die Unterstützung für ACID-Transaktionen dürfte ein Vorteil sein.
• Bei der Performance reicht es zwar nicht an Redis heran, aber wenn Persistenz benötigt wird, scheint es eine durchaus erwägenswerte Alternative zu sein.
• Da sich das Projekt jedoch noch in einem frühen Entwicklungsstadium befindet, sollte man die Stabilität weiter beobachten; auch die in der Roadmap fehlenden Funktionen sind bei einer tatsächlichen Einführung zu berücksichtigen.
• Für reine In-Memory-Anwendungen wird es Redis letztlich wohl nicht schlagen, aber als auf SQLite basierende Persistenzschicht könnte es sich als nützlich erweisen.
• Derzeit steigt die Nachfrage nach schlanken Stacks in Edge-Computing-Umgebungen; in solchen Bereichen könnte man Redka anstelle von Redis ausprobieren.

[yangeok]

Das wäre wohl nützlich, wenn man Redis an einen Scheduler anbinden muss, haha.

[GN⁺]

Hacker-News-Kommentare

• Es gibt Überlegungen dazu, inwieweit man dem nebenläufigkeitsfreien Modell von Redis folgen sollte, bei dem „alles in einem einzigen Thread serialisiert“ ist
• Mit der Low-Level-Bibliothek von SQLite, aktiviertem WAL, einer Verbindung pro Lese-Goroutine und einem dedizierten Writer-Thread, an den Schreib-Batches über einen gepufferten Channel bzw. eine Queue gesendet werden, lässt sich mit SQLite eine bessere Performance erzielen
• Dadurch kann man den eingebauten verbindungsspezifischen Mutex von SQLite deaktivieren und dennoch Thread-Sicherheit wahren, da jede Verbindung jeweils nur von einem Thread gleichzeitig genutzt wird
• Verwendet man große Buffer im Arena-Stil, etwa indem man Parameter-Bytes aus Netzwerk-Requests/Sockets in Buffer kopiert oder Daten aus SQLite direkt in den Socket kopiert, kann man viele einzelne String-Allokationen und Übergaben vermeiden und so viel Zeit sparen
• Das sind Tipps aus der Erfahrung, in Go die maximale Schreib-Performance aus SQLite herauszuholen
• Ich mag sowohl Redis als auch SQLite und habe mich deshalb entschieden, beide zu kombinieren. SQLite ist auf viele kleine Queries spezialisiert, daher scheint es gut zu passen, weil eine relationale Engine damit Redis so nahe kommt, wie es eben geht
• Ich warte darauf, dass jemand die State Machine von TigerBeetle ersetzt, um eine Redis-API zu implementieren
• Es wäre schön, eine Redis-Alternative zu haben, bei der man nicht darüber nachdenken muss, ob der Datensatz in den Arbeitsspeicher passt
• Das gesamte Wertversprechen von Redis besteht darin, im Arbeitsspeicher zu arbeiten und damit Arbeitsspeicher-ähnliche Performance zu liefern. Sobald man auf die Festplatte geht, gibt es kaum noch einen Grund, Redis zu verwenden
• Sobald Netzwerk-I/O hinzukommt, verschwindet ein großer Teil der fantastischen Performance von Redis. Nutzt man einen gehosteten Redis-SaaS-Dienst, leidet die Performance stark. Wenn man einen Redis-kompatiblen Key/Value-Store im eigenen Cluster einfacher betreiben könnte, wäre das ein Vorteil
• Ich frage mich, ob dieses Projekt oder Garnet mehr Redis-Befehle unterstützt. Ich möchte für lokale Debugging-Zwecke eine Teilmenge Redis-kompatibler Funktionen in ein Programm einbetten; dazwischen liegt eine API, die vor nicht unterstützten Redis-Befehlen schützen kann
• Als Foursquare MongoDB bekannt machte, veröffentlichte jemand einen PoC für eine in MySQL implementierte NoSQL-Datenbank, aber der setzte sich nicht durch. Es bringt einen jedoch zum Nachdenken, wie viel Performance geopfert wurde, nur um nicht jedes Mal SQL neu zu erfinden, wenn man eine Datenbank braucht. Ich mag solche Experimente, und manchmal führen sie zu neuen Projekten
• Ich nutze Redis als Cache-Layer vor der Datenbank. Ich verstehe dieses Konzept nicht
• Allerdings wird SetMaxConnections(1) verwendet, doch im WAL-Modus (der hier aktiv ist) unterstützt SQLite Schreibvorgänge, die Lesezugriffe nicht blockieren, sodass es Vorteile bringen könnte, Lese-Nebenläufigkeit zuzulassen