Redka - Redis réimplémenté avec SQLite

• Redka vise à réimplémenter les avantages de Redis avec SQLite tout en restant compatible avec l’API Redis
• Principales caractéristiques :
  • Les données n’ont pas besoin de tenir dans la RAM
  • Prise en charge des transactions ACID
  • Consultation des données et reporting renforcés via des vues SQL
  • Prise en charge à la fois d’un serveur in-process (API Go) et standalone (RESP)
  • Prise en charge des commandes et du protocole compatibles Redis
• Le projet est actuellement en cours de développement ; voir la documentation ci-dessous pour l’état de prise en charge et la feuille de route

Commandes prises en charge

• Redka vise à prendre en charge les cinq types de données fondamentaux de Redis : String, List, Set, Hash et Sorted Set
• Les commandes String, Hash, la gestion des clés et les commandes de transaction sont déjà prises en charge ; List, Set et Sorted Set sont en cours de développement
• Pour la liste détaillée des commandes, consulter la source d’origine

Installation

Serveur standalone

• Télécharger puis exécuter le binaire adapté à votre OS depuis la page Release
• Avec Docker, télécharger l’image via docker pull nalgeon/redka

Module Go

• Installer le module avec go get github.com/nalgeon/redka
• Utiliser github.com/mattn/go-sqlite3 ou modernc.org/sqlite comme pilote SQLite

Utilisation

Serveur standalone

• Exécuter le binaire téléchargé sous la forme redka [-h host] [-p port] [db-path]
  • Valeurs par défaut : host localhost, port 6379, aucun chemin de DB (en mémoire)
• Avec Docker, lancer via la commande docker run. Voir la source d’origine pour les options détaillées
• Une fois le serveur lancé, il est possible de se connecter avec des clients compatibles Redis comme redis-cli, redis-py ou go-redis

Serveur in-process

• Créer un objet DB avec la fonction redka.Open(). L’import du pilote est obligatoire
• Exécuter les différentes commandes en appelant les méthodes de l’objet redka.DB
• Gérer les transactions avec les méthodes View (lecture seule) et Update (écriture autorisée)

Persistance

• Redka stocke les données dans la base SQLite en utilisant les tables rkey, rstring et rhash
• Les données peuvent être consultées en SQL via des vues propres à chaque type (vstring, vhash, etc.)

Performances

• Comparaison des performances entre Redis et Redka avec l’outil redis-benchmark
  • Redka est environ 6 fois plus lent sur SET et 2 fois plus lent sur GET
  • Il affiche malgré tout des performances d’environ 23K écritures/s et 57K lectures/s
• Les performances peuvent se dégrader en exécution dans un conteneur

Feuille de route

• La version 1.0 prévoit surtout l’implémentation des fonctionnalités majeures de l’époque de Redis 2.x
  • String, Hash, gestion des clés et prise en charge des transactions sont terminés
  • Sorted Set est en cours de développement
  • List et Set sont prévus
• Les versions futures doivent ajouter des types de données comme Stream, HyperLogLog et Geo, ainsi que la fonctionnalité Pub/Sub
• Aucune implémentation n’est prévue pour le scripting Lua, l’authentification/ACL, le multi-DB, Watch/Unwatch, etc.
• Les fonctionnalités de cluster et Sentinel ne sont pas non plus prévues

L’avis de GN⁺

• L’approche de Redka, qui offre la persistance tout en restant largement compatible avec Redis, est intéressante. La prise en charge des transactions ACID semble aussi être un atout.
• En matière de performances, Redka n’atteint pas Redis, mais si la persistance est nécessaire, cela semble être une alternative tout à fait envisageable.
• Cela dit, le projet en est encore à ses débuts ; il faudra donc observer davantage sa stabilité, et tenir compte des nombreuses fonctionnalités absentes de la feuille de route avant une adoption réelle.
• Pour un usage purement in-memory, il ne pourra sans doute pas battre Redis, mais en tant que couche de persistance basée sur SQLite, il pourrait s’avérer utile.
• La demande pour des stacks légères augmente actuellement dans les environnements edge computing ; dans ce type de contexte, on pourrait envisager d’utiliser Redka à la place de Redis.

[yangeok]

Ça pourrait être pratique quand il faut brancher Redis sur un scheduler haha

[GN⁺]

Commentaires sur Hacker News

• Je me demande dans quelle mesure il faut suivre le modèle sans concurrence de Redis, où « tout est sérialisé sur un seul thread »
• On peut obtenir de meilleures performances avec SQLite en utilisant la bibliothèque bas niveau, en activant le WAL, en utilisant une connexion par goroutine de lecture et en envoyant des lots d’écriture à un thread writer dédié via un canal/file tamponné
• Cela permet aussi de désactiver le mutex intégré par connexion de SQLite tout en conservant la sûreté des threads, puisque chaque connexion n’est utilisée que par un seul thread à la fois
• Utiliser de gros buffers de style arena, par exemple en copiant les octets des paramètres issus des requêtes réseau/sockets dans un buffer ou en copiant directement depuis SQLite vers le socket, peut faire gagner beaucoup de temps en réduisant les allocations et passages de chaînes individuelles
• Ce sont des conseils tirés de mon expérience à essayer d’obtenir le débit d’écriture maximal de SQLite depuis Go
• J’aime à la fois Redis et SQLite, donc j’ai décidé de combiner les deux. SQLite est spécialisé dans beaucoup de petites requêtes, donc il me semble bien adapté, un moteur relationnel s’étant autant rapproché de Redis que possible
• J’attends que quelqu’un remplace la machine d’état de TigerBeetle pour implémenter l’API Redis
• Ce serait bien d’avoir une alternative à Redis où il n’est pas nécessaire de se demander si le jeu de données tient en mémoire
• Toute la proposition de valeur de Redis repose sur le fait de fonctionner en mémoire et d’offrir des performances de la mémoire. Si on passe au disque, il n’y a presque plus de raison d’utiliser Redis
• Dès qu’on ajoute des E/S réseau, une grande partie des performances fantastiques de Redis disparaît. Utiliser un service Redis hébergé en SaaS a un impact important sur les performances. S’il était plus simple d’exécuter un store clé/valeur compatible Redis sur son propre cluster, ce serait un avantage
• Je me demande si ceci ou Garnet prend en charge davantage de commandes Redis. J’essaie d’intégrer à un programme un sous-ensemble de fonctionnalités compatibles Redis pour du débogage local, avec une API intermédiaire permettant de se protéger contre les commandes Redis non prises en charge
• Quand Foursquare a rendu MongoDB célèbre, quelqu’un avait publié une preuve de concept d’une base NoSQL implémentée sur MySQL, mais cela n’a pas pris. Cela fait quand même réfléchir à la quantité de performances qu’on a sacrifiée pour éviter de réinventer SQL chaque fois qu’on a besoin d’une base de données. J’aime ce genre d’expériences, qui mènent parfois à de nouveaux projets
• J’utilise Redis comme couche de cache devant la base de données. Je ne comprends pas ce concept
• Cela dit, vous utilisez SetMaxConnections(1), mais en mode WAL (qui est utilisé), SQLite permet des écritures qui ne bloquent pas les lectures, donc autoriser la concurrence en lecture pourrait avoir des avantages