As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Classificação de dados em níveis Os clusters que usam um tipo de nó da família r6gd têm seus dados classificados em níveis entre a memória e o armazenamento local em unidades de estado sólido (Solid state Drives, SSD). A classificação de dados em níveis fornece uma nova opção de relação entre preço e desempenho para workloads do Valkey e Redis OSS, utilizando unidades de estado sólido (SSDs) de menor custo em cada nó de cluster, além do armazenamento de dados na memória. Semelhante a outros tipos de nós, os dados gravados nos nós r6gd são armazenados de forma durável em um log de transações Multi-AZ. A classificação de dados em níveis é ideal para workloads que acessam regularmente até 20% do conjunto de dados geral e para aplicações que podem tolerar latência adicional ao acessar dados em SSD. Em clusters com classificação de dados em níveis, o MemoryDB monitora o último horário de acesso de cada item armazenado. Quando a memória disponível (DRAM) é totalmente consumida, o MemoryDB usa um algoritmo usado menos recentemente (Least-Recently Used, LRU) para mover automaticamente da memória para o SSD os itens acessados com pouca frequência. Quando os dados em SSD são acessados posteriormente, o MemoryDB os move de modo automático e assíncrono de volta para a memória antes de processar a solicitação. Se você tiver uma workload que acessa regularmente apenas um subconjunto de dados, a classificação de dados em níveis é uma maneira ideal de dimensionar sua capacidade de modo econômico. Observe que, ao usar a classificação por níveis, as próprias chaves sempre permanecem na memória, enquanto a LRU controla a colocação de valores na memória versus disco. Em geral, recomendamos que seus tamanhos de chave sejam menores do que seus tamanhos de valor ao usar a classificação por níveis de dados. A classificação de dados em níveis foi projetada para causar impacto mínimo na performance das workload da aplicação. Por exemplo, supondo valores de string de 500 bytes, você pode esperar um adicional de 450 microssegundos de latência para solicitações de leitura de dados armazenados em SSD em comparação com solicitações de leitura de dados na memória. Com o maior tamanho de nó de classificação de dados (db.r6gd.8xlarge), é possível armazenar até mais ou menos 500 TB em um único cluster de 500 nós (250 TB ao usar 1 réplica de leitura). Para a classificação de dados em níveis, o MemoryDB reserva 19% da memória (DRAM) por nó para uso não relacionado a dados. A classificação de dados em níveis é compatível com todos os comandos e estruturas de dados do Valkey e Redis OSS compatíveis com o MemoryDB. Para usar esse recurso, não é necessário promover alterações no lado do cliente. **Topics** + [Práticas recomendadas](data-tiering-best-practices.md) + [Limites para a classificação de dados em níveis](data-tiering-prerequisites.md) + [Preços para a classificação de dados em níveis](data-tiering-pricing.md) + [Monitoramento de dados em níveis](data-tiering-monitoring.md) + [Como usar a classificação de dados em níveis](data-tiering-enabling.md) + [Restaurar dados de um snapshot em clusters](data-tiering-enabling-snapshots.md) # Práticas recomendadas Recomendamos seguir estas práticas recomendadas: + A classificação de dados em níveis é ideal para workloads que acessam regularmente até 20% do conjunto de dados geral e para aplicações que podem tolerar latência adicional ao acessar dados em SSD. + Ao usar a capacidade SSD disponível em nós em níveis de dados, recomendamos que o tamanho do valor seja maior do que o tamanho da chave. O tamanho do valor não pode ser maior que 128 MB, caso contrário, não será movido para o disco. Quando os itens são movidos entre DRAM e SSD, as chaves sempre permanecerão na memória e somente os valores serão movidos para a camada SSD. # Limites para a classificação de dados em níveis A classificação de dados em níveis tem as seguintes limitações: + O tipo de nó usado deve ser da família r6gd, que está disponível nas seguintes regiões: `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` e `sa-east-1`. + Não é possível restaurar um snapshot de um cluster r6gd em outro cluster, a menos que ele também use r6gd. + Não é possível exportar um snapshot para o Amazon S3 para clusters de classificação de dados em níveis. + Não há compatibilidade com salvamento sem bifurcação. + Não há compatibilidade com escalabilidade de um cluster de classificação de dados em níveis (p. ex., um cluster que use um tipo de nó r6gd) para um cluster sem classificação de dados em níveis (p. ex., um cluster que use um tipo de nó r6g). + A classificação de dados em níveis só é compatível com as políticas maxmemory `volatile-lru`, `allkeys-lru` e `noeviction`. + Itens maiores que 128 MiB não são movidos para o SSD. # Preços para a classificação de dados em níveis Os nós R6gd têm 5 vezes mais capacidade total (memória \$1 SSD) e podem ajudá-lo a obter mais de 60% de economia de custos de armazenamento ao serem executados na utilização máxima em comparação com os nós R6g (somente memória). Para obter mais informações, consulte [Preços do MemoryDB](https://aws.amazon.com/memorydb/pricing/). # Monitoramento de dados em níveis O MemoryDB oferece métricas especificamente projetadas para monitorar os clusters de desempenho que usam a classificação de dados em níveis. Para monitorar a proporção de itens na DRAM em comparação com o SSD, é possível usar a métrica de `CurrItems` em [Métricas para MemoryDB](metrics.memorydb.md). Você pode calcular a porcentagem como: `(CurrItems with Dimension: Tier = Memory * 100) / (CurrItems with no dimension filter)`. Se a política de remoção configurada permitir, o MemoryDB começará a remover itens quando a porcentagem de itens na memória cair abaixo de 5%. Nos nós configurados com a política de não remoção, as operações de gravação receberão um erro de falta de memória. Ainda é recomendado que você considere [Escalabilidade de clusters do MemoryDB](scaling-cluster.md) quando a percentagem de itens na memória cair abaixo de 5%. Para obter mais informações, consulte *Métricas para clusters do MemoryDB que usam classificação de dados em níveis* em [Métricas para MemoryDB](metrics.memorydb.md). # Como usar a classificação de dados em níveis ## Como usar a classificação de dados em níveis usando o Console de gerenciamento da AWS Ao criar um cluster, você usa a classificação de dados em níveis selecionando um tipo de nó da família r6gd, como o *db.r6gd.xlarge*. A seleção desse tipo de nó ativa automaticamente a classificação de dados em níveis. Para mais informações sobre como criar um cluster, consulte [Etapa 2: criar um cluster](getting-started.md#getting-started.createcluster). ## Como habilitar a classificação de dados em níveis usando a AWS CLI Ao criar um cluster usando o AWS CLI, você usa a classificação de dados em níveis selecionando um tipo de nó da família r6gd, como *db.r6gd.xlarge*, e configurando o parâmetro `--data-tiering`. Você não pode optar por não usar a classificação de dados em níveis ao selecionar um tipo de nó da família r6gd. Se você configurar o parâmetro `--no-data-tiering`, a operação falhará. Para 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 ``` Para 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 ``` Após executar essa operação, você verá uma resposta semelhante ao seguinte: ``` { "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 } } ``` # Restaurar dados de um snapshot em clusters Você pode restaurar um snapshot em um novo cluster com a classificação de dados em níveis ativada usando o (Console), a (CLI da AWS) ou a (API do MemoryDB). Ao criar um cluster usando tipos de nós na família r6gd, a classificação de dados em níveis é ativada. ## Restauração de dados do snapshot para clusters com a classificação de dados em níveis ativada (console) Restaurar um snapshot para um novo cluster com a classificação de dados em níveis ativada (console), siga as etapas em [Restauração a partir de um snapshot (Console)](snapshots-restoring.md#snapshots-restoring-CON) Observe que, para ativar a classificação de dados em níveis, você precisa selecionar um tipo de nó da família r6gd. ## Restauração de dados do snapshot para clusters com a classificação de dados em níveis ativada (CLI da AWS) Ao criar um cluster usando a AWS CLI, a classificação de dados em níveis é usada por padrão ao selecionar um tipo de nó da família r6gd, por exemplo, o *db.r6gd.xlarge*, e configurando o parâmetro `--data-tiering`. Você não pode optar por não usar a classificação de dados em níveis ao selecionar um tipo de nó da família r6gd. Se você configurar o parâmetro `--no-data-tiering`, a operação falhará. Para 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 ``` Para 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 ``` Após executar essa operação, você verá uma resposta semelhante ao seguinte: ``` { "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" } ```