DynamoDB Operações em lote

Quando você precisar ler ou escrever muitos itens de uma vez, disparando um GetItem ou PutItem por item significa uma viagem de ida e volta de rede por item – lenta e tagarela. Lote de DynamoDB APIs dobra muitas operações de item em uma única solicitação: BatchGetItem para leituras, BatchWriteItem para gravações.

Eles são uma vitória em termos de rendimento e latência, não uma garantia de consistência — e isso distinção é onde as pessoas se queimam. Um lote não é uma transação.

O que são operações em lote DynamoDB?

As operações em lote DynamoDB agrupam muitas leituras ou gravações de itens em uma única solicitação: BatchGetItem busca até 100 itens, BatchWriteItem coloca ou exclui até 25, cada um limitado a 16 MB. Eles economizam viagens de ida e volta, não capacidade. É importante ressaltar que um lote não é uma transação – os itens são bem-sucedidos ou falham de forma independente, sem reversão.

• BatchGetItem — busca até 100 itens (ou 16 MB) em uma ou mais tabelas em uma chamada.
• BatchWriteItem — até 25 operações de colocação/exclusão (ou 16 MB) em uma chamada. Sem atualizações – apenas coloca e exclui.
• Não atômico. Itens individuais podem ter sucesso enquanto outros falham. Não há reversão.
• Falha parcial é normal. Itens limitados voltam em UnprocessedItems / UnprocessedKeys — você mesmo deve tentar novamente, com espera.
• Mesmo custo de capacidade das chamadas individuais — o lote economiza viagens de ida e volta, não unidades de capacidade.

O problema: muitos itens, uma viagem de ida e volta

Digamos que você administre um balcão de suporte. Um painel precisa carregar 50 tickets por ID para renderizar um fila; um trabalho noturno arquiva 1.000 tickets resolvidos. Fazendo um item de cada vez são 50 (ou 1.000) viagens de ida e volta sequenciais – a latência aumenta e o trabalho rasteja.

O lote os resume em um punhado de chamadas. A leitura de 50 ingressos torna-se uma única BatchGetItem; o trabalho de arquivamento se torna um fluxo de chamadas BatchWriteItem de 25 exclui cada um. Muito menos viagens de ida e volta, os mesmos dados foram movidos.

Como funciona o lote APIs

BatchGetItem pega um conjunto de chaves primárias (em uma ou mais tabelas) e retorna os itens correspondentes. Você pode solicitar leituras fortemente consistentes por tabela. Qualquer coisa não foi possível ler — geralmente porque a solicitação ultrapassou um limite de taxa de transferência — volta UnprocessedKeys em vez de falhar em toda a chamada.

BatchWriteItem pega uma lista de operações PutRequest / DeleteRequest. Nota o que está faltando: não há atualização. Uma gravação em lote substitui um item inteiro (colocar) ou removê-lo (excluir) — para modificar atributos específicos que você ainda precisa UpdateItem. Os itens que não foi possível gravar voltam em UnprocessedItems.

Um lote é um pacote de operações independentes, cada uma ter sucesso ou falhar por si só – e não uma unidade de tudo ou nada.

Lotes não são transações

Esta é a armadilha. Se o lote da sua tarefa de arquivamento atingir um limite de produtividade na metade, alguns tickets são excluídos e alguns não - e DynamoDB não desfaz aqueles que passou. Não há reversão, nem isolamento, nem "todos os 25 ou nenhum".

Se você precisar de semântica de tudo ou nada - "mover o ticket para arquivado e diminuir o balcão de ingressos abertos, ou não faça nenhum dos dois" - isso é TransactWriteItems, não um lote. Custo de transações mais (cada operação é cobrada em dobro) e limite de 100 itens, mas eles dão a você a lotes de atomicidade deliberadamente não.

Manuseio de itens não processados

Um chamador de lote correto sempre verifica o conjunto não processado e tenta novamente. DynamoDB retorna UnprocessedItems/UnprocessedKeys sempre que a solicitação como um todo foi aceito, mas alguns itens não puderam ser veiculados — normalmente limitação transitória.

Reenvie apenas os itens não processados, com recuo exponencial e jitter. Tratar um lote como disparar e esquecer elimina silenciosamente as gravações - o tipo de bug que surgem meses depois como dados ausentes.

Gravações em lote em DynoTable

Estime quanto custará um trabalho em massa primeiro com o DynamoDB calculadora de preços — um lote consome o mesma capacidade que o indivíduo escreve em pacotes, apenas em menos solicitações.

Em DynoTable, você prepara suas edições localmente e as revisa antes de confirmá-las — alterações em massa em muitas linhas saem como solicitações agrupadas em vez de uma chamada API cada um. As exclusões em massa saem como gravações em lote, com a repetição do item não processado tratada para você.

Armadilhas + próximos passos

• Sempre tente novamente UnprocessedItems/UnprocessedKeys com espera - eles são esperado, não excepcional.
• Sem reversão de falha parcial. Precisa de atomicidade? Usar transações.
• Sem atualizações em uma gravação em lote — BatchWriteItem é apenas colocado/excluído; alcançar UpdateItem para alterar atributos.
• Cuidado com os limites por chamada — 25 gravações/100 leituras/16 MB. Excedê-los falha toda a chamada com uma ValidationException (muitos itens em BatchGetItem, em BatchWriteItem). Página através de empregos maiores; veja paginação.

Quer executar leituras e gravações em massa sem criar scripts no loop de nova tentativa? Baixe DynoTable e edite suas tabelas diretamente.

Matemática de ida e volta

Chamadas seriais GetItem pagam latência por salto. BatchGetItem agrupa até 100 chaves ou 16 MB por solicitação — o limite atingido primeiro.

O custo da capacidade permanece inalterado — o processamento em lote economiza o tempo do relógio e a CPU do cliente, e não RCU. Para gravações, 1.000 exclusões a 25 por lote equivalem a 40 chamadas BatchWriteItem em vez de 1.000 exclusões individuais.

Leituras em lote fortemente consistentes

BatchGetItem aceita ConsistentRead: true por tabela no mapa de solicitação. Leituras fortes ainda custam 2× o RCU de leituras eventuais para os mesmos itens. Misturando tabelas consistentes e eventuais em uma chamada em lote são adequadas - cada entrada da tabela carrega sua própria bandeira.

Agrupando trabalhos grandes

Ao arquivar 1.000 itens com média de 3 KB cada, uma única leitura em lote permanece sob o limite de 100 itens, mas pode exceder 16 MB (100 × 3 KB = 300 KB – seguro). Arquivo Itens de 50 KB e você atingirá o limite de megabytes em torno de 320 itens por chamada, embora o limite de contagem é 100.

Gravações de páginas com loops explícitos:

for each chunk of 25 keys:
  BatchWriteItem
  retry UnprocessedItems with backoff until empty

Os lotes de commits preparados de DynoTable gravam e tentam novamente itens não processados automaticamente – o padrão que você usaria de outra forma com sono agitado.

Decisão de lote versus transação

Gere cargas úteis de colocar/excluir a partir de JSON simples com o DynamoDB JSON conversor ao semear o lote cargas de luminárias.

Inspecione a capacidade consumida

As respostas em lote podem incluir ConsumedCapacity por tabela quando solicitado. Registre-o durante preenchimentos - uma taxa de aceleração crescente aparece à medida que crescem conjuntos não processados antes que os trabalhos parem completamente. Verificação cruzada sustentada WCU com o calculadora de preços se os lotes forem executados em um cronograma.