Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Nous sommes heureux d’annoncer la disponibilité générale de RedisGears, un moteur sans serveur qui offre une programmabilité infinie dans Redis. Les développeurs peuvent utiliser RedisGears pour améliorer les performances des applications et traiter les données en temps réel, tandis que les architectes peuvent en tirer parti pour favoriser la simplicité architecturale.

En tant que cadre dynamique pour l’exécution de les fonctions qui implémentent des flux de données dans Redis, RedisGears fait abstraction de la distribution et du déploiement des données pour accélérer le traitement des données à l’aide de plusieurs modèles dans Redis. RedisGears vous permet de programmer tout ce que vous voulez dans Redis, de déployer des fonctions dans chaque environnement, de simplifier votre architecture et de réduire les coûts de déploiement, et d’exécuter votre moteur sans serveur là où résident vos données.

RedisGears peut être déployé pour une variété de cas d’utilisation :

  • Traitement des données en temps réel, puisqu’il s’exécute intégré dans Redis
  • Traitement fiable des événementstels que les nouveaux messages dans les flux ou les mises à jour d’entités dans Redis, et
  • Opérations sur plusieurs structures de données et des modèles de données de manière transparente sur les fragments.

RedisGears est GA

En plus d’annoncer RedisGears, nous dévoilons également sa première recette. Une « recette » est un ensemble de fonctions (et toutes les dépendances qu’elles peuvent avoir) qui, ensemble, traitent un problème ou un cas d’utilisation de niveau supérieur. Notre première recette est rgsync. Aussi appelé écrire derrière, cette capacité vous permet de traiter Redis comme votre base de données frontale, tandis que RedisGears garantit que toutes les modifications sont écrites dans vos bases de données ou systèmes d’entrepôt de données existants.

Pour vous aider à comprendre la puissance de RedisGears, nous commencerons par une explication de l’architecture RedisGears et de ses avantages. Ensuite, nous discuterons de la manière dont ces avantages s’appliquent à l’écriture différée et nous démontrerons son comportement via une application de démonstration que nous avons créée.

Architecture RedisGears

Au cœur de RedisGears se trouve un moteur qui exécute des flux ou des fonctions fournis par l’utilisateur via une interface programmable. Les fonctions peuvent être exécutées par le moteur de manière ad hoc, ou déclenchées par différents événements pour un traitement piloté par les événements. Les données stockées dans Redis peuvent être lues et écrites par des fonctions, et un coordinateur intégré facilite le traitement des données distribuées dans un cluster.

Dans les grandes lignes, ce diagramme décrit les composants de RedisGears :

image5 2
Architecture RedisGears et flux de données

RedisGears a trois composants principaux :

  1. Coordinateur Gears orchestre l’exécution distribuée de vos fonctions sur chaque partition de votre base de données.
  2. EngrenagesExécuteur planifie et déclenche l’exécution de vos fonctions. Les fonctions peuvent être déclenchées ad hoc, par de nouvelles entrées dans un flux ou par une notification d’espace de clés. Dans ce dernier, la fonction peut être exécuté de manière synchrone avec la notification. (Le GearsExecutor n’est pas visible dans le diagramme ci-dessus, mais impliqué par la section events/trigger.)
  3. EngrenagesMoteur est l’environnement d’exécution de RedisGears.

En plus de ces trois composants principaux, RedisGears inclut une API C rapide de bas niveau pour la programmabilité. Vous pouvez intégrer cette C-API via Python dès aujourd’hui, avec plus de langages en préparation.

RedisGears minimise le temps d’exécution et le flux de données entre les partitions en exécutant vos fonctions aussi près que possible de vos données. En plaçant votre moteur sans serveur en mémoire, là où se trouvent vos données Redis, il élimine les allers-retours chronophages nécessaires pour récupérer les données, accélérant ainsi le traitement des événements et des flux.

RedisGears vous permet “d’écrire une fois, de déployer n’importe où”. Vous pouvez écrire vos fonctions pour une base de données Redis autonome et les déployer en production sans avoir à adapter votre script pour une base de données en cluster.

La combinaison de données en temps réel avec un moteur sans serveur vous permet de traiter des données dans des structures de données et des modèles de données sans la surcharge de plusieurs clients et connecteurs de base de données. Cela simplifie votre architecture et réduit les coûts de déploiement.

Écriture derrière

La capacité à faire face à des pics soudains du nombre d’utilisateurs/demandes est quelque chose que les entreprises et organisations modernes doivent prendre en compte. Le trafic du Black Friday et du Cyber ​​Monday, par exemple, peut éclipser celui des jours ordinaires.

Le fait de ne pas planifier ces pics peut entraîner des performances médiocres, des temps d’arrêt inattendus et, en fin de compte, une perte de revenus. D’un autre côté, la mise à l’échelle excessive de votre solution à ces pics peut également s’avérer coûteuse. La clé est de trouver une solution rentable qui peut répondre à vos demandes et exigences.

Les bases de données relationnelles/sur disque traditionnelles sont souvent incapables de faire face à des augmentations significatives de la charge. C’est là que RedisGears entre en jeu. La capacité d’écriture différée de RedisGears repose sur Redis pour faire le gros du travail, en gérant de manière asynchrone les mises à jour, en allégeant la charge et en diminuant les pics sur la base de données principale. RedisGears garantit également que toutes les modifications sont écrites dans vos bases de données ou systèmes d’entrepôt de données existants, protégeant votre application contre les défaillances de la base de données et augmentant les performances de votre application à la vitesse de Redis. Cela simplifie considérablement la logique de votre application puisqu’elle n’a plus besoin de parler qu’à une seule base de données frontale, Redis. La capacité d’écriture différée est initialement fournie avec la prise en charge d’Oracle, MySQL, SQL, SQLite, Snowflake et Cassandra.

