Por que podemos escolher a capacidade de gravação dos GSIs?

Aqui estão alguns motivos pelos quais a demanda por capacidade de gravação GSI pode ser inferior à capacidade da tabela:

(1) Você aplica o padrão de índice esparso , no qual nem todos os itens da tabela são gravados em um índice:

Para qualquer item em uma tabela, o DynamoDB grava uma entrada de índice correspondente somente se o valor da chave de classificação do índice estiver presente no item. Se a chave de classificação não aparecer em todos os itens da tabela ou se a chave de partição do índice não estiver presente no item, o índice será considerado esparso.

(2) Seus padrões de consulta de índice não exigem o item inteiro. Nesse caso, você pode escrever ( "project" ) apenas um subconjunto dos atributos de um item no índice. A escolha cuidadosa das projeções pode reduzir potencialmente a demanda por gravações de índices:

Como os índices secundários consomem armazenamento e taxa de transferência provisionada, você deve manter o tamanho do índice o menor possível... Se suas consultas geralmente retornam apenas um pequeno subconjunto de atributos e o tamanho total desses atributos é muito menor que o item inteiro , projete apenas os atributos solicitados regularmente.

Ambas as abordagens aparecem no guia de práticas recomendadas do DynamoDB .

E o caso oposto? @hunterhacker observou um cenário em que um GSI pode precisar de *mais* capacidade do que a tabela: se você tiver muitas operações de atualização que modificam um atributo de chave primária do GSI, mas NÃO os atributos-chave da tabela. Isso precisaria de um delete + insert (2 operações) no índice, mas apenas de uma atualização (1 operação) na tabela.