Esta seção apresenta uma visão geral de como avaliar se você está usando suas tabelas do DynamoDB de forma eficiente. Existem certos padrões de uso que não são ideais para o DynamoDB e permitem a otimização tanto do ponto de vista do desempenho quanto do custo.
Tópicos
Realizar menos operações de leitura altamente consistente
O DynamoDB permite que você configure a consistência de leitura por solicitação. As solicitações de leitura são finais consistentes por padrão. Leituras finais consistentes são cobradas a 0,5 RCU para até 4 KB de dados.
A maioria das partes das workloads distribuídas é flexível e pode tolerar uma eventual consistência. No entanto, pode haver padrões de acesso que exijam leituras altamente consistentes. Leituras altamente consistentes são cobradas em 1 RCU para até 4 KB de dados, basicamente dobrando seus custos de leitura. O DynamoDB oferece a flexibilidade de usar os dois modelos de consistência na mesma tabela.
Você pode avaliar sua workload e o código da aplicação para confirmar se leituras altamente consistentes são usadas somente quando necessário.
Executar menos transações para operações de leitura
O DynamoDB permite que você agrupe determinadas ações de uma forma de tudo ou nada, o que significa que você tem a capacidade de executar transações ACID com o DynamoDB. No entanto, como é o caso dos bancos de dados relacionais, não é necessário seguir essa abordagem para cada ação.
Uma operação de leitura transacional de até 4 KB consome 2 RCUs em oposição às 0,5 RCUs padrão para ler a mesma quantidade de dados de uma forma final consistente. Os custos são duplicados nas operações de gravação, o que significa que uma gravação transacional de até 1 KB equivale a 2 WCUs.
Para determinar se todas as operações em suas tabelas são transações, as métricas do CloudWatch para a tabela podem ser filtradas até as APIs de transação. Se as APIs de transação forem os únicos gráficos disponíveis nasSuccessfulRequestLatency métricas da tabela, isso confirmaria que cada operação é uma transação para essa tabela. Como alternativa, se a tendência geral de utilização da capacidade corresponder à tendência da API de transação, considere revisitar o design da aplicação, pois ele parece dominado pelas APIs transacionais.
Realizar menos verificações
O uso extensivo de operações Scan geralmente decorre da necessidade de executar consultas analíticas nos dados do DynamoDB. Executar operações Scan frequentes em uma tabela grande pode ser ineficiente e caro.
Uma alternativa melhor é usar o recurso Exportar para o S3 e escolher um momento para exportar o estado da tabela para o S3. A AWS oferece serviços como o Athena, que podem então ser usados para executar consultas analíticas nos dados sem consumir nenhuma capacidade da tabela.
A frequência das operações Scan pode ser determinada usando a estatística SampleCount na métrica SuccessfulRequestLatency para Scan. Se as operações Scan forem realmente muito frequentes, os padrões de acesso e o modelo de dados devem ser reavaliados.
Encurtar nomes de atributo
O tamanho total de um item no DynamoDB é a soma dos tamanhos e valores de seus nomes de atributo. Ter nomes de atributos longos não só contribui para os custos de armazenamento, mas também pode levar a um maior consumo de RCU/WCU. Recomendamos que você escolha nomes mais curtos para os atributos. Ter nomes de atributos mais curtos pode ajudar a limitar o tamanho do item dentro do próximo limite de 4 KB/1 KB, após o qual você consumiria RCU/WCU adicional para acessar os dados.
Habilitar a vida útil (TTL)
O Tempo de vida (TTL) pode identificar itens mais antigos do que o tempo de expiração que você definiu em um item e removê-los da tabela. Se seus dados crescerem com o tempo e os dados mais antigos se tornarem irrelevantes, habilitar o TTL na tabela pode ajudar a reduzir seus dados e economizar nos custos de armazenamento.
Outro aspecto útil do TTL é que os itens expirados ocorrem em seus fluxos do DynamoDB, portanto, em vez de apenas remover os dados dos seus dados, é possível consumir esses itens do fluxo e arquivá-los em um nível de armazenamento de menor custo. Além disso, a exclusão de itens via TTL não tem nenhum custo adicional. Ela não consome capacidade e não há sobrecarga na criação de uma aplicação de limpeza.
Substituir tabelas globais por backups entre regiões
As tabelas globais permitem que você mantenha várias tabelas de réplicas ativas em diferentes regiões. Todas elas podem aceitar operações de gravação e replicar dados entre si. É fácil configurar réplicas e a sincronização é gerenciada para você. As réplicas convergem para um estado consistente usando uma estratégia de “último gravador ganha”.
Se estiver usando tabelas globais apenas como parte da estratégia de failover ou recuperação de desastres (DR), você poderá substituí-las por uma cópia de backup entre regiões para obter objetivos de ponto de recuperação relativamente flexíveis e requisitos de objetivo de tempo de recuperação. Se você não precisa de acesso local rápido e da alta disponibilidade de cinco noves, manter uma réplica de tabela global pode não ser a melhor abordagem para o failover.
Como alternativa, considere usar oAWS Backup para gerenciar backups do DynamoDB. Você pode programar backups regulares e copiá-los entre regiões para atender aos requisitos de DR em uma abordagem mais econômica em comparação com o uso de tabelas globais.
