Configurar um cluster do DAX
O cluster do DAX é um cluster gerenciado, mas você pode ajustar as configurações para atender aos requisitos da sua aplicação. Devido à estreita integração com as operações de API do DynamoDB, você deve considerar os seguintes aspectos ao integrar sua aplicação ao DAX.
Nesta seção
Preços do DAX
O custo de um cluster depende da quantidade e do tamanho dos nós provisionados. Cada nó é cobrado por hora de execução no cluster. Para obter mais informações, consulte a Definição de preço do Amazon DynamoDB
Os acertos de cache não geram custos do DynamoDB, mas afetam os recursos do cluster do DAX. As perdas no cache geram custos de leitura do DynamoDB e exigem recursos do DAX. As gravações geram custos de gravação do DynamoDB e afetam os recursos do cluster do DAX para proxy da gravação.
Cache de itens e cache de consultas
O DAX mantém um cache de itens e um cache de consultas. Compreender as diferenças entre esses caches pode ajudar você a determinar as características de desempenho e consistência que eles oferecem à sua aplicação.
| Cache de itens | Cache de consultas |
|---|---|
| Purpose | |
|
Armazena os resultados das operações de API GetItem e BatchGetItem. |
Armazena os resultados das operações de API Query e Scan. Essas operações podem retornar vários itens com base nas condições da consulta, em vez de chaves de item específicas. |
| Access type | |
|
Utiliza acesso baseado em chave. Quando uma aplicação solicita dados usando |
Utiliza acesso baseado em parâmetro. O DAX armazena em cache o conjunto de resultados das operações de API |
| Cache invalidation | |
|
O DAX replica automaticamente os itens atualizados no cache de itens dos nós no cluster do DAX nos seguintes cenários:
|
É mais difícil invalidar o cache de consultas do que o cache de itens. As atualizações de itens podem não ser mapeadas diretamente para consultas ou verificações armazenadas em cache. É necessário ajustar cuidadosamente a TTL do cache de consultas para manter a consistência de dados. As gravações por meio do DAX ou da tabela base não são refletidas no cache de consultas até que a TTL expire a resposta anteriormente armazenada em cache e o DAX realize uma nova consulta no DynamoDB. |
| Global secondary index | |
Because the GetItem API operation isn't supported on local secondary indexes or global secondary indexes, the item cache only caches reads from the base table. |
Query cache caches queries against both tables and indexes. |
Selecionar a configuração de TTL para os caches
A TTL determina o período em que os dados são armazenados no cache antes de ficarem obsoletos. Após esse período, os dados são atualizados automaticamente na próxima solicitação. Escolher a configuração de TTL correta para seus caches do DAX envolve o equilíbrio entre a otimização do desempenho da aplicação e a consistência dos dados. Como não existe uma configuração de TTL universal que funcione para todas as aplicações, a configuração ideal de TTL varia de acordo com as características e os requisitos específicos da aplicação. Recomendamos que você comece com uma configuração de TTL conservadora, usando estas recomendações. Depois, ajuste iterativamente a configuração de TTL com base nos dados e insights de desempenho da aplicação.
O DAX mantém uma lista de menos usados recentemente (LRU) para o cache de itens. A lista LRU rastreia quando os itens são gravados pela primeira vez ou lidos pela última vez no cache. Quando a memória do nó do DAX está cheia, o DAX remove itens antigos, mesmo que ainda não tenham expirado, para abrir espaço para novos itens. O algoritmo de LRU está sempre habilitado e não pode ser configurado pelo usuário.
Para definir uma duração de TTL que funcione para suas aplicações, considere os seguintes pontos:
Entenda os padrões de acesso aos dados
-
Workloads com alto volume de leituras: para aplicação com workloads com alto volume leituras e atualizações de dados pouco frequentes, defina uma duração de TTL mais longa para reduzir o número de perdas no cache. Uma duração de TTL mais longa também reduz a necessidade de acessar a tabela subjacente do DynamoDB.
-
Workloads com alto volume de gravações: para aplicações com atualizações frequentes que não são gravadas por meio do DAX, defina uma duração de TTL mais curta para garantir que o cache permaneça consistente com o banco de dados. Uma duração de TTL mais curta também reduz o risco de fornecer dados obsoletos.
Avalie os requisitos de desempenho da aplicação
-
Sensibilidade à latência: se a aplicação exigir baixa latência em relação à atualização dos dados, use uma duração de TTL mais longa. Uma duração de TTL mais longa maximiza os acertos de cache, o que reduz a latência média de leitura.
-
Throughput e escalabilidade: uma duração de TTL mais longa reduz a carga nas tabelas do DynamoDB e melhora o throughput e a escalabilidade. No entanto, você deve equilibrar isso com a necessidade de dados atualizados.
Analise a remoção de cache e o uso de memória
-
Limites de memória de cache: monitore o uso de memória do cluster do DAX. Uma duração de TTL mais longa pode armazenar mais dados no cache, o que pode atingir os limites de memória e levar a remoções baseadas em LRU.
Use métricas e monitoramento para ajustar a TTL
Analise regularmente as métricas, por exemplo, acertos e perdas no cache e utilização de CPU e memória. Ajuste a configuração de TTL com base nessas métricas para encontrar um equilíbrio ideal entre desempenho e atualização dos dados. Se as perdas no cache forem altas e a utilização de memória for baixa, aumente a duração da TTL para aumentar a taxa de acertos de cache.
Considere os requisitos de negócios e a conformidade
As políticas de retenção de dados podem ditar a duração máxima da TTL que você pode definir para informações confidenciais ou pessoais.
Comportamento do cache ao definir a TTL como zero
Se você definir a TTL como 0, o cache de itens e o cache de consultas apresentarão os seguintes comportamentos:
-
Cache de itens: os itens no cache são atualizados somente quando ocorre uma remoção por LRU ou uma operação do tipo write-through.
-
Cache de consultas: as respostas das consultas não são armazenadas em cache.
Armazenar várias tabelas em cache com um cluster do DAX
Para workloads com várias tabelas pequenas do DynamoDB que não precisam de caches individuais, um único cluster do DAX armazena em cache as solicitações dessas tabelas. Isso proporciona um uso mais flexível e eficiente do DAX, especialmente para aplicações que acessam várias tabelas e exigem leituras de alto desempenho.
Assim como as APIs do plano de dados do DynamoDB, as solicitações do DAX exigem um nome de tabela. Se você usa várias tabelas no mesmo cluster do DAX, não precisa de nenhuma configuração específica. No entanto, você precisa garantir que as permissões de segurança do cluster permitam acesso a todas as tabelas armazenadas em cache.
Considerações sobre o uso do DAX com várias tabelas
Ao usar o DAX com várias tabelas do DynamoDB, você deve avaliar os seguintes pontos:
-
Gerenciamento de memória: ao usar o DAX com várias tabelas, você deve considerar o tamanho total do seu conjunto de dados de trabalho. Todas as tabelas em seu conjunto de dados compartilharão o mesmo espaço de memória do tipo de nó selecionado.
-
Alocação de recursos: os recursos do cluster do DAX são compartilhados entre todas as tabelas armazenadas em cache. No entanto, uma tabela de alto tráfego pode causar a remoção de dados das tabelas menores vizinhas.
-
Economias de escala: agrupe recursos menores em um cluster do DAX maior para calcular a média do tráfego em um padrão mais estável. Para o número total de recursos de leitura que o cluster do DAX exige, também é econômico ter três ou mais nós. Isso também aumenta a disponibilidade de todas as tabelas armazenadas em cache no cluster.
Replicação de dados em tabelas globais do DAX e do DynamoDB
O DAX é um serviço baseado em região, portanto um cluster só conhece o tráfego dentro de sua Região da AWS. As tabelas globais gravam sem usar o cache ao replicar dados de outra região.
Uma duração de TTL mais longa pode fazer com que dados obsoletos permaneçam na sua região secundária por mais tempo do que na região primária. Isso pode resultar em perdas no cache local da região secundária.
O diagrama a seguir mostra a replicação de dados ocorrendo no nível da tabela global na Região A de origem. O cluster do DAX na Região B não reconhece imediatamente os dados recém-replicados da Região A de origem.
Disponibilidade de regiões do DAX
Nem todas as regiões que oferecem suporte às tabelas do DynamoDB oferecem suporte à implantação de clusters do DAX. Se sua aplicação exigir baixa latência de leitura por meio do DAX, primeiro consulte a lista de regiões compatíveis com o DAX. Depois, selecione uma região para sua tabela do DynamoDB.
Comportamento de armazenamento em cache do DAX
O DAX executa armazenamento em cache de metadados e negativo. A compreensão desses comportamentos de armazenamento em cache ajudará você a gerenciar com eficiência os metadados de atributos dos itens armazenados em cache e das entradas de cache negativo.
-
Armazenamento de metadados em cache: os clusters do DAX mantêm indefinidamente metadados sobre os nomes de atributos dos itens armazenados em cache. Esses metadados persistem mesmo depois que o item expira ou é removido do cache.
Com o tempo, as aplicações que usam um número não vinculado de nomes de atributos podem provocar exaustão de memória no cluster do DAX. Essa limitação aplica-se somente aos nomes de atributo de nível superior, não a nomes de atributo aninhados. Exemplos de nomes de atributo não vinculados incluem carimbos de data e hora, UUIDs e IDs de sessão. Embora você possa usar carimbos de data e hora e IDs de sessão como valores de atributo, recomendamos usar nomes de atributo mais curtos e previsíveis.
-
Armazenamento em cache negativo: se ocorrer uma perda no cache e a leitura de uma tabela do DynamoDB não gerar nenhum item correspondente, o DAX adicionará uma entrada de cache negativo no respectivo cache de itens ou de consultas. Essa entrada permanecerá até a duração de TTL do cache expirar ou até ocorrer um write-through. O DAX continuará retornando essa entrada de cache negativo para solicitações futuras.
Se o comportamento de armazenamento em cache negativo não se adequar ao padrão da aplicação, leia a tabela do DynamoDB diretamente quando o DAX retornar um resultado vazio. Também recomendamos que você defina uma duração de TTL mais curta para o cache a fim de evitar resultados vazios duradouros no cache e melhorar a consistência com a tabela.
