Classificando DynamoDB em um atributo variável

Você modela uma chave de classificação em torno de um atributo para poder consultar itens em sua ordem - então o alterações de atributos. O status de um ticket, o estado de um pedido, a prioridade de uma tarefa. DynamoDB regra: você não pode atualizar um atributo de chave no local. Uma chave primária é imutável para a vida útil do item. Altere um valor que faz parte da chave e você não estará editando um item - você está movendo-o, o que DynamoDB faz com que você faça isso explicitamente.

Você pode alterar uma chave de classificação DynamoDB?

Não. Uma chave de classificação faz parte da chave primária e os atributos da chave DynamoDB são imutáveis — UpdateItem não pode editar uma partição ou valor de chave de classificação e não há operação de "mover item". Para alterá-lo, exclua o item antigo e coloque um novo ou mantenha o valor volátil em uma chave de classificação GSI.

• Atributos-chave são imutáveis. Você não pode UpdateItem uma partição ou chave de classificação valor — DynamoDB não possui operação de "mover item".
• Para alterar um valor-chave, você exclui o item antigo e coloca um novo - de preferência em um transação então é atômico.
• Melhor: mantenha o valor volátil fora da chave da tabela base e coloque-o em um GSI chave de classificação - GSI chaves podem mudar, porque a atualização o item base apenas propaga novamente a entrada do índice.
• Escolha chaves de classificação que não mudam (carimbos de data e hora, ids imutáveis) sempre que o acesso padrão permite.

O problema: um status pelo qual você deseja classificar, que muda constantemente

Digamos que você administre uma central de suporte e queira listar os tickets de uma equipe ordenados por status. coloque o status na chave de classificação:

PK: TEAM#7   SK: STATUS#open#TICKET#8842

Agora o ticket passa para pendente. Você gostaria apenas de UpdateItem a chave de classificação para STATUS#pending#TICKET#8842 — mas DynamoDB rejeita qualquer gravação que altere uma chave atributo. A chave é o endereço do item; você não pode editar o endereço no local. O o status que você escolheu para classificar é exatamente o que não fica parado.

Opção 1: excluir e recriar (atomicamente)

Se o valor deve estar na chave da tabela base, alterá-lo significa remover o item antigo e escrevendo o novo:

1. DeleteItem  PK=TEAM#7  SK=STATUS#open#TICKET#8842
2. PutItem     PK=TEAM#7  SK=STATUS#pending#TICKET#8842  (same attributes)

Faça isso dentro de um TransactWriteItems para que o delete e a opção de venda é bem-sucedida ou ambas falham - caso contrário, uma colisão entre eles perde o ticket ou duplicá-lo. Isso funciona, mas cada mudança de status agora consiste em duas gravações mais uma transação; bom para mudanças ocasionais, caro para mudanças quentes.

Opção 2: manter o valor mutável fora da chave base (preferencial)

Torne a chave da tabela base algo imutável (o ID do ticket) e coloque o valor volátil e classificável em uma chave de classificação GSI.

Base:  PK: TICKET#8842   status: "open"   teamId: TEAM#7
GSI:   GSI1PK: TEAM#7    GSI1SK: STATUS#open#TICKET#8842

Agora, alterar o status é um UpdateItem simples no atributo status do item base - qual DynamoDB permite, porque status não é uma chave da tabela base. DynamoDB então repropaga a entrada GSI automaticamente para sua nova posição classificada. Uma chamada API, com atomicidade tratada para você - sem transação, sem dança de exclusão (nos bastidores DynamoDB ainda exclui a entrada antiga do índice e grava a nova, portanto, uma alteração indexada custa ~3 gravar unidades em relação ao ~4 de uma exclusão e colocação transacional).

O GSI é eventualmente consistente e custa armazenamento/gravações extras - mas para um valor que muda frequentemente, isso é um pouco mais barato (~3 vs 4 unidades de gravação) e muito mais simples do que excluir e recriar a cada alteração.

Projetando as chaves em DynoTable

Crie e visualize as principais condições para a leitura base e a leitura GSI no DynamoDB construtor de expressão.

Em DynoTable, você escolhe em qual índice uma consulta é executada e observa o volátil classificação de valor em GSI enquanto o item base mantém sua chave imutável - ambos são lidos lado a lado lado em dados reais.

Armadilhas + próximos passos

• Nunca tente UpdateItem um atributo chave — ele é rejeitado; os valores-chave são fixos para a vida do item.
• Se você precisar movê-lo, exclua+coloque uma transação — nunca como dois desprotegidos escreve.
• Prefira chaves base imutáveis + um GSI para qualquer atributo que você classificar por e alterar.
• Não se esqueça de GSI consistência eventual — a entrada reclassificada aparece após um breve atraso de propagação.
• Relacionado: estratégias de classificação de chaves, GSI vs LSI, transações.

Quer ver como um atributo mutável é classificado em GSI versus a tabela base? Baixe DynoTable e explore seus índices diretamente.

Custo de gravação: excluir e colocar vs atualização GSI

Comparação aproximada de WCU para um item de ticket de 1 KB em us-east-1 sob demanda (real o faturamento segue regras de arredondamento AWS):

O caminho GSI evita a orquestração no nível do aplicativo e elimina a janela onde uma falha entre delete e put perde a linha. Você negocia consistência eventual na leitura do índice para gravações mais simples.

Modele o tamanho do item e a taxa de atualização no calculadora de preços quando o status muda é acionado muitas vezes por minuto.

Esparso GSI para listas classificadas por status

Se apenas tickets abertos precisarem de uma fila classificada por status, use um índice esparso: escreva GSI1PK = TEAM#7 e GSI1SK = STATUS#open#... apenas enquanto status = open. Quando o ticket fechar, remova ou omita os atributos-chave GSI na atualização - o item sai do índice sem excluir e colocar na chave de classificação base.

Isso mantém o índice pequeno e evita a indexação de tickets fechados que você nunca lista.

Chaves base imutáveis para preferir

Carimbos de data e hora e IDs imutáveis (CREATED#2026-06-27T10:00:00Z, TICKET#8842) crie chaves de classificação base estáveis quando precisar de ordem cronológica na tabela base em si.

Projete o GSI antes de codificar

Mapear padrões de acesso no ferramenta de design de tabela única — insira "lista abrir tickets por equipe, ordem de prioridade" e inspecionar o GSI1PK sugerido / Modelos GSI1SK. Em seguida, construa a condição-chave no construtor de expressão e emita um arquivo paginado consulta com o query builder para integração testes.

Leia suas gravações após a mudança de status

Depois de UpdateItem, uma leitura fortemente consistente na tabela base mostra o novo status imediatamente. Uma consulta no GSI pode demorar um pouco. Fluxos de UI que redirecionar para uma fila classificada em GSI deve tolerar linhas obsoletas ou buscar novamente no tabela base por id quando a precisão é importante.