Visão geral das tabelas globais

Fatos importantes

• Há duas versões das tabelas globais: versão 2017.11.29 (antiga) (às vezes chamada de v1) e versão 2019.11.21 (atual) (às vezes chamada de v2). Este guia se concentra exclusivamente na versão atual.

• O DynamoDB (sem tabelas globais) é um serviço regional, o que significa que é altamente disponível e intrinsecamente resiliente a falhas de infraestrutura, incluindo a falha de uma zona de disponibilidade inteira. Uma tabela do DynamoDB de região única foi projetada para oferecer disponibilidade de 99,99%. Para obter mais informações, consulte o contrato de nível de serviço (SLA) do DynamoDB.

• Uma tabela global do DynamoDB replica seus dados entre duas ou mais regiões. Uma tabela multirregional do DynamoDB foi projetada para oferecer disponibilidade de 99,999%. Com um planejamento adequado, as tabelas globais podem ajudar a criar uma arquitetura resiliente às falhas regionais.

• O DynamoDB não tem um endpoint global. Todas as solicitações são feitas para um endpoint regional que acessa a instância da tabela global que é local dessa região.

• As chamadas para o DynamoDB não devem ser feitas entre regiões. A melhor prática é que um aplicativo hospedado em uma região acesse diretamente somente o endpoint local do DynamoDB de sua região. Se forem detectados problemas em uma região (na camada do DynamoDB ou na pilha ao redor), o tráfego do usuário final deverá ser roteado para um endpoint de aplicativo diferente hospedado em uma região diferente. As tabelas globais garantem que o aplicativo hospedado em cada região tenha acesso aos mesmos dados.

Modos de consistência

Ao criar uma tabela global, você configura seu modo de consistência. As tabelas globais oferecem suporte a dois modos de consistência: consistência eventual em várias regiões (MREC) e consistência forte em várias regiões (MRSC), que foi introduzida em junho de 2025.

Se você não especificar um modo de consistência ao criar uma tabela global, o padrão da tabela global será MREC. Uma tabela global não pode conter réplicas configuradas com modos de consistência diferentes. Você não pode alterar o modo de consistência de uma tabela global após sua criação.

Principais fatos sobre o MREC

• As tabelas globais que usam o MREC empregam um modelo de replicação ativo-ativo. Do ponto de vista do DynamoDB, a tabela em cada região tem a mesma posição para aceitar solicitações de leitura e gravação. Depois de receber uma solicitação de gravação, a tabela de réplica local replica a operação de gravação para outras regiões remotas participantes em segundo plano.

• Os itens são replicados individualmente. Os itens que são atualizados em uma única transação podem não ser replicados juntos.

• Cada partição de tabela na região de origem replica suas operações de gravação em paralelo com todas as outras partições. A sequência de operações de gravação em uma região remota pode não corresponder à sequência de operações de gravação que ocorreram na região de origem. Para obter mais informações sobre partições de tabelas, consulte a postagem do blog Ajuste de escala do DynamoDB: como as partições, as teclas de atalho e a divisão de calor afetam a performance.

• Um item recém-gravado geralmente é propagado para todas as tabelas de réplica em questão de poucos segundos. A propagação tende a ser mais rápida nas regiões próximas.

• A Amazon CloudWatch fornece uma ReplicationLatency métrica para cada par de regiões. É calculado observando os itens que chegam, comparando o tempo de chegada com o tempo de gravação inicial e calculando uma média. Os horários são armazenados CloudWatch na região de origem. A visualização dos tempos médios e máximos pode ajudar a determinar o atraso médio e o maior atraso de replicação. Não há SLA sobre essa latência.

• Se um item individual for atualizado aproximadamente ao mesmo tempo (dentro dessa ReplicationLatency janela) em duas regiões diferentes e a segunda operação de gravação ocorrer antes da replicação da primeira operação de gravação, há a possibilidade de conflitos de gravação. As tabelas globais que usam o MREC resolvem esses conflitos usando um mecanismo de vitórias do último gravador, com base no registro de data e hora das operações de gravação. A primeira operação “perde” para a segunda operação. Esses conflitos não são registrados em CloudWatch ou AWS CloudTrail.

