1. Throughput de intervalo de chaves excedido (partições com acesso frequente) - Amazon DynamoDB
O throughput do intervalo de chaves excedeu as medidas de mitigação.Diagnóstico e monitoramento comunsProcedimentos de resoluçãoRecursos adicionais

1. Throughput de intervalo de chaves excedido (partições com acesso frequente)

O Amazon DynamoDB impõe limites de throughput específicos em nível de partição para a tabela e o índice secundário global (GSI). Cada partição tem um número máximo de unidades de capacidade de leitura (RCUs) e unidades de capacidade de gravação (WCUs) por segundo. Quando as partições recebem tráfego concentrado que excede esses limites, elas sofrem controle de utilização, enquanto outras operações podem permanecer subutilizadas, criando “partições com acesso frequente”. O controle de utilização em nível de partição do DynamoDB opera de forma independente para leituras e gravações. Uma partição pode controlar a utilização de leituras enquanto as gravações continuam normalmente ou vice-versa. Esse controle de utilização pode ocorrer mesmo quando a tabela ou o GSI tem capacidade geral suficiente. Para saber mais a respeito de:

Quando partições individuais excedem os respectivos limites de throughput, o DynamoDB exibe um tipo de motivo de controle de utilização KeyRangeThroughputExceeded na exceção de controle de utilização. As informações identificam que uma partição está enfrentando alto tráfego e qual tipo de operação (leitura ou gravação) está causando o problema.

O throughput do intervalo de chaves excedeu as medidas de mitigação.

Esta seção apresenta diretrizes de resolução para cenários de controle de utilização em nível de partição. Antes de usar este guia, identifique os motivos específicos de controle de utilização do tratamento de exceções da sua aplicação e determine o nome do recurso da Amazon (ARN) do recurso afetado. Para ter informações sobre como recuperar os motivos de controle de utilização e identificar os recursos com controle de utilização, consulte Estrutura de diagnóstico de controle de utilização do DynamoDB.

Antes de se aprofundar em cenários específicos de controle de utilização, verifique se o problema é resolvido automaticamente:

  • O DynamoDB geralmente se adapta a partições com acesso frequente por meio de seu mecanismo automático de divisão por aquecimento. Se você observar eventos de controle de utilização que se interrompem após um curto período, talvez sua tabela já tenha se adaptado dividindo a partição com acesso frequente. Quando as partições são divididas, cada nova partição lida com uma seção menor do espaço de chaves, o que pode ajudar a distribuir a carga de maneira mais uniforme. Em muitos casos, nenhuma ação adicional é necessária, pois o DynamoDB já resolveu o problema automaticamente.

    Para ter mais informações sobre o mecanismo de divisão por aquecimento, consulte Recursos adicionais.

Se o controle de utilização persistir, consulte os seguintes cenários específicos de controle de utilização para ver as opções de correção específicas:

TableReadKeyRangeThroughputExceeded

Quando isso ocorre

A taxa de consumo de uma ou mais partições na tabela do DynamoDB excede o limite de throughput de leitura da partição. Esse controle de utilização ocorre independentemente da capacidade total provisionada da tabela e afeta tanto as tabelas provisionadas quanto as sob demanda. É possível monitorar as métricas do CloudWatch em Diagnóstico e monitoramento comuns para analisar o evento de controle de utilização.

Opções de correção

Considere estas etapas para lidar com eventos de controle de utilização:

