Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Hiérarchisation des données ElastiCache
ElastiCache avec des OSS clusters Valkey ou Redis comprenant un groupe de réplication et utilisant un type de nœud de la famille r6gd, leurs données sont hiérarchisées entre la mémoire et le stockage local SSD (disques SSD). La hiérarchisation des données offre une nouvelle option de rapport prix/performances pour les OSS charges de travail Valkey ou Redis en utilisant des disques SSD (SSDs) moins coûteux dans chaque nœud du cluster, en plus du stockage des données en mémoire. Il est idéal pour les charges de travail qui accèdent régulièrement à 20 % de leur ensemble de données global, ainsi que pour les applications qui peuvent tolérer une latence supplémentaire lors de l'accès aux données surSSD.
Sur les ElastiCache clusters dotés de la hiérarchisation des données, ElastiCache surveille l'heure du dernier accès à chaque élément stocké. Lorsque la mémoire disponible (DRAM) est entièrement consommée, ElastiCache utilise un algorithme utilisé le moins récemment (LRU) pour déplacer automatiquement les éléments rarement consultés de la mémoire vers. SSD Lorsque des données SSD sont ultérieurement consultées, elles sont ElastiCache automatiquement et asynchrones remises en mémoire avant de traiter la demande. Si votre charge de travail n’accède régulièrement qu’à un sous-ensemble de ses données, la hiérarchisation des données est un moyen optimal de mettre à l’échelle votre capacité de manière rentable.
Notez que lors de l'utilisation de la hiérarchisation des données, les clés elles-mêmes restent toujours en mémoire, tandis que le placement des valeurs sur la mémoire ou sur le LRU disque est régi par rapport au placement des valeurs sur le disque. En général, nous recommandons que la taille de vos clés soit inférieure à celle de vos valeurs lorsque vous utilisez la hiérarchisation des données.
La hiérarchisation des données est conçue pour avoir un impact minimal sur les performances des charges de travail des applications. Par exemple, en supposant des valeurs de chaîne de 500 octets, vous pouvez vous attendre à une latence supplémentaire de 300 microsecondes en moyenne pour les demandes de données stockées SSD par rapport aux demandes de données en mémoire.
Grâce à la plus grande taille de nœud de hiérarchisation des données (cache.r6gd.16xlarge), vous pouvez stocker jusqu’à 1 pétaoctet dans un seul cluster de 500 nœuds (500 To en utilisant 1 réplica en lecture). La hiérarchisation des données est compatible avec toutes les OSS commandes et structures de données Valkey ou Redis prises en charge dans. ElastiCache Vous n’avez besoin d’aucune modification côté client pour utiliser cette fonction.
Rubriques
Bonnes pratiques
Nous recommandons les bonnes pratiques suivantes :
La hiérarchisation des données est idéale pour les charges de travail qui accèdent régulièrement à 20 % de leur ensemble de données global, ainsi que pour les applications qui peuvent tolérer une latence supplémentaire lors de l'accès aux données sur. SSD
Lorsque vous utilisez SSD la capacité disponible sur des nœuds hiérarchisés par données, nous recommandons que la taille de la valeur soit supérieure à la taille de la clé. Lorsque des éléments sont déplacés entre DRAM etSSD, les clés restent toujours en mémoire et seules les valeurs sont déplacées vers le SSD niveau.
Limites
La hiérarchisation des données présente les limitations suivantes :
Vous ne pouvez utiliser la hiérarchisation des données que sur des clusters faisant partie d’un groupe de réplication.
Le type de nœud que vous utilisez doit appartenir à la famille r6gd, disponible dans les régions suivantes :
us-east-2
,us-east-1
,us-west-2
,us-west-1
,eu-west-1
,eu-central-1
,eu-north-1
,eu-west-3
,ap-northeast-1
,ap-southeast-1
,ap-southeast-2
,ap-south-1
,ca-central-1
etsa-east-1
.Vous devez utiliser un moteur Valkey 7.2 ou version ultérieure, ou un moteur Redis OSS 6.2 ou version ultérieure.
Vous ne pouvez pas restaurer une sauvegarde d’un cluster r6gd dans un autre cluster sauf s’il utilise également r6gd.
Vous ne pouvez pas exporter une sauvegarde vers Amazon S3 pour les clusters de hiérarchisation des données.
La migration en ligne n'est pas prise en charge pour les clusters exécutés sur le type de nœud r6gd.
La mise à l’échelle n’est pas prise en charge depuis un cluster de hiérarchisation de données (par exemple, un cluster utilisant un type de nœud r6gd) vers un cluster qui n’utilise pas la hiérarchisation des données (par exemple, un cluster utilisant un type de nœud r6g). Pour de plus amples informations, veuillez consulter Dimensionnement ElastiCache.
Le dimensionnement automatique est pris en charge sur les clusters utilisant la hiérarchisation des données pour Valkey version 7.2 et versions ultérieures, et Redis OSS version 7.0.7 et versions ultérieures. Pour plus d’informations, consultez Clusters Auto Scaling Valkey et Redis OSS.
La hiérarchisation des données prend uniquement en charge les politiques maxmemory
volatile-lru
,allkeys-lru
,volatile-lfu
,allkeys-lfu
etnoeviction
.La sauvegarde sans formulaire est prise en charge pour Valkey version 7.2 et versions ultérieures, ainsi que pour Redis OSS version 7.0.7 et versions ultérieures. Pour de plus amples informations, veuillez consulter Implémentation de la sauvegarde et de la synchronisation.
Les éléments supérieurs à 128 MiB ne sont pas déplacés vers. SSD
Tarification
Les nœuds R6gd ont une capacité totale 4,8 fois supérieure (mémoire +SSD) et peuvent vous aider à réaliser des économies de plus de 60 % en cas d'utilisation maximale par rapport aux nœuds R6g (mémoire uniquement). Pour plus d'informations, consultez ElastiCache les tarifs
Surveillance
ElastiCache propose des métriques conçues spécifiquement pour surveiller les clusters de performances qui utilisent la hiérarchisation des données. Pour surveiller le ratio d'articles DRAM par rapport àSSD, vous pouvez utiliser la CurrItems
métrique de Metrics for Valkey et Redis OSS. Vous pouvez calculer le pourcentage comme suit : (CurrItems avec Dimension : Tier = Memory * 100)/(CurrItems sans filtre de dimension).
Si la politique d'expulsion configurée le permet, elle ElastiCache commencera à expulser des éléments lorsque le pourcentage d'éléments en mémoire sera inférieur à 5 %. Sur les nœuds configurés avec une politique de non-éviction, les opérations d'écriture recevront une erreur de mémoire insuffisante.
Il est tout de même recommandé d'envisager une mise à l'échelle horizontale pour les clusters activés en mode cluster ou une mise à l'échelle supérieure pour les clusters désactivés en mode cluster lorsque le pourcentage d'éléments en mémoire tombe en dessous de 5 %. Pour plus d'informations sur le dimensionnement, voirMise à l'échelle des clusters dans Valkey ou Redis OSS (mode cluster activé). Pour plus d'informations sur les métriques pour les OSS clusters Valkey ou Redis qui utilisent la hiérarchisation des données, consultez. Métriques pour Valkey et Redis OSS
Utilisation de la hiérarchisation des données
Lorsque vous créez un cluster dans le cadre d’un groupe de réplication, vous utilisez la hiérarchisation des données en sélectionnant un type de nœud dans la famille r6gd, tel que cache.r6gd.xlarge. La sélection de ce type de nœud active automatiquement la hiérarchisation des données.
Pour plus d'informations sur la création des clusters , consultez Création d'un cluster pour Valkey ou Redis OSS.
Lorsque vous créez un groupe de réplication à l'aide de AWS CLI, vous utilisez la hiérarchisation des données en sélectionnant un type de nœud de la famille r6gd, tel que cache.r6gd.xlarge, et en définissant le paramètre. --data-tiering-enabled
Vous ne pouvez pas désactiver la hiérarchisation des données lorsque vous sélectionnez un type de nœud dans la famille r6gd. Si vous définissez le paramètre --no-data-tiering-enabled
, l’opération échouera.
Pour Linux, macOS ou Unix :
aws elasticache create-replication-group \ --replication-group-id redis-dt-cluster \ --replication-group-description "Redis OSS cluster with data tiering" \ --num-node-groups 1 \ --replicas-per-node-group 1 \ --cache-node-type cache.r6gd.xlarge \ --engine redis \ --cache-subnet-group-name default \ --automatic-failover-enabled \ --data-tiering-enabled
Pour Windows :
aws elasticache create-replication-group ^ --replication-group-id redis-dt-cluster ^ --replication-group-description "Redis OSS cluster with data tiering" ^ --num-node-groups 1 ^ --replicas-per-node-group 1 ^ --cache-node-type cache.r6gd.xlarge ^ --engine redis ^ --cache-subnet-group-name default ^ --automatic-failover-enabled ^ --data-tiering-enabled
Après avoir exécuté cette opération, une réponse similaire à ceci s’affiche :
{ "ReplicationGroup": { "ReplicationGroupId": "redis-dt-cluster", "Description": "Redis OSS cluster with data tiering", "Status": "creating", "PendingModifiedValues": {}, "MemberClusters": [ "redis-dt-cluster" ], "AutomaticFailover": "enabled", "DataTiering": "enabled", "SnapshotRetentionLimit": 0, "SnapshotWindow": "06:00-07:00", "ClusterEnabled": false, "CacheNodeType": "cache.r6gd.xlarge", "TransitEncryptionEnabled": false, "AtRestEncryptionEnabled": false } }
Restauration des données de la sauvegarde dans des clusters avec la hiérarchisation des données activée
Vous pouvez restaurer une sauvegarde sur un nouveau cluster avec la hiérarchisation des données activée à l'aide de la (console), (AWS CLI) ou (ElastiCache API). Lorsque vous créez un cluster à l’aide de types de nœuds de la famille r6gd, la hiérarchisation des données est activée.
Pour restaurer une sauvegarde dans un nouveau cluster avec la hiérarchisation des données activée (console)
-
Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/elasticache/
. -
Dans le volet de navigation de gauche, choisissez Sauvegardes.
-
Dans la liste des sauvegardes, cochez la case située à gauche du nom de la sauvegarde à restaurer.
-
Choisissez Restore (Restaurer).
-
Renseignez la boîte de dialogue Restore Cluster. Veillez à remplir tous les champs obligatoires, ainsi que ceux dont vous ne souhaitez pas conserver la valeur par défaut.
-
ID du cluster : obligatoire. Nom du nouveau cluster.
-
Mode cluster activé (mise à l'échelle) : choisissez cette option pour un cluster Valkey ou Redis OSS (mode cluster activé).
-
Type de nœud : préciser cache.r6gd.xlarge ou tout autre type de nœud de la famille r6gd.
-
Nombre de partitions : choisissez le nombre de partitions que vous souhaitez dans le nouveau cluster (API/CLI: groupes de nœuds).
-
Replicas per Shard (Réplicas par partition) : choisissez le nombre de nœuds de réplica en lecture souhaité dans chaque partition.
-
Slots and keyspaces (Emplacements et espaces de clés) : choisissez la répartition des clés entre les partitions. Si vous choisissez de spécifier les répartitions de clés, remplissez le tableau en spécifiant les plages de clés de chaque partition.
-
Zone(s) de disponibilité : spécifiez la façon dont les zones de disponibilité du cluster doivent être sélectionnées.
-
Port : modifiez cette valeur uniquement si vous souhaitez que le nouveau cluster utilise un port différent.
-
Choisissez un VPC — Choisissez le cluster VPC dans lequel vous souhaitez créer ce cluster.
-
Groupe de paramètres : choisissez un groupe de paramètres qui réserve suffisamment de mémoire pour la OSS surcharge de Valkey ou Redis pour le type de nœud que vous avez sélectionné.
-
-
Lorsque les paramètres vous conviennent, choisissez Create.
Pour plus d'informations sur la création des clusters , consultez Création d'un cluster pour Valkey ou Redis OSS.
Lors de la création d'un groupe de réplication à l'aide de AWS CLI, la hiérarchisation des données est utilisée par défaut en sélectionnant un type de nœud de la famille r6gd, tel que cache.r6gd.xlarge, et en définissant le paramètre. --data-tiering-enabled
Vous ne pouvez pas désactiver la hiérarchisation des données lorsque vous sélectionnez un type de nœud dans la famille r6gd. Si vous définissez le paramètre --no-data-tiering-enabled
, l’opération échouera.
Pour Linux, macOS ou Unix :
aws elasticache create-replication-group \ --replication-group-id redis-dt-cluster \ --replication-group-description "Redis OSS cluster with data tiering" \ --num-node-groups 1 \ --replicas-per-node-group 1 \ --cache-node-type cache.r6gd.xlarge \ --engine redis \ --cache-subnet-group-name default \ --automatic-failover-enabled \ --data-tiering-enabled \ --snapshot-name
my-snapshot
Pour Linux, macOS ou Unix :
aws elasticache create-replication-group ^ --replication-group-id redis-dt-cluster ^ --replication-group-description "Redis OSS cluster with data tiering" ^ --num-node-groups 1 ^ --replicas-per-node-group 1 ^ --cache-node-type cache.r6gd.xlarge ^ --engine redis ^ --cache-subnet-group-name default ^ --automatic-failover-enabled ^ --data-tiering-enabled ^ --snapshot-name
my-snapshot
Après avoir exécuté cette opération, une réponse similaire à ceci s’affiche :
{ "ReplicationGroup": { "ReplicationGroupId": "redis-dt-cluster", "Description": "Redis OSS cluster with data tiering", "Status": "creating", "PendingModifiedValues": {}, "MemberClusters": [ "redis-dt-cluster" ], "AutomaticFailover": "enabled", "DataTiering": "enabled", "SnapshotRetentionLimit": 0, "SnapshotWindow": "06:00-07:00", "ClusterEnabled": false, "CacheNodeType": "cache.r6gd.xlarge", "TransitEncryptionEnabled": false, "AtRestEncryptionEnabled": false } }