• Cada item tem um carimbo de data/hora da última gravação mantido como uma propriedade privada do sistema. A abordagem do último escritor ganha é implementada usando uma operação de gravação condicional que exige que o timestamp do item recebido seja maior do que o timestamp do item existente.

• Uma tabela global replica todos os itens para todas as regiões participantes. Se quiser ter escopos de replicação diferentes, você pode criar várias tabelas globais e atribuir a cada tabela diferentes regiões participantes.

• A região local aceita operações de gravação mesmo que a região de réplica esteja off-line ou ReplicationLatency cresça. A tabela local continua tentando replicar itens na tabela remota até que cada item seja bem-sucedido.

• No caso improvável de uma região ficar totalmente off-line, quando voltar a ficar on-line posteriormente, todas as replicações pendentes de saída e entrada serão repetidas. Nenhuma ação especial é necessária para sincronizar as tabelas novamente. O mecanismo do último escritor ganha garante que os dados acabem se tornando consistentes.

• Você pode adicionar uma nova região a uma tabela MREC do DynamoDB a qualquer momento. O DynamoDB gerencia a sincronização inicial e a replicação contínua. Você também pode remover uma região (até mesmo a região original), e isso excluirá a tabela local nessa região.

Principais fatos sobre o MRSC

• As tabelas globais que usam o MRSC também empregam um modelo de replicação ativo-ativo. Do ponto de vista do DynamoDB, a tabela em cada região tem a mesma posição para aceitar solicitações de leitura e gravação. As alterações de item em uma réplica da tabela global do MRSC são replicadas de forma síncrona em pelo menos uma outra região antes que a operação de gravação retorne uma resposta bem-sucedida.

• Operações de leitura altamente consistentes em qualquer réplica do MRSC sempre retornam a versão mais recente de um item. As operações de gravação condicional sempre avaliam a expressão da condição em relação à versão mais recente de um item. As atualizações sempre funcionam com a versão mais recente de um item.

• Eventualmente, operações de leitura consistentes em uma réplica do MRSC podem não incluir alterações que ocorreram recentemente em outra região e podem nem mesmo incluir alterações que ocorreram muito recentemente na mesma região.

• Uma operação de gravação falha com uma ReplicatedWriteConflictException exceção quando tenta modificar um item que já está sendo modificado em outra região. As operações de gravação que falham com a ReplicatedWriteConflictException exceção podem ser repetidas e serão bem-sucedidas se o item não estiver mais sendo modificado em outra região.

• Com o MRSC, as latências são maiores para operações de gravação e para operações de leitura altamente consistentes. Essas operações exigem comunicação entre regiões. Essa comunicação tende a adicionar latência que aumenta com base na latência de ida e volta entre a região que está sendo acessada e a região mais próxima que participa da tabela global. (Para obter mais informações, consulte a apresentação do AWS re:Invent 2024, Multi-Region Strong consistency with Amazon DynamoDB global tables.) Eventualmente, operações de leitura consistentes não apresentam latência extra. Existe uma ferramenta de teste de código aberto que permite calcular experimentalmente essas latências com suas regiões.

• Os itens são replicados individualmente. As tabelas globais que usam o MRSC não suportam a transação APIs.

• Uma tabela global do MRSC deve ser implantada em exatamente três regiões. Você pode configurar uma tabela global MRSC com três réplicas ou com duas réplicas e uma testemunha. Uma testemunha é um componente de uma tabela global do MRSC que contém dados recentes gravados em réplicas da tabela global. Uma testemunha fornece uma alternativa opcional para uma réplica completa e, ao mesmo tempo, oferece suporte à arquitetura de disponibilidade do MRSC. Você não pode realizar operações de leitura ou gravação em uma testemunha. Uma testemunha não incorre em custos de armazenamento ou gravação. Uma testemunha está localizada em uma região diferente das duas réplicas.

• Para criar uma tabela global MRSC, você adiciona uma réplica e uma testemunha, ou adiciona duas réplicas a uma tabela existente do DynamoDB que não contém dados. Você não pode adicionar réplicas adicionais a uma tabela global MRSC existente. Você não pode excluir uma única réplica ou uma testemunha de uma tabela global do MRSC. Você pode excluir duas réplicas, ou excluir uma réplica e uma testemunha, de uma tabela global do MRSC. O segundo cenário converte a réplica restante em uma tabela do DynamoDB de região única.