Para os modos provisionado e sob demanda:

  • Capacidade antes do aquecimento: se o controle de utilização persistir, verifique se sua tabela está limitada por sua capacidade. Consulte Noções básicas sobre o throughput a quente do DynamoDB. Use o throughput a quente ou aumente a capacidade provisionada de leitura com antecedência para aumentos esperados no tráfego. Aumentar o throughput a quente melhora a capacidade da tabela para lidar com picos repentinos no tráfego antes que ocorra controle de utilização. Com o tempo, se o throughput real se aproximar consistentemente dos níveis de throughput a quente, o DynamoDB poderá dividir as partições muito usadas com base nos padrões de uso observados.

  • Identifique as chaves com acesso frequente: se a tabela não resolver o problema automaticamente e o throughput a quente for alto ou se aumentá-lo não corrigir o problema, será necessário identificar chaves de acesso frequente específicas. Use Identificação de chaves com acesso frequente usando o CloudWatch Contributor Insights para determinar se algum valor específico de chave de partição indica acesso frequente. Essa é a primeira etapa para direcionar suas iniciativas de mitigação de forma eficaz. Observe que a identificação nem sempre é simples, principalmente no caso de partições em que o acesso frequente é revezado (quando partições diferentes recebem acesso frequente ao longo do tempo) ou quando o controle de utilização é acionado por determinadas operações, como verificações. Para esses cenários complexos, talvez seja necessário analisar os padrões de acesso da aplicação e correlacioná-los ao momento do evento de controle de utilização.

  • Dependendo do seu caso de uso, considere a possibilidade de usar leituras finais consistentes: alterne de leituras altamente consistentes para leituras finais consistentes, que consomem metade das RCUs e podem dobrar imediatamente sua capacidade efetiva de leitura. Para ver as práticas recomendadas sobre a implementação de leituras finais consistentes e reduzir o consumo da capacidade de leitura, consulte Consistência de leitura do DynamoDB.

  • Melhore o design da chave de partição: como uma solução de longo prazo, considere Melhorar o design da chave de partição para distribuir o acesso de maneira mais uniforme entre as partições. Essa abordagem geralmente oferece a solução mais abrangente para problemas de partição com acesso frequente abordando a causa raiz. No entanto, requer um planejamento cuidadoso, pois envolve desafios significativos de migração.

TableWriteKeyRangeThroughputExceeded

Quando isso ocorre

A taxa de consumo de uma ou mais partições na tabela do DynamoDB excede o limite de throughput de gravação da partição. Esse controle de utilização ocorre independentemente da capacidade total provisionada da tabela e afeta tanto as tabelas provisionadas quanto as sob demanda. É possível monitorar as métricas do CloudWatch em Diagnóstico e monitoramento comuns para analisar o evento de controle de utilização.

Opções de correção

Considere estas etapas para lidar com eventos de controle de utilização:

Para os modos provisionado e sob demanda:

  • Capacidade antes do aquecimento: se o controle de utilização persistir, verifique se sua tabela está limitada por sua capacidade. Consulte Noções básicas sobre o throughput a quente do DynamoDB. Use o throughput a quente ou aumente a capacidade provisionada de gravação com antecedência para aumentos esperados no tráfego. Aumentar o throughput a quente melhora a capacidade da tabela para lidar com picos repentinos no tráfego antes que ocorra controle de utilização. Com o tempo, se o throughput real se aproximar consistentemente dos níveis de throughput a quente, o DynamoDB poderá dividir as partições muito usadas com base nos padrões de uso observados.

  • Identifique as chaves com acesso frequente: se a tabela não resolver o problema automaticamente e o throughput a quente for alto ou se aumentá-lo não corrigir o problema, será necessário identificar chaves de acesso frequente específicas. Use Identificação de chaves com acesso frequente usando o CloudWatch Contributor Insights para determinar se algum valor específico de chave de partição indica acesso frequente. Essa é a primeira etapa para direcionar suas iniciativas de mitigação de forma eficaz. Considere estes padrões comuns:

    • Se você vir que a mesma chave de partição aparece com frequência em seus dados de controle de utilização, isso indica que ela é uma chave de acesso concentrado.

    • Se você não vir chaves repetidas, mas a gravação de dados estiver ocorrendo de forma ordenada (como carimbos de data/hora sequenciais ou operações baseadas em verificação que seguem a ordem do espaço de chaves), é provável que haja partições com acesso frequente contínuo, caso em que diferentes chaves passam a ter acesso frequente ao longo do tempo à medida que suas gravações se movem pelo espaço de chaves.

    Observe que o controle de utilização de gravação também pode ocorrer com operações como BatchWriteItem ou transações que afetam vários itens simultaneamente. Quando itens individuais em uma solicitação BatchWriteItem sofrem controle de utilização, o DynamoDB não propaga esses erros de controle de utilização para o código da aplicação. Em vez disso, o DynamoDB exibe informações sobre os itens não processados na resposta, com os quais sua aplicação deve lidar ao tentar novamente esses itens específicos. Para transações, a operação inteira falhará com uma TransactionCanceledException se algum item sofrer controle de utilização. Diante desses cenários complexos, talvez seja necessário analisar os padrões de gravação e os fluxos de trabalho de ingestão de dados da aplicação, correlacioná-los com o momento dos eventos de controle de utilização e implementar estratégias apropriadas para lidar com novas tentativas.

  • Melhore o design da chave de partição: como uma solução de longo prazo, considere Melhorar o design da chave de partição para distribuir o acesso de maneira mais uniforme entre as partições. Essa abordagem geralmente oferece a solução mais abrangente para problemas de partição com acesso frequente abordando a causa raiz. No entanto, requer um planejamento cuidadoso, pois envolve desafios significativos de migração.

