Usar tabelas globais do DynamoDB - Amazon DynamoDB
Fatos importantesFatos importantes sobre MRECFatos importantes sobre MRSCCasos de usoConclusão e atributos

Usar tabelas globais do DynamoDB

As tabelas globais aproveitam a presença global do Amazon DynamoDB para oferecer a você um banco de dados totalmente gerenciado, multiativo e com várias regiões que oferece performance rápida e local de leitura e gravação para aplicações globais com grande ajuste de escala. As tabelas globais replicam as tabelas do Amazon DynamoDB automaticamente nas Regiões da AWS escolhidas por você. Como as tabelas globais usam APIs existentes do DynamoDB, nenhuma alteração na aplicação é necessária. Não há nenhum custo ou compromisso inicial pelo uso de tabelas globais, e você paga apenas pelos recursos que usa.

Este guia explica como usar as tabelas globais do DynamoDB de forma eficaz. Fornece fatos importantes sobre tabelas globais, explica os principais casos de uso do recurso, descreve os dois modos de consistência, apresenta uma taxonomia de três modelos de gravação diferentes que você deve considerar, analisa as quatro principais opções de roteamento de solicitações que você pode implementar, discute maneiras de evacuar uma região ativa ou uma região offline, explica como pensar sobre o planejamento da capacidade de throughput e fornece uma lista de verificação de fatores a serem considerados ao implantar tabelas globais.

Este guia se enquadra em um contexto mais amplo de implantações em várias regiões da AWS, conforme abordado no whitepaper AWS Multi-Region Fundamentals e no vídeo Data resiliency design patterns with AWS.

Tópicos

Fatos importantes sobre o design de tabelas globais do DynamoDB

  • Há duas versões de tabelas globais: a versão atual Global Tables versão 2019.11.21 (atual) (às vezes chamada de “V2”) e Global Tables versão 2017.11.29 (herdada) (às vezes chamada de “V1”). Este guia se concentra exclusivamente na versão atual.

  • O DynamoDB (sem tabelas globais) é um serviço regional, o que significa que ele é altamente disponível e intrinsecamente resiliente a falhas de infraestrutura, incluindo a falha de toda uma zona de disponibilidade. Uma tabela do DynamoDB de região única foi projetada para oferecer disponibilidade de 99,99%. Para obter mais informações, consulte o Acordo 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 na criação de uma arquitetura que seja resiliente a 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 ocorrer entre regiões. A prática recomendada é que uma aplicação hospedada em uma região acesse diretamente apenas o endpoint local do DynamoDB para a sua própria região. Caso problemas sejam detectados dentro de uma região (na camada do DynamoDB ou na pilha relacionada), o tráfego do usuário final deve ser direcionado para um endpoint de aplicação diferente, hospedado em outra região. As tabelas globais garantem que a aplicação hospedada em cada região tenha acesso aos mesmos dados.

Modos de consistência

Ao criar uma tabela global, você pode configurar o modo de consistência. As tabelas globais comportam dois modos de consistência: consistência final multirregional (MREC) e consistência forte multirregional (MRSC), que foi introduzida em junho de 2025.

Se você não especificar um modo de consistência ao criar uma tabela global, ela usará como padrão o MREC. Uma tabela global não pode conter réplicas configuradas com modos de consistência diferentes. Não é possível alterar o modo de consistência de uma tabela global depois da criação.

Fatos importantes sobre MREC

  • As tabelas globais que usam MRSC empregam um modelo de replicação ativa-ativa. 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. Após receber uma solicitação de gravação, a réplica local da tabela reproduz a operação de gravação para as outras regiões remotas participantes em segundo plano.

  • Os itens são replicados individualmente. Os itens 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 na 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.

  • O Amazon CloudWatch fornece uma métrica ReplicationLatency para cada par de regiões. Ela é calculada observando os itens que chegam, comparando o tempo de chegada com o tempo de gravação inicial e calculando uma média. Os tempos são armazenados no 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 janela de ReplicationLatency) em duas regiões diferentes, e a segunda operação de gravação ocorrer antes de a primeira operação ser replicada, poderão ocorrer conflitos de gravação. As tabelas globais que usam MREC resolvem esses conflitos com o mecanismo de último gravador prevalece, com base no carimbo de data/hora das gravações. A primeira operação “perde” para a segunda operação. Esses conflitos não são registrados no CloudWatch nem no AWS CloudTrail.

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

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

  • A região local aceita operações de gravação mesmo que a região da réplica esteja offline ou a ReplicationLatency aumente. 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 offline, quando ela voltar a ficar on-line, todas as replicações pendentes de entrada e saída passarão por uma nova tentativa. Nenhuma ação especial é necessária para sincronizar as tabelas novamente. O mecanismo de o último gravador prevalece 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 cuidará da sincronização inicial e da replicação contínua. Você também pode remover uma região (até mesmo a original), e isso excluirá a tabela local nessa região.

