DynamoDB Migrações sem tempo de inatividade

Vindo de SQL, uma migração é um ALTER TABLE que bloqueia a tabela enquanto ela reescreve cada linha. DynamoDB não tem esquema para alterar — os itens não têm esquema, então adicionar um atributo ou um novo tipo de entidade é gratuito.

A parte difícil é o padrão de acesso que os novos dados devem servir e remodelar dados em tempo real para atendê-los sem uma reescrita de parar o mundo.

Como você migra uma tabela DynamoDB sem tempo de inatividade?

DynamoDB não possui ALTER TABLE, então as migrações nunca bloqueiam a tabela. Você adiciona atributos, um novo formato de chave ou um novoGSIonline com UpdateTable e, em seguida, remodele os dados ativos de forma incremental: preencha itens antigos preguiçosamente na leitura ou com uma varredura acelerada e grave ambos os formatos durante a transição. Não há transição para o dia da bandeira.

• Não há ALTER TABLE. Os itens não têm esquema. Uma “migração” significa adicionar atributos, um novo formato de chave ou um novo índice — nunca reescrever um conjunto de colunas fixas.
• Novas gravações são fáceis; itens antigos são o problema. As linhas existentes não carregam os novos atributos, para que qualquer novo índice ou consulta os perca silenciosamente até você preencher.
• Adicione índices on-line, preencha preguiçosamente. UpdateTable cria um GSI em um live mesa; preencher itens antigos na leitura (preguiçoso) ou com uma varredura controlada - nunca um transição do dia da bandeira.
• Escrita dupla durante a transição. Embora ambas as formas coexistam, escreva a antiga e o novo formato juntos para que nenhum caminho de leitura fique obsoleto.

Enquadre-o como um padrão de acesso, não como uma coluna

Digamos que você execute um produto de espaço de trabalho SaaS em uma tabela. Os itens usam PK = "WS#<id>" e SKsobrecarregadopor entidade:

Agora o produto quer comentários nos documentos, além de uma nova leitura: "listar todos comentário que um membro escreveu no espaço de trabalho, o mais recente primeiro." Essa última cláusula é a migração. Um novo tipo de entidade por si só é trivial; atendendo a uma consulta as chaves atuais não podem responder é o trabalho.

Adicione o novo tipo de entidade primeiro

Os comentários são apenas novos itens na mesma partição — sem cerimônia de migração, sem nova tabela:

Um Query em PK = "WS#a91" com SK begins_with "DOC#2026-04-01#x7#CMT#" já lista os comentários de um documento. Os documentos existentes permanecem intactos. Isto metade é enviada no primeiro dia — consulte coleções de itens e chaves sobrecarregadas por que a mesma partição contém ambos.

A nova consulta precisa de um GSI

"Todos os comentários de um membro, os mais recentes primeiro" não podem ser veiculados pela tabela base - memberId não é o prefixo PK nem um prefixo SK. Esse é um novo índice e escolhê-lo corretamente é uma decisão própria: consulte GSI vs LSI (um LSI deve existir na criação da tabela, portanto, para uma migração em uma tabela ativa, um GSI é sua única opção).

Adicione um GSI1 genérico e escreva os novos atributos em novos itens de comentário:

Query GSI1 WHERE GSI1PK = "MEMBER#u44" com ScanIndexForward = false fornece comentários mais recentes por membro.

Crie o índice on-line

UpdateTable adiciona um GSI a uma tabela ativa sem tempo de inatividade. DynamoDB preenchimentos itens existentes no índice em segundo plano; os relatórios de índice CREATING/preenchimento até terminar, depois muda para ACTIVE (Gerenciando GSIs).

Duas armadilhas aqui. Primeiro, AWS avisa que adicionar umGSIpode acelerar a tabela base escreve se a nova chave for distribuída de forma desigual — adicione-a em uma janela de baixo tráfego e assista CloudWatch. Em segundo lugar, o índice é eventualmente consistentemesmo depois vai ATIVO; uma gravação pode não ficar visível no GSI por um momento. Veja por que GSIs são eventualmente consistentes.

Preencha os itens antigos

O GSI indexa apenas itens que têm GSI1PK/GSI1SK. Sua pré-migração comentários - escritos antes da existência do atributo - nunca aparecem, mesmo depois o preenchimento é concluído. O preenchimento online GSI copia itens existentes, mas não pode inventar atributos que não estão neles. Você tem que somar os valores.

Duas estratégias:

Para a varredura, percorra com Scan e para cada comentário antigo adicione o índice atributos com um UpdateItem condicional para que você nunca destrua um concorrente escreva.

A condição protege o atributo que ainda não existe. Construa e copie o ConditionExpression e UpdateExpression exatos com o DynamoDB Expression Builder em vez de digitando manualmente attribute_not_exists(GSI1PK).

Gravação dupla durante a transição

Até que cada item antigo carregue os novos atributos, duas formas coexistem. A escrita path deve preencher o novo formato em cada gravação - novos comentários e quaisquer atualize para um antigo - para que a lacuna apenas diminua.

Escolha uma condição final de preenchimento que você possa verificar: a varredura paginava toda a tabela, ou o caminho lento durou o suficiente para que os itens não convertidos fiquem obsoletos por design. Só então você remove o antigo caminho de leitura. Ignorando isso é como uma migração "conclui", enquanto uma fração das consultas retorna silenciosamente resultados curtos.

Armadilhas

• Adicionando o atributo ≠ preenchido. Um novo GSI começa vazio para itens antigos. Verifique a cobertura antes de confiar na consulta.
• Alterar uma chave é uma reescrita. Você não pode alterar PK/SK de um item; você escreve um novo item sob a nova chave e exclui o antigo. Planeje-o como copiar e excluir, com leitura dupla intermediária.
• Sem transição transacional. Não há nenhum momento em que a mesa inteira vire. Projete cada etapa para ser segura enquanto ambas as formas estiverem ativas.

Próximos passos

Verifique a sanidade das novas chaves e coleções sobrecarregadas em design de tabela única e confirme se o preenchimento está conclua paginando a tabela ativa. Experimente DynoTable para navegar em seu tabela, identifique itens não preenchidos e execute as atualizações condicionais em seu próprios dados.