IndexReadKeyRangeThroughputExceeded

Quando isso ocorre

A taxa de consumo de uma ou mais partições no GSI do DynamoDB excede o limite de throughput de leitura da partição. Esse controle de utilização ocorre independentemente da capacidade total provisionada do GSI e afeta tanto as tabelas provisionadas quanto as sob demanda. É possível monitorar as métricas do CloudWatch em Diagnóstico e monitoramento comuns para analisar o evento de controle de utilização.

Opções de correção

Considere estas etapas para lidar com eventos de controle de utilização:

  • Capacidade antes do aquecimento: se o controle de utilização persistir, verifique se o GSI está limitado por sua capacidade. Consulte Noções básicas sobre o throughput a quente do DynamoDB. Use o throughput a quente ou aumente a capacidade provisionada de leitura com antecedência para aumentos esperados no tráfego. Aumentar o throughput a quente melhora a capacidade do GSI para lidar com picos repentinos no tráfego antes que ocorra controle de utilização. Com o tempo, se o throughput real se aproximar consistentemente dos níveis de throughput a quente, o DynamoDB poderá dividir as partições muito usadas com base nos padrões de uso observados.

  • Identifique as chaves com acesso frequente: se o GSI não resolver automaticamente o problema e o throughput a quente for alto ou aumentá-la não corrigir o problema, você precisará identificar chaves com acesso frequente específicas. Use Identificação de chaves com acesso frequente usando o CloudWatch Contributor Insights para determinar se algum valor específico de chave de partição indica acesso frequente. Essa é a primeira etapa para direcionar suas iniciativas de mitigação de forma eficaz. Observe que, para GSIs, a distribuição de chaves de partição pode diferir significativamente da tabela base, criando diferentes padrões de chaves com acesso frequente.

  • Redefina as chaves de partição do GSI: considere se o design da chave do GSI pode estar criando pontos com acesso frequente não naturais (como sinalizadores de status, chaves somente de data ou atributos boolianos) que concentram as leituras em um pequeno número de partições. Considere a possibilidade de usar chaves compostas que combinem o atributo de baixa cardinalidade com um atributo de alta cardinalidade (p. ex., “ACTIVE#customer123” em vez de apenas “ACTIVE”) ou aplique as técnicas descritas em Usar a fragmentação de gravação para distribuir workloads uniformemente em uma tabela do DynamoDB aos itens da tabela base que afetam a distribuição do GSI para distribuir gravações em várias partições. Embora a consulta de dados fragmentados exija lógica adicional da aplicação para agregar resultados, essa abordagem evita o controle de utilização ao distribuir os padrões de acesso de maneira mais uniforme.

IndexWriteKeyRangeThroughputExceeded

Quando isso ocorre

A taxa de consumo de uma ou mais partições no GSI do DynamoDB excede o limite de throughput de gravação da partição. Esse controle de utilização ocorre independentemente da capacidade total provisionada do GSI e afeta tanto as tabelas provisionadas quanto as sob demanda. É possível monitorar as métricas do CloudWatch em Diagnóstico e monitoramento comuns para analisar o evento de controle de utilização.

Opções de correção

Considere estas etapas para lidar com eventos de controle de utilização:

  • Redefina a chave de partição do GSI: analise o design da chave de partição do GSI para verificar se ela tem cardinalidade (exclusividade) suficiente para distribuir as gravações uniformemente. Uma causa comum de controle de utilização de gravação do GSI é o uso de atributos de baixa cardinalidade como chaves de partição do GSI (p. ex., sinalizadores de status com apenas alguns valores possíveis). Mesmo quando a tabela base tem chaves de partição bem distribuídas, ainda assim o GSI poderá experimentar partições com acesso frequente se a respectiva chave de partição concentrar gravações em um pequeno número de valores. Por exemplo, se 80% dos seus itens tiverem status="ACTIVE", isso criará uma partição com acesso frequente grave em um GSI baseado em status. Considere a possibilidade de usar chaves compostas que combinem o atributo de baixa cardinalidade com um atributo de alta cardinalidade (p. ex., “ACTIVE#customer123” em vez de apenas “ACTIVE”) ou aplique as técnicas descritas em Usar a fragmentação de gravação para distribuir workloads uniformemente em uma tabela do DynamoDB aos itens da tabela base que afetam a distribuição do GSI para distribuir gravações em várias partições. Embora a consulta de dados fragmentados exija lógica adicional da aplicação para agregar resultados, essa abordagem evita o controle de utilização ao distribuir os padrões de acesso de maneira mais uniforme.

  • Capacidade antes do aquecimento: verifique se o GSI está limitado por sua capacidade. Consulte Noções básicas sobre o throughput a quente do DynamoDB. Use o throughput a quente ou aumente a capacidade provisionada de leitura com antecedência para aumentos esperados no tráfego. Aumentar o throughput a quente melhora a capacidade do GSI para lidar com picos repentinos no tráfego antes que ocorra controle de utilização. Com o tempo, se o throughput real se aproximar consistentemente dos níveis de throughput a quente, o DynamoDB poderá dividir as partições muito usadas com base nos padrões de uso observados.

  • Otimize as projeções do GSI: aplique as técnicas descritas em Otimizar as projeções do GSI para reduzir o volume de gravação nos GSIs. Projetar menos atributos pode reduzir significativamente a capacidade de gravação consumida por cada atualização do GSI.

Diagnóstico e monitoramento comuns

Ao solucionar problemas de controle de utilização em nível de partição, várias métricas do CloudWatch podem ajudar a identificar partições com acesso frequente e confirmar a causa raiz.

Métricas essenciais do CloudWatch

Monitore estas métricas essenciais para diagnosticar o controle de utilização em nível de partição:

Procedimentos de resolução

Identificação de chaves com acesso frequente usando o CloudWatch Contributor Insights

Use esse procedimento para identificar quais chaves de partição estão causando controle de utilização.

  1. Habilite o CloudWatch Contributor Insights em sua tabela ou GSI para rastrear as chaves com utilização mais limitada. Considere manter o CloudWatch Contributor Insights habilitado continuamente para alertas de controle de utilização em tempo real usando o modo Chaves limitadas. Esse modo se concentra exclusivamente em solicitações com controle de utilização, processando eventos somente quando ocorre controle. Esse monitoramento direcionado é uma forma econômica de manter a visibilidade contínua dos problemas de controle de utilização.

  2. Identifique quais chaves estão causando os problemas de partição com acesso frequente.

  3. (Se o modo completo Chaves acessadas e limitadas estiver habilitado.) Analise os padrões de acesso ao longo do tempo para determinar se as chaves com acesso frequente são consistentes ou ocorrem durante períodos específicos.

Melhorar o design da chave de partição

Use essa abordagem você puder modificar o esquema da tabela para distribuir melhor o tráfego entre as partições. Quando possível, essa é a solução de longo prazo mais eficaz para problemas de partição com acesso frequente. De preferência, o design da chave de partição deve ser cuidadosamente considerado durante a fase inicial de design da tabela.

A redefinição da chave de partição representa uma alteração fundamental em seu modelo de dados, pois afeta todo o ecossistema de aplicações. Antes de prosseguir com essa abordagem, considere cuidadosamente estas limitações importantes:

  • Complexidade da migração de dados: a redefinição das chaves de partição exige a migração de todos os dados existentes, o que pode consumir muitos recursos e tempo no caso de tabelas grandes.

  • Alterações no código da aplicação: é necessário atualizar todo o código da aplicação que lê ou grava na tabela para usar a nova estrutura de chaves.

  • Impacto na produção: a migração para um novo design de chave geralmente exige tempo de inatividade ou estratégias complexas de dupla gravação durante a transição.

Para ver orientações e princípios abrangentes sobre design de chave de partição, consulte Práticas recomendadas para projetar e usar chaves de partição de maneira eficaz no DynamoDB e Projetar chaves de partição para distribuir a workload no DynamoDB.

Otimizar as projeções do GSI

Analise os padrões de consulta da aplicação para determinar exatamente quais atributos precisam estar disponíveis ao consultar o GSI e limite as projeções apenas a esses atributos. Quando você atualiza atributos que não são projetados em um GSI, nenhuma operação de gravação ocorre nesse GSI, reduzindo o consumo de throughput de gravação durante as atualizações. Essa estratégia de projeção direcionada otimiza o desempenho e o custo e, ao mesmo tempo, atende aos requisitos de consulta da aplicação. Observe que projetar menos atributos reduz o consumo da capacidade de gravação, mas pode exigir leituras adicionais da tabela base.

Para ter mais informações sobre estratégias de projeção eficientes, consulte Práticas recomendadas para uso de índices secundários no DynamoDB.

Recursos adicionais

As seguintes publicações de blog apresentam exemplos e detalhes práticos dos conceitos abordados neste guia: