Redis Labs veut prouver sa polyvalence avec Redis 7.0

Un concurrent de plus en plus frontal à Elastic, MongoDB et Couchbase

En effet, Redis est revenu sur la disponibilité générale de RedisSearch 2.0, son moteur de recherche et d’indexation développé en C doté, selon l’éditeur, de capacités en temps réel. Benchmark maison à l’appui, l’entreprise assure que son moteur est 58 % plus rapide qu’Elasticsearch pour indexer 5,6 millions de pages Wikipédia. Sur un exercice de recherche, « le débit de RediSearch a atteint 12,5 K ops/sec contre 3,1 K ops/sec avec Elasticsearch, soit quatre fois plus rapide. De plus, la latence de RediSearch est légèrement meilleure, à 8 millisecondes en moyenne contre 10 ms avec Elasticsearch », écrivent les employés de l’éditeur. Là encore, l’entreprise s’appuie sur une architecture in-memory associée au modèle de données, trie et prend en charge plusieurs langages, dont le français, l’allemand, l’espagnol, le russe, l’anglais, ou encore le chinois. Seulement, le moteur ne supporte pas nativement les fichiers JSON. L’éditeur travaille depuis plus d’un an sur RedisJSON, un module permettant de rendre compatible les données au format JSON avec les clés Redis, de type documents.

Au second trimestre 2021, RediSearch profitera d’une intégration avec RedisJSON. Pour l’instant, cette capacité est disponible en préversion privée. Plus tard, RedisSearch sera apte à effectuer des indexations et des requêtes sur les données Streams, des séries chronologiques. Toutefois, l’éditeur ne cherche pas à couvrir les cas d’usage de supervision IT, comme le fait Elastic, mais seulement ceux dédiés à l’exploration et à la recherche de données (Enterprise Search, inventaire en temps réel, indexation de base de données secondaires, moteur de recherche dans un CRM, etc.).

Redis Labs renforce la tolérance aux pannes (et la cohérence des données)

Surtout, l’éditeur promet le support du mode actif/actif pour les clusters de RediSearch.

L’entreprise propose aussi une capacité active-active pour Redis Enterprise Software depuis la version 5.4.2, déployée en avril 2019. La release 6.0.20 (avril 2021) apporte un nouveau mécanisme de migration de clusters actif/passif vers d’autres, actif/actif. À cela s’ajoute une politique d’éviction associée à la mémoire (elle « commence à évincer les clés lorsque l’une des instances Active-Active atteint 80 % de sa limite de mémoire », peut-on lire dans la documentation). Cette version 6.0.20 intègre également le protocole LDAP dans son système de gestion des rôles (RBAC) et doit améliorer l’administration des flux TLS entre la base de données et les clients applicatifs.

Dans cette volonté de muscler son SGBD, Redis Labs a une nouvelle fois évoqué l’arrivée du module API RedisRaft, en développement depuis Redis 5 (2018), qui vient de passer avec succès le test Jespen. Par le protocole de consensus distribué Raft, il s’agit d’apporter des capacités de cohérence (une sérialisation stricte) et de la tolérance aux pannes aux nœuds d’un même cluster. Actuellement, Redis propose au mieux une cohérence éventuelle, pouvant provoquer une désynchronisation des données stockées sur plusieurs serveurs ou des erreurs d’écriture si un des serveurs n’est pas disponible.

L’algorithme Raft réclame à minima trois nœuds. Chacun des nœuds joue un rôle : le leader, est chargé de la réplication des logs, le candidat interroge à intervalle régulier le serveur pour désigner le leader, et le suiveur reçoit les logs répliqués. Avec ce principe, un nœud peut tomber sans affecter le fonctionnement du cluster et « les écritures reconnues sont validées et ne seront jamais perdues. Les lectures renverront toujours l’écriture approuvée la plus récente », assure l’éditeur. Ces affirmations se vérifient tant que la majorité des nœuds du cluster reste active. Dans cette configuration à trois nœuds, si deux d’entre eux tombent, le cluster s’arrête, mais la reprise d’activité est plus rapide.

