Clusters cloud Redis avec partage d’expressions régulières

Clusters cloud Redis avec partage d’expressions régulières

Je suis ravi d’annoncer qu’aujourd’hui, nous avons rendu notre technologie de clustering encore plus utile avec la disponibilité publique de RegEx Sharding. Cette fonctionnalité vous permet de définir exactement comment Redis Cloud distribue les données entre les partitions d’une base de données, permettant ainsi à votre application de continuer à effectuer des opérations multi-clés avec des performances optimales sur d’énormes ensembles de données. Nos politiques de partage standard et nouvelles RegEx sont immédiatement disponibles pour tous nos abonnés Redis Cloud Pay-as-You-Go.

Qu’est-ce qu’un cluster Redis et pourquoi devriez-vous l’utiliser ?

Avant de plonger dans les détails de cette annonce, je voudrais d’abord passer en revue le “pourquoi” et le “quoi” d’un cluster Redis. Redis, le magasin de données le plus rapide disponible aujourd’hui, est une base de données NoSQL open source en mémoire. L’architecture de Redis est telle qu’un seul serveur Redis est lié par le matériel de l’hôte sur lequel il s’exécute, en particulier le processeur, la RAM et le réseau de ce serveur. Étant un processus (principalement) à un seul thread, Redis n’utilise qu’un seul des cœurs de processeur du serveur. Et comme il s’agit d’une base de données en mémoire, toutes les données gérées par un processus Redis doivent tenir dans la RAM du serveur sur lequel il s’exécute. Enfin, l’interface réseau du serveur exécutant Redis peut également devenir un goulot d’étranglement une fois saturée de trafic généré par Redis et l’application. Alors qu’un seul serveur Redis peut traiter des dizaines et des centaines de milliers d’opérations par secondeil y a des cas où les applications ont besoin de plus.

La mise à l’échelle d’un serveur Redis (verticalement) est possible, dans une certaine mesure. Bien sûr, vous pouvez ajouter plus de RAM à un serveur, remplacer le processeur par un modèle plus rapide et même utiliser un réseau plus large et plus rapide, mais en fin de compte, vous atteindrez la limite supérieure du matériel de n’importe quel serveur. C’est là que le clustering et le sharding peuvent vous aider en vous permettant d’utiliser plusieurs cœurs de processeur sur chaque serveur et au-delà.

Un cluster Redis est composé d’un ou plusieurs serveurs, chaque serveur exécutant un ou plusieurs processus Redis. Chaque processus gère une instance de base de données non partagée appelée partition. Les clés de la base de données en cluster sont mappées sur des emplacements de hachage, qui à leur tour sont mappés sur des partitions, de sorte que chaque partition gère un sous-ensemble mutuellement exclusif de l’espace de noms de la base de données. En un sens, les fragments sont les bases de données physiques et les emplacements de hachage sont une couche supplémentaire qui facilite les opérations administratives telles que le repartitionnement. En exécutant les fragments sur plusieurs serveurs, un cluster vous permet essentiellement d’utiliser plus de cœurs de processeur, plus de RAM et plus de ressources réseau pour gérer votre base de données.

Le clustering est une approche efficace pour mettre à l’échelle horizontalement votre base de données Redis, car il vous permet d’utiliser une configuration distribuée. Il offre un moyen efficace de répartir les besoins en mémoire, la charge de traitement et la bande passante dont votre base de données a besoin entre plusieurs serveurs. Il y a cependant un hic – parce que les clusters Redis sont implémentés avec des fragments sans partage, vous ne pouvez pas exécuter d’opérations multi-clés qui s’étendent sur plus d’un emplacement de hachage (par exemple ZUNIONSTORE sur plusieurs ensembles triés). Cela déclenchera une erreur. Afin d’exécuter des opérations atomiques sur plusieurs clés (c’est-à-dire des commandes uniques qui fonctionnent sur plusieurs clés, des blocs MULTI/EXEC et des scripts Lua), vous devez vous assurer que toutes les clés pertinentes sont mappées sur le même emplacement de hachage (plus de détails ci-dessous).

