View a markdown version of this page

Classificação por níveis de dados em ElastiCache - Amazônia ElastiCache

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 por níveis de dados em ElastiCache

ElastiCache para clusters Valkey ou Redis OSS que compõem um grupo de replicação e usam um tipo de nó da família r6gd, seus dados são classificados em camadas entre a memória e o armazenamento SSD (unidades de estado sólido) local. A classificação de dados em níveis fornece uma nova opção de performance de preço para workloads do Valkey ou Redis OSS ao utilizar unidades de estado sólido (SSDs) de menor custo em cada nó de cluster, além de armazenar dados na memória. Essa modalidade é 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 ElastiCache clusters com camadas de dados, ElastiCache monitora o último horário de acesso de cada item que ele armazena. Quando a memória disponível (DRAM) é totalmente consumida, ElastiCache usa um algoritmo usado menos recentemente (LRU) para mover automaticamente itens acessados com pouca frequência da memória para o SSD. Quando os dados no SSD são acessados posteriormente, eles são transferidos de volta para a memória de forma ElastiCache automática e assíncrona 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, presumindo valores de string de 500 bytes, você pode esperar uma média de mais 300 microssegundos de latência para solicitações de dados armazenados em SSD em comparação com solicitações de dados em memória.

Com o maior tamanho de nó de classificação de dados em níveis (cache.r6gd.16xlarge), você pode armazenar até 1 petabyte em um só cluster de 500 nós (500 TB ao usar 1 réplica de leitura). A hierarquização de dados é compatível com todos os comandos e estruturas de dados do Valkey ou Redis OSS suportados em. ElastiCache Para usar esse recurso, não é necessário promover alterações no lado do cliente.

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. 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.

Limitações

A classificação de dados em níveis tem as seguintes limitações:

  • Você só pode usar a classificação de dados em níveis em clusters que fazem parte de um grupo de replicação.

  • O tipo de nó que você usa deve ser da família r6gd.

  • Você deve usar um mecanismo que seja Valkey 7.2 ou posterior, ou um Redis OSS 6.2 ou posterior.

  • Você não pode restaurar um backup de um cluster r6gd para outro cluster, a menos que ele também use r6gd.

  • Você não pode exportar um backup para o Amazon S3 para clusters de classificação de dados em níveis.

  • Não há compatibilidade para migração online com clusters em execução no tipo de nó r6gd.

  • A escalabilidade entre clusters com a hierarquização de dados ativada e a hierarquização de dados desativada não é suportada. Para migrar dados de um ElastiCache cluster com a classificação de dados desativada para um cluster com a classificação de dados ativada, você pode restaurar um backup em um novo cluster com a classificação de dados ativada. Para obter mais informações, consulte Dimensionamento ElastiCache.

  • O ajuste de escala automático é aceito em clusters que usam classificação de dados em níveis para Valkey versão 7.2 e posteriores e Redis OSS versão 7.0.7 e posteriores. Para obter mais informações, consulte Auto Scaling de clusters Valkey e Redis OSS.

  • A divisão de dados em camadas só são compatíveis com as políticas volatile-lru, allkeys-lru, volatile-lfu, allkeys-lfu e noeviction.

  • A gravação sem bifurcação é compatível com o Valkey versão 7.2 e posteriores, e com o Redis OSS versão 7.0.7 e posteriores.

  • Itens maiores que 128 MiB não são movidos para o SSD.

  • A partir do Valkey 8.1 e versões posteriores, um item cujo tamanho de chave+valor seja menor que 40 bytes não será movido para o SSD.

  • A hierarquização de dados não é suportada com clusters com durabilidade ativada.

Preços

Os nós R6gd têm 4,8x mais capacidade total (memória + SSD) e podem ajudar você a obter mais de 60% de economia para execução com utilização máxima em comparação aos nós R6g (somente memória). Para obter mais informações, consulte Preços do ElastiCache .

Monitoramento

ElastiCache oferece métricas projetadas especificamente para monitorar os clusters de desempenho que usam a hierarquização de dados. Para monitorar a proporção de itens na DRAM em comparação com o SSD, é possível usar a métrica CurrItems em Métricas para Valkey e Redis OSS. Você pode calcular a porcentagem como: (CurrItems com Dimensão: Nível = Memória* 100)/(CurrItems sem filtro de dimensão).

