Avaliar a adequação do DAX aos seus casos de uso
Esta seção explica quando e por que usar o DAX. Use essas orientações para determinar se a integração do DAX com o DynamoDB é vantajosa para os padrões de workload, os requisitos de desempenho e as necessidades de consistência de dados da sua aplicação. Também abrange cenários em que o DAX pode não ser adequado, como workloads com alto volume de gravações e dados acessados com pouca frequência.
Quando e por que escolher o DAX
Você pode considerar a adição do DAX à sua pilha de aplicações em vários cenários. Por exemplo, use o DAX para reduzir a latência geral das solicitações de leitura no DynamoDB ou para minimizar as leituras repetidas dos mesmos dados de uma tabela. A seguinte lista apresenta exemplos de cenários nos quais você pode aproveitar a integração do DAX com o DynamoDB:
-
Requisito de alto desempenho
-
Leituras de baixa latência: considere o uso do DAX se sua aplicação exigir tempos de resposta na casa dos microssegundos para leituras finais consistentes. O DAX também pode reduzir drasticamente o tempo de resposta de acesso a dados lidos com frequência.
-
-
Workloads com alto volume de leituras
-
Aplicações com alto volume de leituras: para aplicações com alta relação entre leituras e gravações, por exemplo, 10:1 ou mais, o DAX resulta em mais acessos ao cache e menos dados obsoletos. Isso reduz a quantidade de leituras em uma tabela. Para evitar a leitura de dados obsoletos do cache se sua aplicação tiver alto volume de gravações, defina uma Usar a vida útil (TTL) no DynamoDB mais baixa para o cache.
-
Armazenamento de consultas comuns em cache: se sua aplicação lê frequentemente os mesmos dados, por exemplo, produtos populares em uma plataforma de comércio eletrônico, o DAX pode atender a essas solicitações diretamente do cache.
-
-
Padrões de tráfego intermitente
-
Ajuste mais suave da escala da tabela: o DAX ajuda a suavizar os impactos de picos repentinos de tráfego. O DAX fornece um buffer para aumentar a escala verticalmente da capacidade da tabela do DynamoDB de forma adequada, o que reduz o risco de controle de utilização de leituras.
-
Maior throughput de leitura para cada item: o DynamoDB aloca partições individuais para cada item. No entanto, uma partição começa a aplicar o controle de utilização nas leituras de um item quando atinge 3.000 unidades de capacidade de leitura (RCUs). O DAX permite escalar as leituras de um único item para além de 3.000 RCUs.
-
-
Otimização de custo
-
Redução dos custos do DynamoDB: a realização de leituras do DAX pode reduzir a quantidade de leituras enviadas para uma tabela do DynamoDB, o que pode afetar diretamente o custo. Com uma alta taxa de acertos de cache, o custo reduzido de leitura da tabela pode exceder o custo do cluster do DAX, resultando em uma redução do custo líquido.
-
-
Requisitos de consistência de dados
-
Consistência eventual: o DAX oferece suporte a leituras finais consistentes. Isso torna o DAX adequado para casos de uso em que a consistência imediata não é essencial.
-
Armazenamento em cache com write-through: as gravações feitas no DAX são do tipo write-through. Depois que o DAX confirma a gravação de um item no DynamoDB, ele mantém essa versão do item no cache de itens. Esse mecanismo de write-through ajuda a manter uma consistência de dados mais rigorosa entre o cache e o banco de dados, mas usa recursos adicionais do cluster do DAX.
-
Quando não usar o DAX
Embora o DAX seja poderoso, ele não é adequado para todos os cenários. A seguinte lista apresenta exemplos de cenários em que a integração do DAX com o DynamoDB não é adequada:
-
Workloads com alto volume de gravações: a principal vantagem do DAX é acelerar as leituras, mas as gravações usam mais recursos do DAX do que as leituras. Se sua aplicação apresentar alto volume de gravações, os benefícios do DAX poderão ser limitados.
-
Dados lidos com baixa frequência: se sua aplicação acessa dados com baixa frequência ou uma grande variedade de dados raramente reutilizados (dados frios), é provável que você tenha uma baixa cache hit ratio. Nesse caso, a despesa de manutenção do cache pode não justificar os ganhos de desempenho.
-
Leituras ou gravações em massa: se sua aplicação realiza mais gravações em massa do que gravações individuais, é melhor gravar sem usar o DAX. Além disso, para leituras em massa, é necessário executar varreduras completas da tabela diretamente em uma tabela do DynamoDB.
-
Forte consistência ou requisitos de transação: o DAX transmite leituras altamente consistentes e chamadas TransactGetItems para uma tabela do DynamoDB. Você deve realizar essas leituras sem usar o cluster do DAX para evitar o uso de recursos do cluster. Os itens lidos dessa forma não serão armazenados em cache, portanto rotear esses itens pelo DAX não oferece nenhuma vantagem.
-
Aplicações simples com requisitos de desempenho moderado: para aplicações com requisitos de desempenho moderado e tolerância à latência direta do DynamoDB, a complexidade e o custo de adicionar o DAX podem não ser necessários. Por si só, o DynamoDB lida com alto throughput e fornece desempenho de latência inferior a 10 milissegundos.
-
Necessidades de consultas complexas além do acesso a valores e chaves: o DAX é otimizado para padrões de acesso a valores e chaves. Se sua aplicação exigir recursos complexos de consulta com filtragem complexa, como operações Query e Scan, os benefícios do armazenamento em cache do DAX poderão ser limitados.
Nessas situações, use o Amazon ElastiCache (Redis OSS) como alternativa. O ElastiCache (Redis OSS) comporta estruturas de dados avançadas, como listas, conjuntos e hashes. Ele também oferece outros recursos, como pub/sub, índices geoespaciais e scripts.
-
Requisitos de conformidade: o DAX ainda não oferece os mesmos credenciamentos de conformidade do DynamoDB. Por exemplo, o DAX ainda não obteve o credenciamento SOC.