Si RedisRaft sera disponible en même temps que redis 7.0 Yossi Gottlieb, Chief Architect chez Redis Labs, prévient qu’il s’agit d’un aparté à la base de données et qu’en l’état, l’usage de la première implémentation du protocole n’est pas recommandé en production. Pour autant, le Chief Architect pense que RedisRaft « est un bon ajout à l’écosystème Redis, en complément du projet cœur ».

IA : Redis Labs veut propulser les feature stores

Dans cette même veine, L’éditeur a présenté les avancées de RedisAI, un module correspondant à un moteur dédié à l’inférence de modèles de machine learning. Celui-ci supporte les frameworks TensorFlow, PyTorch et ONNXRuntime. À proprement parler, RedisAI s’installe sur un serveur Redis et permet aux utilisateurs de télécharger ces librairies. Selon l’éditeur, ce serveur devient le lieu d’inférence des modèles. Il entend ainsi éviter une adhérence applicative, si l’exécution des modèles s’effectue à cet emplacement, ou de multiplier les microservices pour jouer chaque modèle séparément. Plus intéressant, cette inférence se produit au plus près des données : RedisAI s’exécute in-memory avec le SGBD NoSQL. RedisAI s’accompagne de deux structures de données : le tensor (un array multidimensionnel de type numérique comme des floats) et un modèle (un modèle ML pour un par back-end donné, ici TensorFlow, Pytorch ou ONNXRuntime).

Les tensors sont employés comme des entrées et des sorties des inférences. Les modèles s’appuient sur les tensors en entrée et génèrent des tensors en sorties.

Mais l’éditeur a pris conscience de l’utilisation de Redis au sein de Feast, le feature store open source développé par Google et Gojek. Un feature store est une architecture conçue pour stocker et retrouver les données et métadonnées constituant les paramètres (features) d’un modèle de machine learning. Le SGBD est exploité dans Feast pour jouer le rôle « d’Online feature store », c’est-à-dire de lieu de stockage des paramètres pour des modèles en inférence. Une autre base de données ou un datawarehouse sert d’espace de stockage pour les features « hors ligne », en clair les paramètres des algorithmes en phase d’apprentissage.

Redis Labs voit la possibilité de diminuer le nombre d’opérations nécessaires, d’une part grâce à Redis Gears, un framework pour écrire et exécuter des fonctions dans Redis et d’autre part en profitant de RedisAI.

Dans ce cas spécifique, les fonctions permettent d’uniformiser les formats de données stockées dans la base de données, c’est-à-dire de les transformer en tensors qui peuvent être manipulés par le modèle inféré par RedisAI. Si l’on résume, cette combinaison de Feast, de Redis, de RedisAI et de Redis Gears doit permettre de créer un online feature store, d’injecter les paramètres vers les modèles, de stocker les modèles et de les inférer, de synchroniser les paramètres employés à l’entraînement et à l’inférence. L’éditeur propose ainsi un package pour déployer cet online feature store sur les infrastructures sur site et promet de le fournir et de l’administrer depuis Redis Enterprise Cloud dès le second semestre 2021.

Enfin, Ofer Bengal a annoncé un partenariat avec AWS facilitant, comme le PDG l’expliquait au MagIT, de déployer Redis Enterprise Cloud depuis la marketplace AWS, et simplifiant la consommation de crédits achetés auprès du fournisseur cloud. Précisons qu’en avril 2021, Redis est en tête du classement des bases de données clés-valeurs mené par DBEngines, devant Amazon DynamoDB. Avec Google Cloud, Redis Labs dévoile une préversion privée de Redis Enterprise en tant qu’application Kubernetes sur l’infrastructure hybride Anthos et de Redis Enterprise sur la place de marché dédiée à Google Cloud Kubernetes (GKE).