Se a política de despejo configurada permitir, ElastiCache começará a despejar itens quando restar menos de 5% da memória disponível (DRAM). 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 é recomendável que você considere expandir para clusters habilitados para o modo cluster ou aumentar para clusters desativados no modo cluster quando menos de 5% da memória disponível (DRAM) permanece. Para obter mais informações sobre a escalabilidade, consulte Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado). Para obter mais informações sobre métricas para clusters do Valkey ou Redis OSS que usam a classificação de dados em níveis, consulte Métricas para o Valkey e Redis OSS.

Como usar a classificação de dados em níveis

Ao criar um cluster como parte de um grupo de replicação, você usa a classificação de dados em níveis selecionando um tipo de nó da família r6gd, p. ex., cache.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 Criação de um cluster do Valkey ou Redis OSS.

Ao criar um grupo de replicação usando o AWS CLI, você usa a hierarquização de dados selecionando um tipo de nó da família r6gd, como cache.r6gd.xlarge, e definindo o parâmetro. --data-tiering-enabled

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-enabled, a operação falhará.

Para 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

Para 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

Após executar essa operação, você verá uma resposta semelhante ao seguinte:

{ "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 } }

Como restaurar dados do backup para clusters com a classificação de dados em níveis ativada

Você pode restaurar um backup em um novo cluster com a hierarquização de dados ativada usando o (Console), (AWS CLI) ou (ElastiCache API). Ao criar um cluster usando tipos de nós na família r6gd, a classificação de dados em níveis é ativada.

Para restaurar um backup para um novo cluster com a classificação de dados em níveis ativada (console)
  1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em https://console.aws.amazon.com/elasticache/.

  2. No painel de navegação, escolha Backups.

  3. Na lista de backups, escolha a caixa à esquerda do nome do backup do qual você deseja restaurar.

  4. Escolha Restore.

  5. Preencha a caixa de diálogo Restore Cluster. Certifique-se de preencher todos os campos Obrigatórios e qualquer outro que você deseja alterar em relação aos padrões.

    1. Cluster ID (ID do cluster): obrigatório. O nome do novo cluster.

    2. Modo cluster habilitado (aumento de escala horizontalmente): escolha esta opção para um cluster do Valkey ou Redis OSS (modo cluster habilitado).

    3. Node Type (Tipo de nó) – Especifique cache.r6gd.xlarge ou qualquer outro tipo de nó da família r6gd.

    4. Número de fragmentos — Escolha o número de fragmentos que você deseja no novo cluster (API/CLI: grupos de nós).

    5. Replicas per Shard – Escolha o número de nós de réplica de leitura desejados em cada estilhaço.

    6. Slots and keyspaces (Slots e espaços de chaves): escolha como deseja que as chaves sejam distribuídas entre os fragmentos. Se você optar por especificar as distribuições de chaves, complete a tabela especificando os intervalos de chaves para cada estilhaço.

    7. Availability zone(s) – especifique como você deseja que as zonas de disponibilidade do cluster sejam selecionadas.

    8. Port – Somente altere esse valor se quiser que o novo cluster use uma porta diferente.

    9. Choose a VPC – Escolha a VPC na qual criar esse cluster.

    10. Parameter Group: escolha um grupo de parâmetros que reserve memória suficiente para a sobrecarga do Valkey ou Redis OSS para o tipo de nó selecionado.

  6. Quando estiver satisfeito com as configurações, escolha Create (Criar).

Para mais informações sobre como criar um cluster, consulte Criação de um cluster do Valkey ou Redis OSS.

Ao criar um grupo de replicação usando o AWS CLI, a hierarquização de dados é usada por padrão selecionando um tipo de nó da família r6gd, como cache.r6gd.xlarge, e definindo o parâmetro. --data-tiering-enabled

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-enabled, a operação falhará.

Para 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

Para 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

Após executar essa operação, você verá uma resposta semelhante ao seguinte:

{ "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 } }