Prise en charge des clusters pour Redis

L’open source Redis v3 portera uniquement sur la prise en charge du clustering natif. Il y a quelques semaines, Salvatore Sanfilippo a publié la première version v3 de Release Candidate, et il devrait être prêt pour la production d’ici quelques mois. Une fois le cluster open source stabilisé, il fournira tous les outils nécessaires à quiconque pour configurer et exploiter un cluster Redis, et relever efficacement les défis d’évolutivité.

Il existe cependant d’autres clusters Redis en plus de l’implémentation open source. Au cours de la majeure partie des deux dernières années, chez Redis, nous avons exploité notre propre version développée indépendamment d’un cluster Redis pour fournir les fonctionnalités d’évolutivité de Redis Cloud. La technologie de clustering éprouvée en production de Redis vous permet de faire évoluer dynamiquement vos bases de données Redis bien au-delà des limites d’un seul serveur. Certains de nos clients utilisent le clustering pour gérer des ensembles de données à l’échelle du To, tandis que d’autres en dépendent pour maintenir un débit massif avec des latences inférieures à la milliseconde. Comme tout dans notre service, notre clustering est extrêmement simple à utiliser et ne nécessite aucun effort particulier. Une fois utilisé, il est transparent pour l’application et ne nécessite aucune modification de code ou bibliothèques clientes spécialisées – vous continuez simplement à travailler via un point de terminaison de base de données unique qui masque les complexités sous-jacentes de l’architecture.

Utilisation d’expressions régulières pour partitionner Redis

Les clusters Redis Cloud offrent le choix entre deux politiques de partitionnement : Standard et RegEx. La politique standard est conçue pour se comporter exactement comme la cluster Redis open source. En utilisant des balises de hachage dans votre nom de clé (c’est-à-dire les caractères ‘{‘ et ‘}’), vous pouvez spécifier précisément la partie du nom de la clé qui sera utilisée pour le hachage. Cette politique de partitionnement standard utilisera la sous-chaîne du nom de la clé entourée d’accolades pour mapper cette clé à un emplacement de hachage.

Bien que cette politique de partitionnement standard soit un outil puissant, nous l’avons portée au niveau supérieur en introduisant notre politique de partitionnement RegEx. Ce type de partitionnement vous permet de configurer un ensemble de règles d’expression régulière utilisées pour extraire la balise de hachage des noms des clés. Étant donné que vous pouvez utiliser plusieurs règles et que chaque règle est une expression régulière à part entière, cette politique de partitionnement personnalisée offre une grande flexibilité, vous permettant ainsi d’implémenter n’importe quelle logique de correspondance de modèle sur vos noms de clé pour extraire les balises de hachage. Vous pouvez intégrer une partie de votre logique métier directement dans la politique de partitionnement pour garantir une adaptation parfaite aux exigences de votre application.

Les politiques de partitionnement RegEx personnalisées sont particulièrement utiles lors de l’utilisation du clustering avec une application et un ensemble de données existants, car vous pouvez ignorer à la fois la migration des données et les modifications de code pour votre nouveau schéma de base de données implicite. Avec le partitionnement RegEx personnalisé, vous pouvez « apprendre » aux clusters Redis Cloud comment les noms de clé de votre ensemble de données sont construits et vous assurer que les clés qui doivent se trouver dans le même emplacement de hachage (pour les opérations multi-clés) sont correctement identifiées. Vous pouvez en savoir plus sur nos politiques de partage et comment les utiliser sur notre documentation.

Le clustering Redis est simple et amusant avec Redis Cloud. Nos bases de données peuvent être regroupées et mises à l’échelle pour s’adapter à la croissance du volume, du débit et du trafic de données d’un simple clic et sans aucune modification de votre application existante. Des questions? Retour d’information? E-mail ou tweeter moi – je suis très disponible 🙂

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

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

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