Esclarecimentos sobre o controle de utilização de gravação e a contrapressão do índice secundário global (GSI) no DynamoDB - Amazon DynamoDB
Esclarecimentos sobre o controle de utilização de contrapressão do GSITipos de controle de utilização do GSI

Esclarecimentos sobre o controle de utilização de gravação e a contrapressão do índice secundário global (GSI) no DynamoDB

O controle de utilização de contrapressão do GSI representa um dos cenários de controle de utilização mais complexos no DynamoDB porque cria uma relação indireta entre as operações de gravação e o controle. A aplicação grava em uma tabela base, mas sofre controle devido a restrições de capacidade em um ou vários índices.

Esclarecimentos sobre o controle de utilização de contrapressão do GSI

Quando você grava uma tabela no DynamoDB, quaisquer índices secundários globais (GSIs) nessa tabela são atualizados de forma assíncrona usando um modelo com consistência final. Se um GSI não tiver capacidade suficiente para lidar com essas atualizações, o DynamoDB limitará as gravações na tabela base para manter a consistência de dados. Isso é chamado de contrapressão do GSI. Para ter mais informações sobre como os GSIs funcionam, consulte Global Secondary Indexes in DynamoDB.

Ao contrário controle de utilização direto da tabela, em que o recurso que está sendo acessado também é o recurso que causa o controle, a contrapressão do GSI cria uma dependência entre a tabela base e os respectivos índices. Mesmo que a tabela base tenha ampla capacidade, as gravações sofrerão controle de utilização se algum GSI associado não conseguir lidar com o volume de atualização. É particularmente importante entender essa relação porque as restrições em nível de partição se aplicam de forma independente à tabela base e a cada GSI. Cada um tem sua própria estrutura de partição e limites de throughput correspondentes.

O particionamento do GSI é baseado na chave de partição do GSI, que geralmente é diferente da chave de partição da tabela base. Mesmo que o acesso à tabela base esteja perfeitamente distribuído entre partições, as atualizações do GSI ainda assim podem se concentrar em partições específicas, criando pontos de acesso frequente no GSI. Para ver as práticas recomendadas gerais sobre design de chave de partição para tabelas e GSIs, consulte DynamoDB partition key design.

Por exemplo, se a tabela base usa customerId como chave de partição (distribuída uniformemente), mas o GSI usa status como chave de partição (com valores possíveis limitados, como “ativo”, “pendente” e “fechado”), as atualizações em itens com valores de status conhecidos podem criar partições com acesso frequente (quentes) do GSI mesmo quando o acesso à tabela base está equilibrado. Isso cria um cenário particularmente desafiador, em que a aplicação pode sofrer controle de utilização devido a partições com acesso frequente do GSI, mesmo que a tabela base e o GSI tenham capacidade geral suficiente e o padrão de acesso da tabela base pareça bem distribuído.

Embora a exceção de controle de utilização aponte para o GSI (por meio do ResourceArn), a operação real que está sofrendo controle de utilização é a gravação na tabela base. Isso pode ser confuso porque a aplicação está gravando na tabela base e recebendo uma exceção relacionada ao GSI.

Tipos de controle de utilização do GSI

O controle de utilização de contrapressão do GSI manifesta-se por meio de diferentes tipos de exceção, dependendo da restrição específica de capacidade:

  • Capacidade provisionada do GSI excedida: ocorre quando o GSI não tem unidades de capacidade de gravação suficientes para lidar com as atualizações das operações da tabela base. Isso gera uma ProvisionedThroughputExceededException com o motivo IndexWriteProvisionedThroughputExceeded, e o ResourceArn aponta diretamente para o GSI específico que está enfrentando restrições de capacidade.

  • Throughput máximo sob demanda do GSI excedido: ocorre quando as operações de gravação do GSI ultrapassam os limites máximos configurados nas tabelas sob demanda. Isso gera uma ThrottlingException com o motivo IndexWriteMaxOnDemandThroughputExceeded, identificando o GSI específico com restrições de throughput configuradas.

  • Limites de partição do GSI excedidos: ocorre quando partições individuais do GSI excedem os respectivos limites de throughput (partições com acesso frequente), mesmo que a capacidade geral do GSI pareça suficiente. Isso gera um ThrottlingException com o motivo IndexWriteKeyRangeThroughputExceeded, indicando problemas de partição com acesso frequente no GSI específico identificado no ResourceArn. Isso é particularmente importante porque a distribuição de partições do GSI pode diferir significativamente da distribuição de partições da tabela base, criando pontos de acesso frequente no GSI mesmo quando o acesso à tabela base é distribuído uniformemente.

  • Limites da conta do GSI excedidos: esses limites são acionados quando as operações de gravação em um GSI específico excedem os limites regionais de throughput por tabela (ou de qualquer GSI individual dentro dessa tabela) definidos no nível da conta. O DynamoDB exibe uma ThrottlingException com o motivo IndexWriteAccountLimitExceeded, apontando para o GSI que ultrapassou os limites de uso da conta. Esse controle de utilização ocorre de forma independente para cada GSI que ultrapassa o limite. Para ter informações sobre cotas por tabela, por conta, regionais e de serviço, consulte Cotas no Amazon DynamoDB.