Sous le capot : architecture de base de données Flash Redis Enterprise

Sous le capot : architecture de base de données Flash Redis Enterprise

Pour de nombreuses applications interactives, la réactivité est essentielle pour des expériences engageantes et fluides. Cependant, la RAM est chère. Conserver une grande quantité de données avec Redis peut être coûteux. Compte tenu du coût de l’infrastructure, vous finissez par choisir entre les 2 options suivantes ;

#1: Payez une prime pour stocker des ensembles de données importants dans la RAM avec Redis OU
#2 : Limitez l’utilisation de la base de données Redis aux données les plus précieuses et augmentez Redis avec des bases de données relationnelles sur disque ou NoSQL.

Redis Enterprise Flash offre une meilleure option #3 : La technologie Redis Enterprise Flash combine RAM et flash pour stocker de grands ensembles de données dans Redis avec un coût par Go bien inférieur. Avec Redis Enterprise Flash, vous pouvez étendre la RAM sur des périphériques Flash tels que les disques SSD basés sur NVMe et SATA et conserver des ensembles de données plus volumineux dans Redis, le tout sans perdre l’avantage de performance de Redis.

Approfondissons l’architecture Redis Enterprise pour voir comment la combinaison de disques SSD basés sur flash fonctionne dans la pratique.

Présentation de l’architecture d’entreprise Redis

Commençons par un aperçu de Redis Enterprise avant d’explorer l’architecture Flash.

Un cluster Redis Enterprise est composé de nœuds identiques qui sont déployés dans un centre de données ou étendus sur des zones de disponibilité locales. L’architecture Redise est composée d’un chemin de gestion (représenté dans la couche bleue de la figure 1 ci-dessous) et d’un chemin d’accès aux données (représenté dans la couche rouge de la figure 1 ci-dessous).

– La Parcours de gestion est composé d’un proxy qui aide à mettre à l’échelle les connexions et d’un gestionnaire de cluster qui est responsable de l’orchestration du cluster et du placement des fragments de base de données, ainsi que de la détection et de l’atténuation des pannes.
– La Chemin d’accès aux données est composé de fragments Redis maître et esclave. Les clients effectuent des opérations de données sur le fragment maître. Les fragments maîtres maintiennent les fragments esclaves à l’aide de la réplication en mémoire.

image 5 1Figure 1
Nœuds Redis Enterprise, avec des tuiles bleues représentant le chemin de gestion et des tuiles rouges représentant le chemin d’accès aux données avec Redis comme fragments.

Haute disponibilité avec réplication : Redis Enterprise utilise la réplication en mémoire pour maintenir les réplicas maîtres et esclaves répartis sur les nœuds, les racks et les zones. Redis Enterprise est livré avec divers chiens de garde qui détectent et protègent contre de nombreux types de pannes. En cas de pannes de nœud, de réseau et de processus qui rendent le réplica maître inaccessible, Redis Enterprise promeut automatiquement le réplica esclave en réplica maître et redirige la connexion client de manière transparente vers le nouveau réplica maître.

Outre la réplication intra-cluster, Redis Enterprise dispose également d’une réplication intégrée basée sur le WAN pour les déploiements Redis dans plusieurs centres de données. Vous pouvez trouver des détails supplémentaires dans le références section.

Mise à l’échelle et performances avec partitionnement : Chaque cluster Redis Enterprise peut contenir plusieurs bases de données. Dans Redis, les bases de données représentent des données qui appartiennent à une seule application, locataire ou microservice. Redis Enterprise est conçu pour s’adapter à des centaines de bases de données par cluster afin de fournir des modèles multilocataires flexibles et efficaces.

Chaque base de données peut contenir quelques ou plusieurs fragments Redis. Le partage est transparent pour les applications Redis. Les fragments maîtres de la base de données traitent les opérations de données pour un sous-ensemble donné de clés. Le nombre de fragments par base de données est configurable et dépend des besoins de débit des applications. Les bases de données dans Redis Enterprise peuvent être repartitionnées en plusieurs fragments Redis pour adapter le débit tout en maintenant des latences inférieures à la milliseconde. Le repartitionnement est effectué sans temps d’arrêt.

Slide3

Figure 2
Redis Enterprise place les répliques maître (M) et esclave (S) dans des nœuds, des racks et des zones distincts et utilise la réplication en mémoire pour protéger les données contre les pannes.

