Auto Tiering (Redis on Flash) : Redis remplace RocksDB par Speedb

Speedb s'impose auprès de Redis

Cette jeune pousse basée à Tel-Aviv et fondée en 2020 développe un fork du moteur historique de Redis on Flash, RocksDB, développé originellement par Facebook. Elle a levé plus de 4 millions de dollars auprès d’Hyperwise Ventures et d’Intel Ignite. Pour information, CockroachDB a, lui aussi, bâti sa technologie par-dessus RocksDB.

Speedb doit permettre d’optimiser les mécanismes automatiques de vidage mémoire et d’accès aux données pour plusieurs bases de données déployées simultanément.

Pour comprendre les avantages de ce moteur, il faut s’intéresser aux éléments essentiels de RocksDB (et de la plupart des bases de mémoire in-memory).

Dans RockDB, les données sont temporairement placées en mémoire « dans un tampon contenant des clés et les valeurs avant qu’elles ne soient écrites sur disque », appelé Memtable. À chaque écriture, RocksDB interagit avec le Write Buffer Manager (WBM), chargé de contrôler l’usage total de la RAM par des bases de données (ou des familles de colonnes) pour savoir s’il faut la vider. Ce processus entraîne le transfert des Memtables sélectionnées sur disque en les rendant immuables.

Le « proactive flushing », l’atout numéro 1 de Speedb

Selon les créateurs de Speedb, cette approche est sous-optimisée. Le WBM vide en priorité les tampons historiquement placés en mémoire, peu importe leur taille, tandis que la multiplication des opérations de vidage affecte les performances.

Outre un nouveau type de tables et plusieurs fonctions d’optimisation, Speedb introduit un mécanisme nommé « proactive flushing ». Cette modification du WBM ajoute un thread interne chargé d’enclencher le vidage mémoire au bon moment, et non plus seulement en fonction des écritures.

Le mécanisme permet de mieux choisir les Memtables en ciblant en priorité les plus volumineuses. Aussi, le Write Buffer Manager peut maintenant suivre les opérations de vidage mémoire en parallèle, tout en limitant les opérations concurrentes qui pourraient affecter les performances l’une ou plusieurs des bases de données.

Associée aux SSD NVMe, l’implémentation de Speedb aurait grandement amélioré les performances de Redis on Flash.

« Auto Tiering permet d’améliorer considérablement les performances en termes de débit et de latence, en doublant le débit et en réduisant de moitié la latence par rapport au moteur de stockage de la génération précédente (RocksDB), et en réduisant les coûts d’infrastructure jusqu’à 70 % », avance Rowan Trollope, CEO de Redis, dans un billet de blog.

Des limitations à ne pas oublier

Selon Speedb, l’intégration de son moteur dans la pile Redis a été testée pendant plus d’un an auprès de clients grand compte.

La technologie n’est toutefois pas adaptée à tous les usages, prévient Redis. Auto Tiering fonctionne moins bien quand les clés sont trop longues par rapport à la taille des valeurs, quand le modèle d’accès aux données est trop étendu ou quand elles sont trop fréquemment déplacées vers et depuis la RAM. S’il est possible de traiter un large volume de données, les grandes collections de valeurs strings (Sets), forcément stockées en mémoire, ne sont pas non plus idéales.

Autre contrainte, « la taille de la RAM ne peut être inférieure à 10 % ou supérieure à 60 % de la mémoire totale », peut-on lire dans la documentation. « Nous vous recommandons de conserver au moins 20 % de toutes les valeurs dans la RAM ». Aussi, les SSD (NVMe ou SATA, mais la première technologie est mieux adaptée) doivent être « rattachés localement », et non via le réseau à l’aide d’un SAN ou d’un NAS.

Enfin, Auto Tiering n’est pas une technologie pour persister les données : il faut mettre en place une autre couche de stockage et les règles qui vont avec.

Selon Redis, cette évolution de Redis on Flash s’adapte bien aux applications mobiles bancaires avec lesquelles les usagers observent les dernières transactions et, de temps en temps, des relevés plus anciens ou dans le cadre de gestion de base de données de profil par des éditeurs de jeu vidéo massivement multijoueur. 

Dans un autre registre, Redis dévoile la disponibilité générale de son opérateur Kubernetes qui prend en charge les déploiements actifs-actifs tout en simplifiant leur mise en route à l’aide de fichiers YAML. L’opérateur doit assurer « l’harmonie » entre le cluster Redis et l’infrastructure Kubernetes. Les bases de données sont exécutées en mode stateful, tandis que les différents services adjacents (UI, plugins) et les applications le sont en mode stateless. Redis Enterprise Operator for Kubernetes est à la fois compatible avec AKS, GKE ainsi que EKS et avec Anthos, Outpost, Azure Arc ou un déploiement K8s on premise.