Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

Práticas recomendadas para o design de tabelas globais do DynamoDB

Modo de foco
Práticas recomendadas para o design de tabelas globais do DynamoDB - Amazon 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 fornece performance rápida e local de leitura e gravação para aplicações globais com grande ajuste de escala. Com as tabelas globais, os dados se replicam automaticamente nas regiões da AWS escolhidas por você. Como as tabelas globais usam APIs existentes do DynamoDB, nenhuma alteração será necessária na aplicação. Não há nenhum custo ou compromisso inicial pelo uso de tabelas globais, e você paga apenas pelos recursos que usa.

Orientação prescritiva para o design de tabelas globais do DynamoDB

O uso eficiente de tabelas globais exige considerações cuidadosas de alguns fatores, como seu modo de gravação preferido, 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 leituras e gravações de baixa latência e um acordo de serviço de 99,999%.

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, V2.

  • Sem o uso de tabelas globais, o DynamoDB é um serviço regional. É altamente disponível e intrinsecamente resiliente a falhas de infraestrutura em uma região, incluindo a falha de uma zona de disponibilidade (AZ) inteira. Uma tabela do DynamoDB de região única tem um Acordo de Serviço (SLA) com 99,99% de disponibilidade. https://aws.amazon.com/dynamodb/sla/

  • Com o uso de tabelas globais, o DynamoDB permite que uma tabela replique seus dados entre duas ou mais regiões. Uma tabela multirregional do DynamoDB tem um SLA com 99,999% de disponibilidade. Com um planejamento adequado, as tabelas globais podem ajudar na criação de uma arquitetura que seja resiliente e resistente a falhas regionais.

  • As tabelas globais 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. Depois de receber uma solicitação de gravação, a tabela da réplica local replicará a gravação para outras regiões participantes em segundo plano.

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

  • Cada partição de tabela na região de origem replica suas gravações em paralelo com todas as outras partições. A sequência de gravações na região remota pode não corresponder à sequência de gravações 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. É calculada com base na análise dos itens recebidos e na comparação do horário de chegada com o tempo inicial de gravação para o cálculo de 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 o mesmo item for atualizado aproximadamente ao mesmo tempo (dentro dessa janela de ReplicationLatency) em duas regiões diferentes e a segunda gravação ocorrer antes de a primeira gravação ser replicada, poderão acontecer conflitos de gravação. As tabelas globais resolvem esses conflitos com o mecanismo de último gravador vence, com base no carimbo de data/hora das gravações. A primeira gravação “perde” para a segunda gravação. Esses conflitos não são registrados no CloudWatch ou 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 último gravador vence é implementada usando uma 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 replicará todos os itens em todas as regiões participantes. Se você quiser ter diferentes escopos de replicação, poderá criar tabelas diferentes e definir regiões participantes diferentes para cada uma das tabelas.

  • As gravações serão aceitas na região local mesmo que a região da réplica esteja off-line ou que 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 ela voltar a ficar on-line, todas as replicações pendentes de entrada e saída serão repetidas. Nenhuma ação especial é necessária para sincronizar as tabelas novamente. O mecanismo de último gravador vence garante que os dados acabem se tornando consistentes.

  • Você pode adicionar uma nova região a uma tabela do DynamoDB a qualquer momento. O DynamoDB cuidará da sincronização inicial e da replicação contínua. Se uma região for removida, mesmo que seja a região original, somente a tabela dessa região será excluída.

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

  • As chamadas para o DynamoDB não devem acontecer entre regiões. A prática recomendada é que a camada de computação em uma região acesse diretamente somente o endpoint local do DynamoDB dessa região. Se forem detectados problemas em uma região, sejam eles na camada do DynamoDB ou na pilha circundante, o tráfego do usuário final deverá ser roteado para outra camada de computação hospedada em uma região diferente. Graças à replicação de tabelas globais, a região diferente já terá uma cópia local dos mesmos dados para trabalhar localmente. Em algumas circunstâncias, a camada de computação em uma região pode transmitir a solicitação à camada computacional de outra região para processamento, mas isso não deve acessar diretamente o endpoint remoto do DynamoDB. Para obter mais informações sobre esse caso de uso específico, consulte Roteamento de solicitações na camada de computação.

Casos de uso de tabelas globais do DynamoDB

As tabelas globais oferecem os seguintes benefícios comuns:

  • Leituras com latência mais baixa. Você pode colocar uma cópia dos dados mais perto do usuário final para reduzir a latência de rede durante as leituras. O cache é mantido tão atualizado quanto o valor de ReplicationLatency.

  • Gravações com latência mais baixa. 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 Roteamento de solicitações com tabelas globais do DynamoDB.

  • Maior resiliência e recuperação de desastres. Você pode evacuar uma região (afastar algumas ou todas as solicitações enviadas para essa região) caso a região apresente redução de performance ou interrupção total, com um objetivo de ponto de recuperação (RPO) e um objetivo de tempo de recuperação (RTO) medidos em segundos. O uso de tabelas globais também aumenta o SLA do DynamoDB de 99,99% para 99,999%.

  • 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. Por exemplo, você pode usar tabelas globais do DynamoDB para que um sistema de gerenciamento de pedidos obtenha um processamento confiável de baixa latência e em alta escala e, ao mesmo tempo, manter a resiliência a falhas regionais e de AZ.

PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.