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. # Mise à niveau des données Les clusters qui utilisent un type de nœud de la famille r6gd voient leurs données hiérarchisées entre la mémoire et le stockage SSD (Solid State Drive) local. La hiérarchisation des données offre une nouvelle option de rapport prix/performances pour les charges de travail Valkey et Redis OSS en utilisant des disques SSD (SSDs) à moindre coût dans chaque nœud du cluster, en plus du stockage des données en mémoire. Comme pour les autres types de nœuds, les données écrites sur les nœuds r6gd sont stockées de manière durable dans un journal des transactions multi-AZ. La hiérarchisation des données est parfaitement adaptée aux charges de travail qui accèdent régulièrement jusqu'à 20 % de leur jeu de données, et pour les applications qui peuvent tolérer une latence supplémentaire lors de l'accès aux données sur SSD. Sur les clusters avec hiérarchisation des données, MemoryDB surveille l'heure du dernier accès de chaque élément stocké. Lorsque la mémoire disponible (DRAM) est entièrement consommée, MemoryDB utilise un algorithme utilisé le moins récemment (LRU) pour déplacer automatiquement les éléments rarement consultés de la mémoire vers le SSD. Lorsque les données du SSD sont ultérieurement consultées, MemoryDB les replace automatiquement et de manière asynchrone 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 principe du moins récemment utilisé (LRU, Least Recently Used) régit le placement des valeurs en mémoire plutôt que 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 généralement vous attendre à 450 microsecondes de latence supplémentaires pour les demandes de lecture de données stockées sur un SSD par rapport aux demandes de lecture de données en mémoire. Avec la plus grande taille de nœud de hiérarchisation des données (db.r6gd.8xlarge), vous pouvez en stocker jusqu'à 500 TBs dans un seul cluster de 500 nœuds (250 To avec une réplique en lecture). Pour la hiérarchisation des données, MemoryDB réserve 19 % de la mémoire (DRAM) par nœud à des fins autres que les données. La hiérarchisation des données est compatible avec toutes les commandes et structures de données Valkey et Redis OSS prises en charge dans MemoryDB. Vous n’avez besoin d’aucune modification côté client pour utiliser cette fonction. **Topics** + [Bonnes pratiques](data-tiering-best-practices.md) + [Limites de hiérarchisation des données](data-tiering-prerequisites.md) + [Mise à niveau de tarification des données](data-tiering-pricing.md) + [Surveillance de la hiérarchisation des données](data-tiering-monitoring.md) + [Utilisation de la hiérarchisation des données](data-tiering-enabling.md) + [Restauration des données d'un instantané vers des clusters](data-tiering-enabling-snapshots.md) # Bonnes pratiques Nous recommandons les bonnes pratiques suivantes : + La hiérarchisation des données est parfaitement adaptée aux charges de travail qui accèdent régulièrement jusqu'à 20 % de leur jeu de données, et pour les applications qui peuvent tolérer une latence supplémentaire lors de l'accès aux données sur SSD. + Lors de l'utilisation de la capacité SSD disponible sur les nœuds hiérarchisés en fonction des données, nous recommandons que la taille de la valeur soit supérieure à celle de la clé. La taille de la valeur ne peut pas être supérieure à 128 Mo ; sinon, elle ne sera pas déplacée sur le disque. Lorsque des éléments sont déplacés entre DRAM et SSD, les clés restent toujours en mémoire et seules les valeurs sont déplacées vers le niveau SSD. # Limites de hiérarchisation des données La hiérarchisation des données présente les limitations suivantes : + 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-west-3`, `eu-central-1`, `ap-northeast-1`, `ap-southeast-1`, `ap-southeast-2`, `ap-south-1`, `ca-central-1` et `sa-east-1`. + Vous ne pouvez pas restaurer un instantané d'un cluster r6gd dans un autre cluster à moins que celui-ci n'utilise également r6gd. + Vous ne pouvez pas exporter un instantané vers Amazon S3 pour les clusters de hiérarchisation des données. + L’enregistrement sans fonction fork n’est pas prise en charge. + 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). + La hiérarchisation des données prend uniquement en charge les politiques de mémoire maximale `volatile-lru`, `allkeys-lru` et `noeviction`. + Les éléments de plus de 128 MiB ne sont pas déplacés vers le SSD. # Mise à niveau de tarification des données Les nœuds R6gd ont une capacité totale (mémoire\$1SSD) 5 fois supérieure et peuvent vous aider à réaliser des économies de stockage de plus de 60 % lorsqu'ils fonctionnent à une utilisation maximale par rapport aux nœuds R6g (mémoire uniquement). Pour plus d'informations, consultez la section Tarification de [MemoryDB.](https://aws.amazon.com/memorydb/pricing/) # Surveillance de la hiérarchisation des données MemoryDB propose des métriques conçues spécifiquement pour surveiller les clusters de performance qui utilisent la hiérarchisation des données. Pour surveiller le ratio entre les éléments en DRAM et en SSD, vous pouvez utiliser la `CurrItems` métrique à[Métriques pour MemoryDB](metrics.memorydb.md). Vous pouvez calculer le pourcentage comme suit :`(CurrItems with Dimension: Tier = Memory * 100) / (CurrItems with no dimension filter)`. Si la politique d'expulsion configurée le permet, MemoryDB 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é de prendre en compte les [Dimensionnement des clusters MemoryDB](scaling-cluster.md) cas où le pourcentage d'éléments en mémoire tombe en dessous de 5 %. Pour plus d'informations, voir *Métriques pour les clusters MemoryDB qui utilisent la hiérarchisation des données* à. [Métriques pour MemoryDB](metrics.memorydb.md) # Utilisation de la hiérarchisation des données ## Utilisation de la hiérarchisation des données à l'aide du AWS Management Console *Lorsque vous créez un cluster, vous utilisez la hiérarchisation des données en sélectionnant un type de nœud de la famille r6gd, tel que db.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 [Étape 2 : Créer un cluster](getting-started.md#getting-started.createcluster). ## Activation de la hiérarchisation des données à l'aide du AWS CLI Lorsque vous créez un cluster à 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 *db.r6gd.xlarge, et en définissant le paramètre*. `--data-tiering` 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`, l’opération échouera. Pour Linux, macOS ou Unix : ``` aws memorydb create-cluster \ --cluster-name my-cluster \ --node-type db.r6gd.xlarge \ --engine valkey \ --acl-name my-acl \ --subnet-group my-sg \ --data-tiering ``` Pour Windows : ``` aws memorydb create-cluster ^ --cluster-name my-cluster ^ --node-type db.r6gd.xlarge ^ --engine valkey ^ --acl-name my-acl ^ --subnet-group my-sg --data-tiering ``` Après avoir exécuté cette opération, une réponse similaire à ceci s’affiche : ``` { "Cluster": { "Name": "my-cluster", "Status": "creating", "NumberOfShards": 1, "AvailabilityMode": "MultiAZ", "ClusterEndpoint": { "Port": 6379 }, "NodeType": "db.r6gd.xlarge", "EngineVersion": "7.2", "EnginePatchVersion": "7.2.6", "Engine": "valkey" "ParameterGroupName": "default.memorydb-valkey7", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxxxxxxxxx:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "ACLName": "my-acl", "DataTiering":"true", "AutoMinorVersionUpgrade": true } } ``` # Restauration des données d'un instantané vers des clusters Vous pouvez restaurer un instantané sur un nouveau cluster avec la hiérarchisation des données activée à l'aide de la (console), (AWS CLI) ou (API MemoryDB). 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. ## Restauration des données d'un instantané vers des clusters avec la hiérarchisation des données activée (console) Pour restaurer un instantané sur un nouveau cluster avec la hiérarchisation des données activée (console), suivez les étapes décrites dans [Restauration à partir d'un instantané (console)](snapshots-restoring.md#snapshots-restoring-CON) Notez que pour activer la hiérarchisation des données, vous devez sélectionner un type de nœud de la famille r6gd. ## Restauration des données d'un instantané dans des clusters avec la hiérarchisation des données activée (AWS CLI) Lors de la création d'un cluster à 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 *db.r6gd.xlarge, et en définissant le paramètre*. `--data-tiering` 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`, l’opération échouera. Pour Linux, macOS ou Unix : ``` aws memorydb create-cluster \ --cluster-name my-cluster \ --node-type db.r6gd.xlarge \ --engine valkey --acl-name my-acl \ --subnet-group my-sg \ --data-tiering \ --snapshot-name my-snapshot ``` Pour Windows : ``` aws memorydb create-cluster ^ --cluster-name my-cluster ^ --node-type db.r6gd.xlarge ^ --engine valkey ^ --acl-name my-acl ^ --subnet-group my-sg ^ --data-tiering ^ --snapshot-name my-snapshot ``` Après avoir exécuté cette opération, une réponse similaire à ceci s’affiche : ``` { "Cluster": { "Name": "my-cluster", "Status": "creating", "NumberOfShards": 1, "AvailabilityMode": "MultiAZ", "ClusterEndpoint": { "Port": 6379 }, "NodeType": "db.r6gd.xlarge", "EngineVersion": "7.2", "EnginePatchVersion": "7.2.6", "Engine": "valkey" "ParameterGroupName": "default.memorydb-valkey7", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxxxxxxxxx:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "ACLName": "my-acl", "DataTiering": "true" } ```