

# Avaliar a adequação do DAX aos seus casos de uso
<a name="evaluate-dax-suitability"></a>

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.

**Topics**
+ [Quando e por que escolher o DAX](#choose-dax)
+ [Quando não usar o DAX](#dax-unsuitable-scenarios)

## Quando e por que escolher o DAX
<a name="choose-dax"></a>

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](TTL.md) 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](provisioned-capacity-mode.md#read-write-capacity-units) (RCUs). O DAX permite escalar as leituras de um único item para além de 3.000 RCUs. 
+ **Otimização de custos**
  + **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](DAX.consistency.md). 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
<a name="dax-unsuitable-scenarios"></a>

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](pres-guide-monitor-dax.md#cachehitratio). 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](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactGetItems.html) 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](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html) e [Scan](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html), os benefícios do armazenamento em cache do DAX poderão ser limitados.

  Nessas situações, use o [Amazon ElastiCache (Redis OSS)](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) 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.