Dans Redis Enterprise, chaque base de données dispose d’un quota de RAM. Le quota ne peut pas dépasser les limites de la RAM disponible sur le nœud. Cependant, avec Redis Enterprise Flash, la RAM est étendue au lecteur flash local (SATA, SSD NVMe, etc.). Le quota total de la base de données peut tirer parti à la fois de la RAM et du lecteur flash. L’administrateur peut choisir le ratio RAM vs Flash à l’aide de la diapositive illustrée à la figure 3. Ce ratio peut être mis à jour à tout moment de la durée de vie de la base de données sans temps d’arrêt.

Slide4

figure 3
Boîte de dialogue Créer une base de données dans Redis Enterprise Pack avec la vue de la configuration RAM et Flash.

Architecture Flash d’entreprise Redis

Avec Redis Enterprise Flash, vous obtenez une version améliorée de Redis sous forme de partition. Outre d’autres modifications, avec ce fragment, au lieu de stocker toutes les clés et données dans la RAM, les valeurs moins fréquemment consultées sont poussées à clignoter. Dans la figure 4, vous pouvez voir la RAM et le Flash combinés pour stocker les données sous la forme de 2 nuances de gris distinctes.

Slide5
Figure 4
Fragments Redis Enterprise Flash avec composants de processus, de mémoire et de stockage sur disque. Redis Enterprise Flash utilise à la fois la RAM et le Flash pour conserver les données. La RAM stocke toutes les clés et certaines valeurs. Au fur et à mesure que la RAM se remplit, les valeurs moins fréquemment utilisées sont déplacées vers la mémoire flash (SSD basés sur NVMe ou SATA).

Si les applications doivent accéder à une valeur qui est en flash, Redis Enterprise place automatiquement la valeur dans la RAM. Selon le matériel flash utilisé, les applications connaissent une latence légèrement plus élevée lorsqu’elles ramènent des valeurs dans la RAM à partir du flash. Cependant les accès ultérieurs à la même valeur sont rapides, une fois la valeur en RAM.

À l’aide de techniques de placement intelligentes, Redis Enterprise Flash s’adapte aux modifications de la charge de travail au fil du temps. Redis Enterprise Flash a une tâche en arrière-plan qui éjecte les valeurs moins fréquemment utilisées pour flasher afin d’adapter et de maintenir une bonne dose d’espace libre pour les nouvelles opérations entrantes.

Il est important de noter que même si les valeurs sont éjectées pour flasher, toutes les clés et métadonnées restent dans la RAM. Les clés sont généralement plus petites que les valeurs. De nombreuses commandes Redis nécessitent un accès aux clés sans nécessiter l’accès à la valeur. Le fait de conserver la liste complète des clés dans la RAM garantit que de nombreuses opérations peuvent être exécutées sans aucune pénalité de récupération de valeur à partir de la mémoire flash. Les services d’arrière-plan gérant l’expiration, garantissant l’unicité des clés dans la base de données sont des opérations fréquentes dans la base de données. Avec toutes les clés stockées dans la RAM, il est facile de vérifier si la clé existe déjà avant d’insérer la nouvelle clé ou d’effectuer des vérifications d’expiration.

Durabilité: Redis Enterprise Flash utilise un lecteur flash comme extension de RAM. Au démarrage de la base de données, Redis Enterprise Flash attend et s’assure que la RAM et le lecteur Flash sont complètement vides. Une fois le moteur démarré, la RAM+flash est peuplée à partir de la copie durable des données (disque ou autre réplique). Lorsque vous utilisez Redis Enterprise Flash, vous pouvez utiliser l’une des deux options de durabilité de Redis Enterprise :

Durabilité basée sur disque : Redis Enterprise conserve toujours une copie durable sur disque. Tout comme les systèmes basés sur disque, ce chemin d’E/S est placé sur un périphérique de stockage en réseau plus lent et plus durable. Les bases de données Redis fournissent des options réglables pour conserver cette copie durable. Vous pouvez en savoir plus sur les options de durabilité ici.
Durabilité basée sur la réplication : Redis Enterprise maintient également une réplique – un fragment esclave – pour la durabilité. La durabilité basée sur la réplication protège contre les pannes de nœud, de rack ou de zone et offre de meilleures performances d’écriture que les écritures de stockage en réseau. Cela signifie qu’en cas d’interruption non planifiée, il est probable que votre réplique soit plus à jour que votre copie durable sur disque. Pour tirer pleinement parti de la durabilité répliquée, Redis fournit la commande WAIT. WAIT garantit qu’une écriture peut attendre un accusé de réception jusqu’à ce que plusieurs répliques confirment cette écriture. Cela garantit qu’une écriture confirmée avec WAIT sur les répliques sera durable même si un nœud prend feu et ne revient jamais au cluster.

“Cache tampon” contre l’approche “Extension RAM”

Le placement intelligent des données dans Redis Enterprise Flash, qui transfère les valeurs de la mémoire flash dans la RAM en fonction de l’ensemble de travail, est similaire aux systèmes de base de données sur disque et au “cache miss” sur le cache tampon de la base de données. Cependant, les similitudes entre les bases de données sur disque et la méthode d’extension de RAM utilisée dans Redis Enterprise Flash s’arrêtent là. Les modèles d’E/S utilisés dans Redis Enterprise Flash sont beaucoup plus efficaces que ceux d’un système basé sur disque. Voici quelques-unes des différences entre les deux :

Gestion des valeurs chaudes : De nombreuses charges de travail d’application effectuent des écritures répétées sur un ensemble de touches « actives » sur une courte période, par exemple lorsque les clés appartiennent à une donnée active. Par exemple, imaginez des mises à jour répétées par une application de sa base de données, suivant l’état actuel d’un acheteur sur un site au fur et à mesure que l’acheteur consulte divers produits. Les bases de données sur disque effectuent ces écritures à la fois dans la RAM et sur le disque pour conserver les modifications à chaque fois. Cependant, les mises à jour des données dans la RAM ne sont pas envoyées au flash dans Redis Enterprise Flash. L’approche d’extension de RAM utilisée par Redis Enterprise Flash ne nécessite aucune écriture pour flasher sous des écritures répétées sur des touches “hot”, à moins que la valeur ne soit éjectée pour flasher. N’oubliez pas que les valeurs actives ne sont pas éjectées pour flasher et restent principalement dans la RAM, de sorte que les mises à jour répétées des clés de l’acheteur actif se produisent simplement dans la RAM et ne nécessitent pas d’écritures flash. Cela garantit que la bande passante E/S du lecteur Flash est uniquement utilisée pour les éjections vers Flash.
Exploitation du stockage éphémère : L’architecture cloud dans les clouds publics ou privés comprend généralement deux types de stockage, un stockage éphémère plus rapide et un stockage en réseau durable plus lent. Les bases de données sur disque exigent que leurs écritures persistent jusqu’au disque pour chaque écriture. Ainsi, vous devez utiliser le stockage en réseau persistant. Cependant, Redis Enterprise Flash traite la mémoire flash comme une extension de RAM, ce qui lui permet de tirer pleinement parti du stockage éphémère local et rapide.
Amplification d’écriture : Les bases de données sur disque dépendent des écritures sur disque pour leur durabilité. Chaque écriture sur disque dans les bases de données sur disque est généralement effectuée via un redo-log (RL) ou un write-ahead-log (WAL) avant que les valeurs réelles ne soient mises à jour sur le stockage. Redis Enterprise Flash utilise RocksDB pour gérer l’accès au lecteur flash. La séquence d’appel à RocksDB avec Redis Enterprise Flash n’a pas besoin de maintenir ces WAL supplémentaires. L’amplification d’écriture mesure le nombre d’opérations d’E/S qu’une seule lecture/écriture provoque. En raison des écritures consignées, les bases de données sur disque se retrouvent avec une amplification d’écriture beaucoup plus élevée. Vous pouvez en savoir plus sur RocksDB et divers effets d’amplification IO ici.
Avancées du matériel avec la mémoire persistante : Les techniques utilisées pour créer Redis Enterprise Flash sont basées sur la nouvelle direction de la technologie de la mémoire. Au fur et à mesure que la mémoire persistante est introduite dans l’architecture de calcul, telle que 3DXPoint d’Intel, l’idée derrière ces technologies est de permettre à l’application de décider quelle partie des données sera conservée en RAM et laquelle utilisera Flash/Nand afin de maximiser les performances au meilleur coût. Redis Enterprise Flash a été conçu pour exploiter ces avantages.

Commencez et essayez Redis Enterprise Flash !

Il est facile de démarrer avec Redis Enterprise Flash avec Docker sur une machine Windows, Linux ou Mac. Vous pouvez trouver les étapes ici : Démarrage rapide de Redis Enterprise Flash.

Références

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 *