• Você pode determinar se uma tabela global do MRSC tem uma testemunha configurada e em qual região ela está configurada a partir da saída da DescribeTableAPI. A testemunha pertence e é gerenciada pelo DynamoDB e não aparece na Conta da AWS sua região em que está configurada.

• As tabelas globais do MRSC estão disponíveis nos seguintes conjuntos de regiões:

  • Conjunto de regiões dos EUA: Leste dos EUA (Norte da Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon)

  • Conjunto de regiões da Europa: Europa (Irlanda), Europa (Londres), Europa (Paris), Europa (Frankfurt)

  • Conjunto de regiões AP: Ásia-Pacífico (Tóquio), Ásia-Pacífico (Seul) e Ásia-Pacífico (Osaka)

• As tabelas globais do MRSC não podem abranger conjuntos de regiões. Por exemplo, uma tabela global do MRSC não pode conter réplicas dos conjuntos de regiões dos EUA e da UE.

• O Time to Live (TTL) não é suportado pelas tabelas globais do MRSC.

• Os índices secundários locais (LSIs) não são suportados pelas tabelas globais do MRSC.

• CloudWatch As informações do Contributor Insights são relatadas somente para a região em que a operação ocorreu.

• A região local aceita todas as operações de leitura e gravação, desde que uma segunda região que hospede uma réplica ou testemunha esteja disponível para estabelecer o quórum. Se uma segunda região não estiver disponível, a região local poderá atender somente leituras eventualmente consistentes.

• No caso improvável de uma região ficar totalmente offline, quando voltar a ficar online mais tarde, ela se atualizará automaticamente. Até que sejam recuperadas, as operações de gravação e as operações de leitura fortemente consistentes retornarão erros. No entanto, eventualmente, operações de leitura consistentes retornarão os dados que foram propagados até agora na região, com o comportamento usual de consistência local entre o nó líder e as réplicas locais. Nenhuma ação especial é necessária para que as mesas voltem a sincronizar

Casos de uso

As tabelas globais do MREC oferecem os seguintes benefícios:

• Operações de leitura de baixa latência. Você pode colocar uma cópia dos dados mais perto do usuário final para reduzir a latência da rede durante as operações de leitura. Os dados são mantidos tão atualizados quanto o ReplicationLatency valor.

• Operações de gravação de baixa latência. Um usuário final pode gravar em uma região próxima para reduzir a latência da rede e o tempo necessário para concluir a operação de gravação. O tráfego de gravação deve ser roteado cuidadosamente para garantir que não haja conflitos. As técnicas de roteamento são discutidas em uma seção posterior.

• Migração entre regiões sem interrupção. Você pode adicionar uma nova região e, em seguida, excluir a região antiga para migrar uma implantação de uma região para outra, sem nenhum tempo de inatividade na camada de dados.

As tabelas globais do MREC e do MRSC oferecem esse benefício:

• Maior resiliência e recuperação de desastres. Se uma região tiver um desempenho degradado ou uma interrupção total, você poderá evacuá-la (ou seja, afastar algumas ou todas as solicitações que vão para essa região). O uso de tabelas globais aumenta o SLA do DynamoDB para a porcentagem de tempo de atividade mensal de 99,99% para 99,999%. O uso do MREC suporta um objetivo de ponto de recuperação (RPO) e um objetivo de tempo de recuperação (RTO) medidos em segundos. O uso do MRSC oferece suporte a um RPO zero.

  Por exemplo, a Fidelity Investments apresentou na re:Invent 2022 sobre como eles usam as tabelas globais do DynamoDB em seu sistema de gerenciamento de pedidos. Seu objetivo era alcançar um processamento confiável de baixa latência em uma escala que eles não poderiam atingir com o processamento local e, ao mesmo tempo, manter a resiliência às falhas regionais e da zona de disponibilidade.

Se sua meta é resiliência e recuperação de desastres, as tabelas MRSC têm latências de gravação mais altas e latências de leitura altamente consistentes, mas oferecem suporte a um RPO zero. As tabelas globais do MREC oferecem suporte a um RPO igual ao atraso de replicação entre as réplicas — geralmente alguns segundos, dependendo das regiões da réplica. Para obter mais informações, consulte Modos de consistência na documentação do DynamoDB.