image7 1
RedisGears aide à aplanir la courbe de charge de votre base de données.

Implémentation en écriture différée

Le schéma ci-dessous affiche l’architecture de la capacité d’écriture différée de RedisGears :

image6 1
Mappage des structures de données Redis et des fonctions RedisGears à la capacité d’écriture différée.

Il fonctionne comme suit :

  1. Une opération d’écriture se produit sur une clé de hachage Redis.
  2. Cette écriture déclenche l’exécution d’un première fonction RedisGears qui enregistre de manière synchrone la modification dans un flux Redis.
  3. Lorsque et seulement lorsque l’événement est ajouté avec succès au flux, un accusé de réception est renvoyé au client.
  4. UN deuxième fonction RedisGears est exécuté de manière asynchrone en arrière-plan et regroupe les modifications dans la base de données cible. Cette fonction est déclenchée par les nouveaux messages dans le flux.

Ensemble, ces deux fonctions constituent ce que nous appelons une “recette” pour RedisGears. (Notez que la recette de l’écriture différée est regroupée dans le rgsync (RedisGears sync), ainsi que plusieurs autres recettes de synchronisation de base de données.)

Comme indiqué ci-dessus, la troisième étape ne se produit que lorsque l’événement a été ajouté avec succès au flux. Cela signifie que si quelque chose ne va pas après que le client a reçu l’accusé de réception de l’opération d’écriture, les mécanismes de réplication Redis, de basculement automatique et de persistance des données garantissent que l’événement de mise à jour ne sera pas perdu. Par défaut, la fonctionnalité d’écriture différée de RedisGears fournit la au moins une livraison propriété pour les écritures, ce qui signifie que les données seront écrites une fois sur la cible, mais éventuellement plus que cela en cas d’échec. Il est possible de configurer la fonction RedisGears pour fournir exactement une foise la sémantique de livraison si nécessaire, garantissant que toute opération d’écriture donnée n’est exécutée qu’une fois que les données se trouvent sur la base de données cible.

Améliorer les performances des applications avec l’écriture différée

Pour mettre en valeur les avantages de l’écriture différée, nous avons développé un demande de démonstration dans lequel nous avons ajouté des points de terminaison pour permettre deux scénarios :

  1. Le serveur d’applications écrit directement dans la base de données principale.
  2. L’application traite Redis comme une base de données frontale et RedisGears effectue l’écriture différée dans la base de données principale.

Dans cet exemple, nous avons utilisé MySQL comme base de données principale pour faciliter les tests et la reproduction.

image2 2
À quoi ressemble votre application avec et sans écriture différée.

Pour simuler des pics dans l’application, nous avons créé un test de pointe avec k6dans lequel nous simulons une courte rafale allant de 1 à 48 utilisateurs simultanés.

Pour vérifier comment le système global a géré le pic, nous avons suivi la charge HTTP et la latence obtenues sur l’application ainsi que les performances du système de base de données sous-jacent. Le graphique ci-dessous présente les deux scénarios : l’intervalle de gauche présente les résultats de la solution MySQL uniquement, tandis que l’intervalle de droite présente les résultats du scénario d’écriture différée avec RedisGears.

image4 2
Mesures de performance de la base de données et de l’application pour les deux scénarios.

Ce graphique affiche quelques résultats importants :

  1. Au niveau de l’application, le graphique des demandes d’application montre que nous sommes passés de servir jusqu’à 5 000 requêtes par seconde à traiter jusqu’à 4 fois plus de demandesavec le même matériel sous-jacent.
  2. Le graphique de la base de données indique une augmentation du nombre d’insertions/mises à jour de MySQL par seconde. En effet, l’écriture différée regroupe les mises à jour de la base de données principale en une seule requête (cela n’est possible que parce que dans ce scénario, l’application frontale est découplée de la base de données principale). C’est une situation gagnant-gagnant, puisque votre application HTTP n’a pas à attendre la fin de l’opération d’écriture dans la base de données, et vous pouvez également faites-en plus avec les ressources pour lesquelles vous avez initialement dimensionné votre base de données principale. en tirer le meilleur parti “gratuitement”.
  3. Comme prévu, et directement lié à la suppression de la synchronisation entre votre application rapide et votre base de données backend lente avec l’ajout de RedisGears, nous sommes passés de valeurs de latences d’application du 95e quantile de 32 millisecondes à des latences inférieures à 10 millisecondes. Au lieu d’attendre en moyenne 8 millisecondes pour une réponse d’application, cela ne prend que 2 millisecondes. Non seulement vos applications fonctionneront plus rapidement, mais, plus important encore, elles seront également plus stables et résilientes.

Démarrer avec RedisGears

Nous sommes vraiment enthousiasmés par RedisGears et l’écriture différée. Nous pensons que le cas d’utilisation en écriture différée n’est que le début des problèmes infinis que RedisGears peut résoudre.

Nous espérons que ce billet de blog vous a encouragé à essayer RedisGears. Veuillez vérifier s’il vous plait Redisgoreilles.io, qui contient des tonnes d’exemples et d’astuces pour commencer. Vous pouvez trouver plus de démos sympas ici :

Une nouvelle version de RedisInsight sera bientôt publiée et contiendra la prise en charge de RedisGears pour exécuter des fonctions et afficher les fonctions enregistrées dans RedisGears. Nous vous laissons avec un GIF rapide de ce à quoi vous pouvez vous attendre :

image1

Bon codage !

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

Redis à AWS re:Invent 2015

Redis à AWS re:Invent 2015

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *