DynamoDB leituras fortemente vs eventualmente consistentes

Você atualiza um item, lê-o imediatamente e obtém o valor antigo. A escrita bem-sucedido - um momento depois, a mesma leitura retorna o novo valor. Nada está quebrado: você atingiu a leitura padrão eventualmente consistente do DynamoDB e pode cancelar por solicitação.

Este é um dos poucos botões de correção que o DynamoDB entrega diretamente a você e possui um preço real anexado. Acertar é saber o que cada modalidade garante, o que custa e onde leituras fortes simplesmente não estão disponíveis.

Qual é a diferença entre leituras fortes e eventualmente consistentes no DynamoDB?

Uma leitura eventualmente consistente (o padrão) é servida por qualquer réplica, de modo que ela pode retornar brevemente dados obsoletos logo após uma gravação, mas custa metade do preço. Uma leitura fortemente consistente, ativada por solicitação com ConsistentRead=true, é roteada para o líder da partição e sempre reflete cada gravação confirmada – com 2× a capacidade de leitura.

Eventualmente consistente (o padrão) — pode retornar brevemente dados obsoletos logo após uma escrita. Modo de leitura mais barato.
Fortemente consistente — sempre reflete cada gravação confirmada antes da leitura. Ative por solicitação com ConsistentRead=true.
Leituras fortes custam 2× eventuais. Uma leitura fortemente consistente consome o dobro capacidade de leitura de uma capacidade eventualmente consistente para os mesmos dados.
Não em todos os lugares. Você obtém leituras fortes na tabela base e em um Local Índice Secundário. Um Índice Secundário Global é apenas eventual — sem adesão.
Padrão para eventual. Alcance forte apenas ao ler seu próprio texto recém-escrito dados e obsoletos por momento seriam errados.

O problema: uma leitura que não vê a última gravação

Digamos que você administre contas de usuário. Um usuário altera seu e-mail de notificação, seu aplicativo escreve a atualização e a tela de confirmação relê imediatamente o perfil para mostrar o novo endereço. Com o modo de leitura padrão, essa releitura pode chegar a uma réplica que ainda não recebeu a alteração - então o usuário vê seu e-mail antigo e assume o falha ao salvar.

A janela é pequena (normalmente menos de um segundo) e fecha sozinha. Mas "geralmente correto" não é suficiente para uma confirmação de leitura após gravação. Isso é exatamente o caso para o qual existe uma consistência forte.

Por que a consistência eventual acontece

O DynamoDB armazena cada partição em três nós de armazenamento — um primário e dois réplicas — em zonas de disponibilidade separadas. Uma gravação é reconhecida assim que chega no primário e em uma réplica; ele então se propaga para o terceiro nó assincronamente.

As leituras, para distribuir a carga, podem ser atendidas por qualquer um dos três nós. Um eventualmente leitura consistente pode atingir um nó que ainda não recebeu sua gravação mais recente - então retorna um valor ligeiramente obsoleto. Uma leitura fortemente consistente é encaminhada para o líder da partição, que sempre contém os dados confirmados mais recentes, para que nunca retorna resultados obsoletos.

Esse atraso de replicação é toda a diferença. Também explica o custo 2×: leituras fortes não podem ter balanceamento de carga entre réplicas da mesma forma que leituras eventuais, então O DynamoDB custa o dobro da capacidade.

O custo, concretizado

As leituras são medidas em Unidades de capacidade de leitura (RCU), cada uma cobrindo até 4 KB. Uma unidade remota compra uma leitura fortemente consistente ou duas leituras eventualmente consistentes de 4 KB item. Portanto, inverter o ConsistentRead=true em um caminho de leitura a quente dobra seu custo de leitura - em um endpoint de alto tráfego que é um item de linha que você notará.

Modele a diferença para seus próprios tamanhos de itens e solicite taxas com o Calculadora de preços DynamoDB antes de fazer forte lê seu padrão - raramente vale a pena pagar duas vezes.

Onde leituras fortes estão (e não estão) disponíveis

Leia contra	Fortemente consistente?
Mesa base	Sim – opte por `ConsistentRead=true`
Índice Secundário Local (LSI)	Sim — mesma opção da tabela base
Índice Secundário Global (GSI)	Não — apenas eventual, sem substituição

Um GSI mantém sua própria cópia dos dados, replicada da tabela base de forma assíncrona, para que nunca possa oferecer uma leitura forte. Se um padrão de acesso genuinamente precisa de leitura após gravação e você estava planejando servi-lo a partir de um GSI, isso é um sinal para servi-lo na mesa base ou em um LSI.

Armadilhas + próximos passos

Não faça leituras fortes como padrão. A maioria das leituras tolera um obsoleto inferior a um segundo janela; pagar 2× em todos os lugares é desperdício.
Não espere leitura após gravação de um GSI. É eventual por design - consulte por que um GSI é eventualmente consistente.
Transações lidas fortemente. TransactGetItems é sempre fortemente consistente — consulte transações DynamoDB.
A consistência interage com a capacidade. O multiplicador 2× se liga diretamente Planejamento de custos on-demand vs. provisionado.

Quer explorar suas tabelas e índices DynamoDB sem gravar chamadas API? Baixe DynoTable e inspecione seus dados diretamente.

Comparação RCU trabalhada

Duas leituras do mesmo item de 6 KB na tabela base:

Modo	Blocos de 4 KB	RCU consumido	Quando usar
Fortemente consistente	2 (arredondamentos de 6 KB)	2 RCU	Telas de confirmação após sua própria escrita
Eventualmente consistente	2	1 RCU	Painéis, listas, análises

Com 1.000 leituras por segundo, o modo forte custa aproximadamente o dobro do custo on-demand leia o gasto do modo eventual - modele o delta no calculadora de preços antes de lançar um hot caminho para ConsistentRead=true globalmente.

Consistência BatchGetItem

Cada entrada da tabela no BatchGetItem pode definir o ConsistentRead de forma independente. Um painel que carrega um perfil de usuário (forte) e configurações relacionadas (eventual) pode misture sinalizadores em uma chamada em lote - ainda sujeito à leitura forte por tabela regras de disponibilidade (não fortes no GSI).

Leitura após gravação no código do aplicativo

Padrão para confirmação de atualização de perfil:

UpdateItem com novo e-mail.
GetItem imediato com ConsistentRead: true na mesa base.

Passo 2 custa 2× o RCU de uma eventual leitura mas garante a confirmação tela corresponde à gravação. Ignore leituras fortes em agregações de segundo plano que tolerar atraso de menos de um segundo.

Padrões do DynoTable

Leituras exploratórias no DynoTable usam consultas de tabela base eventualmente consistentes a menos que você opte por uma semântica mais forte em configurações avançadas - correspondendo à maioria casos de uso do painel. Depois de preparar uma gravação, a atualização do editor de itens mostra valores comprometidos da resposta bem-sucedida sem uma consistência separada alterne para o caminho comum.

Use o construtor de consultas para emitir leituras de amostra com ConsistentRead definido explicitamente ao copiar o código SDK em serviços que precisam garantias de leitura após gravação.

Nota sobre tabelas globaisAs tabelas globais são replicadas de forma assíncrona entre regiões. Aplica-se consistência forte

dentro da réplica de uma região, não globalmente. Uma gravação em us-east-1 não é legível instantaneamente no eu-west-1 - planeje o UX entre regiões de acordo. Consulte tabelas globais para ver as expectativas de atraso de replicação.