Fatos importantes sobre MRSC

  • As tabelas globais que usam MRSC empregam um modelo de replicação ativa-ativa. 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 MRSC são replicadas de forma síncrona em pelo menos uma outra região antes que a operação de gravação exiba 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 condicionais de gravação 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.

  • Operações de leitura final consistente em uma réplica 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 exceção ReplicatedWriteConflictException quando ela tenta modificar um item que já está sendo modificado em outra região. As operações de gravação que falharem com a exceção ReplicatedWriteConflictException poderão ser repetidas, e serão bem-sucedidas se o item não estiver mais sendo modificado em outra região.

  • Com 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 pode 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 acessar mais informações, consulte a apresentação do AWS re:Invent 2024, Multi-Region strong consistency with DynamoDB global tables. As operações de leitura final consistente 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 MRSC não são compatíveis com APIs de transação.

  • 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 duas réplicas e uma testemunha. Testemunha é um componente de uma tabela MRSC global que contém dados recentes gravados em réplicas da tabela global. Uma testemunha oferece uma alternativa opcional para uma réplica completa e, ao mesmo tempo, comporta a arquitetura de disponibilidade do MRSC. Você não pode realizar operações de leitura ou gravação em uma testemunha. Uma testemunha não gera custos de armazenamento nem gravação. Uma testemunha está localizada em uma região diferente das duas réplicas.

  • Para criar uma tabela MRSC global, adicione uma réplica e uma testemunha ou 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. Não é possível excluir uma única réplica ou testemunha de uma tabela MRSC global. Você pode excluir duas réplicas ou excluir uma réplica e uma testemunha de uma tabela MRSC global. O segundo cenário converte a réplica restante em uma tabela do DynamoDB de região única.

  • Você pode determinar se uma tabela MRSC global possui uma testemunha configurada, e em qual região ela está configurada, com base na saída da API DescribeTable. A testemunha pertence e é gerenciada pelo DynamoDB e não aparece na sua Conta da AWS na 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 da AP: Ásia-Pacífico (Tóquio), Ásia-Pacífico (Seul) e Ásia-Pacífico (Osaka).

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

  • Tempo de vida (TTL) não é aceito em tabelas globais MRSC.

  • Índices secundários locais (LSIs) não são aceitos em tabelas globais MRSC.

  • As informações do CloudWatch Contributor Insights são relatadas somente para a região em que uma 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 uma testemunha esteja disponível para estabelecer o quórum. Se uma segunda região não estiver disponível, a região local poderá fornecer somente leituras finais consistentes.

  • No caso improvável de uma região ficar totalmente offline, quando ela voltar a ficar on-line, ela se atualizará automaticamente. Até que sejam recuperadas, as operações de gravação e as operações de leitura altamente consistentes somente na região em recuperação exibirão erros, enquanto as solicitações para outras regiões continuarão funcionando normalmente. As operações de leitura final consistente para a região em recuperação exibirão os dados que foram propagados até o momento 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 sincronizar as tabelas novamente.

Casos de uso de tabelas globais MREC do DynamoDB

As tabelas globais MREC oferecem os seguintes benefícios:

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

  • Operações de gravação de baixa latência. Você pode gravar em uma região próxima para reduzir a latência de rede e o tempo necessário para realizar a 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 mais detalhes em Estratégias de roteamento do DynamoDB.

  • Migração entre regiões sem interrupção. Você pode adicionar uma nova região, depois 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 MREC e MRSC oferecem este benefício:

  • Maior resiliência e recuperação de desastres. Se uma região tiver uma performance degradada ou uma interrupção total, você poderá evacuá-la. Evacuar significa redirecionar parte ou todas as solicitações que estão indo para essa região. O uso de tabelas globais aumenta o SLA do DynamoDB para a percentagem de tempo de atividade mensal de 99,99% para 99,999%. O uso de MREC comporta um objetivo de ponto de recuperação (RPO) e um objetivo de tempo de recuperação (RTO) medidos em segundos. O uso de MRSC comporta um RPO de zero.

    Por exemplo, a Fidelity Investments fez uma apresentação no re:Invent 2022 sobre como ela usa as tabelas globais do DynamoDB em seu sistema de gerenciamento de pedidos. O objetivo dela era ter um processamento confiável de baixa latência em uma escala que não poderia atingir com o processamento on-premises e, ao mesmo tempo, manter a resiliência a falhas regionais e de zona de disponibilidade.

Se sua meta for 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 consistente, mas comportam um RPO de zero. As tabelas globais MREC aceitam um RPO igual ao atraso de replicação entre as réplicas, geralmente de alguns segundos, dependendo das regiões da réplica.

Conclusão e atributos

As tabelas globais do DynamoDB têm poucos controles, mas ainda exigem uma análise cuidadosa. Você deve determinar seu modo de gravação, modelo de roteamento e processos de evacuação. Você deve instrumentar sua aplicação em todas as regiões e se preparar para ajustar o roteamento ou realizar uma evacuação para manter a integridade global. A recompensa é ter um conjunto de dados distribuído globalmente com operações de leitura e gravação de baixa latência, projetado para oferecer 99,999% de disponibilidade.

Para acessar mais informações sobre tabelas globais do DynamoDB, consulte os seguintes recursos: