Principais métricas a serem consideradas durante o monitoramento do desempenho do DynamoDB da AWS!

Bancos de dados NoSQL sempre foram considerados como um degrau acima dos bancos de dados SQL. A principal razão para a crescente popularidade dos bancos de dados NoSQL é sua abordagem dinâmica e amigável à nuvem para processar dados com facilidade em uma grande quantidade de servidores comuns. Com alta escalabilidade, disponibilidade e confiabilidade, o DynamoDB da AWS é um ótimo exemplo de banco de dados NoSQL totalmente gerenciado.

Se sua organização está usando o DynamoDB, existem algumas métricas importantes que você precisa controlar para garantir que seus aplicativos sejam executados sem problemas. Negligencie esses números-chave e corre o risco de perder a marca do desempenho ótimo do aplicativo. Vamos dar uma olhada nas métricas que você precisa monitorar para atingir o desempenho do DynamoDB:

1. Solicitações limitadas e capacidade de transferência

Para garantir um desempenho consistente e de baixa latência de seus aplicativos, é essencial definir com antecedência a capacidade de produção de atividades de R / W e garantir que elas sejam suficientes para as necessidades de seu aplicativo. Se suas solicitações de leitura ou gravação excederem o limite definido – o significado consumido é maior do que o throughput provisionado – o DynamoDB limitará a solicitação; em outras palavras, limitará o número de solicitações que podem ser submetidas a uma operação em um determinado período de tempo. Esse processo é baseado em um conceito chamado de “algoritmo leaky bucket”, que protege o aplicativo de ser sobrecarregado com solicitações. Quando uma solicitação é acelerada, o cliente da API do DynamoDB pode tentar novamente automaticamente.

Métricas para observar:

Unidades de capacidade R / W consumidas e aprovisionadas: Uma unidade de capacidade de leitura representa uma leitura por segundo para um item com tamanho até 4 KB. Ler um item maior que 4KB consome mais unidades de capacidade de leitura. Uma unidade de capacidade de gravação representa uma gravação por segundo para um item até 1 KB de tamanho. As unidades de capacidade de rastreamento R / W ajudarão você a detectar picos e quedas anormais nas atividades de R / W.

Capacidade de burst: Quando a taxa de transferência de uma tabela não é totalmente utilizada, o DynamoDB economiza uma parte dessa capacidade não utilizada para futuros “surtos” de taxa de transferência de R / W. O DynamoDB pode realmente usar essa capacidade de burst para evitar solicitações limitadas; Se a capacidade de burst estiver disponível, as solicitações de R / W que excederem seu limite de rendimento poderão ser bem-sucedidas. No entanto, a capacidade de ruptura pode mudar com o tempo e nem sempre estar disponível, portanto, uma carga de trabalho uniformemente distribuída é fundamental para otimizar o desempenho do aplicativo.

2. Latência

Do ponto de vista de um usuário final, a latência é uma métrica que determina a eficiência do seu aplicativo. Para uma experiência suave ao usuário final, o DynamoDB fornece latência em milissegundos de dígito único para aplicativos executados em qualquer escala. Isso significa que, mesmo quando seu aplicativo cresce e começa a armazenar uma enorme quantidade de dados, o DynamoDB continuará fornecendo desempenho rápido e consistente. A latência geralmente é a melhor quando você usa a instância localizada na mesma região.

    3. Erros

Se uma solicitação não for bem-sucedida, o DynamoDB retornará um erro que contém três componentes:

• Código de status HTTP

• Mensagem de erro

• Nome da exceção

Métricas para observar:

• Erros do sistema:  representa o número de solicitações que resultaram em um código de erro 500 (erro do servidor). Geralmente é igual a zero.

• Erro do usuário:  representa o número de solicitações que resultaram em um código de erro 400 (solicitação incorreta). Se o cliente estiver interagindo corretamente com o DynamoDB, essa métrica deverá ser igual a zero.

• Solicitações de falha de verificação condicional:  refere-se à condição lógica de uma solicitação de gravação que informa se um item pode ser modificado ou não. Esse erro é considerado separado de um erro do usuário, mesmo que um código de erro 400 (solicitação incorreta) seja retornado.

4. Índice secundário global

Embora o DynamoDB ofereça acesso rápido aos itens em uma tabela, especificando os principais valores principais, os aplicativos podem se beneficiar de ter uma ou mais chaves secundárias para acesso eficiente. Para ilustrar, considere a tabela abaixo chamada “Carrinho de compras”, que acompanha os livros mais vendidos. Cada item no carrinho é identificado por uma chave de partição (ID) e uma chave de classificação (título do livro). Ao executar uma ação, um aplicativo pode ter dificuldades para recuperar dados de “Livros populares” com base no título do livro apenas porque ID é a chave de partição; é muito mais fácil exibir os dois principais livros com base no ID e no título do livro.

Livros populares

É aqui que um índice secundário global (GSI) pode ajudar. Um GSI contém uma seleção de atributos da tabela base, mas é organizado por uma chave primária diferente da tabela. Isso aumenta o desempenho de consultas em atributos não-chave. As considerações de armazenamento devem ser mantidas em mente, pois a alocação de recursos para o novo índice pode levar mais tempo para tabelas maiores.

Métricas para observar:

• R/W capacity units
• GSI throughput and throttled requests
• Online index throttled events
• Online index consumed write capacity

 Veja todas as métricas do GSI .