As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Tabelas globais: como funcionam
Importante
Esta documentação, destinada à versão 2017.11.29 (herdada) de tabelas globais, deve ser evitada para novas tabelas globais. Os clientes devem usar a versão 2019.11.21 (atual) do Global Tables sempre que possível, pois ela oferece maior flexibilidade, maior eficiência e consome menos capacidade de gravação do que a versão 2017.11.29 (Legacy).
Para determinar qual versão você está usando, consulte Determinar a versão da tabela global que você está usando. Para atualizar tabelas globais existentes da versão 2017.11.29 (herdada) para a versão 2019.11.21 (atual), consulte Atualizar as tabelas globais.
As seções a seguir ajudam você a entender os conceitos e o comportamento das tabelas globais no Amazon DynamoDB.
Conceitos de tabela global para a versão 2017.11.29 (herdada)
Uma tabela global é a coleção de uma ou mais tabelas-réplica, todas pertencentes a uma única conta da AWS.
Uma tabela-réplica (ou simplesmente réplica) é uma única tabela do DynamoDB que funciona como parte de uma tabela global. Cada réplica armazena o mesmo conjunto de itens de dados. Qualquer tabela global só pode ter uma tabela-réplica por região da AWS.
Veja a seguir uma visão geral conceitual de como uma tabela global é criada.
-
Crie uma tabela comum do DynamoDB, com o DynamoDB Streams habilitado, em uma região da AWS.
-
Repita a etapa 1 para todas as outras regiões em que você deseja replicar seus dados.
-
Defina uma tabela global do DynamoDB, com base nas tabelas que você criou.
O AWS Management Console automatiza essas tarefas para que você possa criar uma tabela global de forma rápida e fácil. Para ter mais informações, consulte Criar uma tabela global.
A tabela global resultante do DynamoDB consiste em várias tabelas-réplica, uma por região, que o DynamoDB trata como uma única unidade. Cada réplica possui o mesmo nome de tabela e o mesmo esquema de chave primária. Quando uma aplicação grava dados em uma tabela-réplica em uma região, o DynamoDB propaga automaticamente a gravação para as outras tabelas-réplica nas demais regiões da AWS.
Importante
Para manter os dados da tabela sincronizados, as tabelas globais criam automaticamente os seguintes atributos para cada item:
-
aws:rep:deleting -
aws:rep:updatetime -
aws:rep:updateregion
Não modifique esses atributos ou crie atributos com o mesmo nome.
Você pode adicionar tabelas-réplica à tabela global para que ela fique disponível em outras regiões. (Para fazer isso, a tabela global precisa estar vazia. Em outras palavras, nenhuma das tabelas-réplica pode conter informações.)
Você também pode remover uma tabela-réplica de uma tabela global. Se você fizer isso, a tabela será completamente desassociada da tabela global. Essa tabela que se tornou independente não interagirá mais com a tabela global, e os dados não serão mais propagados de nem para a tabela global.
Atenção
Saiba que a remoção de uma réplica não é um processo atômico. Para garantir um comportamento consistente e o estado conhecido, você pode considerar desviar o tráfego de gravação da aplicação para longe da réplica a ser removida antecipadamente. Depois de removê-la, aguarde até que todos os endpoints da região de réplica mostrem a réplica como desassociada antes de fazer outras gravações nela como sua própria tabela de regiões isolada.
Tarefas comuns
As tarefas comuns para tabelas globais funcionam da maneira a seguir.
Não é possível excluir uma tabela de réplicas de uma tabela global da mesma forma que uma tabela normal. Isso interromperá a replicação nessa região e excluirá a cópia da tabela mantida nessa região. Não é possível romper a replicação e ter cópias da tabela como entidades independentes.
nota
Só será possível excluir uma tabela de origem no mínimo 24 horas depois que ela for usada para iniciar uma nova região. Se você tentar excluí-la antes disso, receberá um erro.
Conflitos poderão ocorrer se as aplicações atualizarem o mesmo item em regiões diferentes e quase ao mesmo tempo. Para garantir a consistência final, as tabelas globais do DynamoDB usam um método do tipo “último gravador ganha” entre as atualizações simultâneas. Todas as réplicas concordarão com a atualização mais recente e serão convertidas em um estado em que todas têm dados idênticos.
nota
Há várias formas de evitar conflitos, incluindo:
Usar uma política do IAM para permitir somente gravações na tabela em uma região.
Usar uma política do IAM para encaminhar usuários para apenas uma região e manter a outra em espera ou rotear alternadamente usuários ímpares para uma região e usuários pares para outra região.
Evitar o uso de atualizações não idempotentes, como Marcador = Marcador + 1, em favor de atualizações estáticas, como Marcador = 25.
Monitorar tabelas globais
Você pode usar CloudWatch para observar a métricaReplicationLatency. Essa métrica rastreia o tempo decorrido entre o momento em que um item atualizado aparece no stream do DynamoDB para uma tabela de réplica e o momento em que esse item aparece em outra réplica na tabela global. ReplicationLatencyé expresso em milissegundos e é emitido para cada par de região de origem e região de destino. Essa é a única CloudWatch métrica fornecida pelo Global Tables v2.
As latências que você observará dependerão da distância entre as regiões escolhidas, bem como de outras variáveis. Latências na faixa de 0,5 a 2,5 segundos para regiões podem ser comuns na mesma área geográfica.
Vida útil (TTL)
Você pode usar a vida útil (TTL) para especificar um nome de atributo cujo valor indica a hora de expiração do item. Esse valor é especificado como um número em segundos desde o início da época do Unix.
Com a versão legada das tabelas globais, as exclusões de TTL não são replicadas automaticamente em outras réplicas. Quando um item é excluído por meio de uma regra TTL, esse trabalho é executado sem consumir unidades de gravação.
Lembre-se de que, se as tabelas de origem e de destino tiverem uma capacidade de gravação provisionada muito baixa, isso poderá acionar o controle de utilização, pois as exclusões por TTL exigem capacidade de gravação.
Fluxos e transações com tabelas globais
Cada tabela global produz um fluxo independente com base em todas as gravações, seja qual for o ponto de origem dessas gravações. Você pode optar por consumir esse fluxo do DynamoDB em uma região ou em todas as regiões de forma independente.
Se você quiser gravações locais processadas, mas não gravações replicadas, poderá adicionar seu próprio atributo de região a cada item. Depois, você pode usar um filtro de eventos do Lambda para invocar somente o Lambda para gravações na região local.
As operações transacionais fornecem garantia de atomicidade, consistência, isolamento e durabilidade (ACID) SOMENTE na região em que a gravação é realizada originalmente. As transações não são compatíveis entre regiões em tabelas globais.
Por exemplo, se você tiver uma tabela global com réplicas nas regiões Leste dos EUA (Ohio) e Oeste dos EUA (Oregon) e realizar uma TransactWriteItems operação na região Leste dos EUA (Ohio), poderá observar transações parcialmente concluídas na região Oeste dos EUA (Oregon) à medida que as alterações são replicadas. As alterações só serão replicadas para outras regiões quando forem confirmadas na região de origem.
nota
As tabelas globais “contornam” o DynamoDB Accelerator atualizando o DynamoDB diretamente. Por isso, o DAX não saberá que está mantendo dados obsoletos. O cache do DAX só será atualizado quando a TTL do cache expirar.
As etiquetas em tabelas globais não se propagam automaticamente.
Throughput de leitura e gravação
As tabelas globais gerenciam o throughput de leitura e gravação das maneiras a seguir.
A capacidade de gravação deve ser a mesma em todas as instâncias de tabela em todas as regiões.
Com a versão 2019.11.21 (atual), se a tabela estiver configurada para comportar autoescalabilidade ou estiver no modo sob demanda, a sincronização da capacidade de gravação será automática. A quantidade atual de capacidade de gravação provisionada em cada região aumentará e diminuirá de maneira independente dentro dessas configurações de autoescalabilidade sincronizada. Se a tabela for colocada no modo sob demanda, esse modo será sincronizado nas outras réplicas.
A capacidade de leitura pode diferir entre as regiões porque as leituras podem não ser iguais. Ao adicionar uma réplica global a uma tabela, a capacidade da região de origem é propagada. Após a criação, você pode ajustar a capacidade de leitura de uma réplica, e essa nova configuração não é transferida para o outro lado.
Consistência e resolução de conflitos
Todas as alterações feitas em qualquer item de qualquer tabela-réplica serão replicadas para todas as outras réplicas dentro da mesma tabela global. Em uma tabela global, um item recém-gravado geralmente é propagado para todas as tabelas-réplica dentro de poucos segundos.
Com uma tabela global, cada tabela-réplica armazena o mesmo conjunto de itens de dados. O DynamoDB não oferece suporte à replicação parcial de apenas alguns dos itens.
Uma aplicação pode ler e gravar dados em qualquer tabela-réplica. O DynamoDB comporta leituras finais consistentes entre regiões, mas não leituras altamente consistentes entre regiões. Sua aplicação usar somente leituras finais consistentes e emitir leituras somente para uma região da AWS, ela funcionará sem qualquer modificação. No entanto, se a aplicação exigir leituras altamente consistentes, ela precisará executar todas as leituras e gravações altamente consistentes na mesma região. Caso contrário, se você gravar em uma região e ler em outra, a resposta lida poderá incluir dados obsoletos que não refletirão os resultados das gravações concluídas recentemente na outra região.
Conflitos poderão ocorrer se as aplicações atualizarem o mesmo item em regiões diferentes e quase ao mesmo tempo. Para garantir a consistência eventual, as tabelas globais do DynamoDB usam uma conciliação o último a gravar ganha entre as atualizações simultâneas. Com ela, o DynamoDB emprega o melhor esforço para determinar o último a gravar. Com esse mecanismo de resolução de conflitos, todas as réplicas concordarão com a atualização mais recente e serão convertidas para um estado em que todas têm dados idênticos.
Disponibilidade e durabilidade
Se uma única região da AWS se tornar isolada ou degradada, sua aplicação poderá realizar redirecionamentos para uma região diferente e executar leituras e gravações em uma tabela-réplica diferente. Você pode aplicar lógica de negócios personalizada para determinar quando redirecionar solicitações para outras regiões.
Se uma região se tornar isolada ou degradada, o DynamoDB acompanhará as gravações executadas que ainda não foram propagadas para todas as tabelas-réplica. Quando a região voltar a ficar online, o DynamoDB retomará a propagação de todas as gravações pendentes dessa região para as tabelas-réplica nas outras regiões. Ele também retomará a propagação de gravações de outras tabelas-réplica para a região que está online novamente. Todas as gravações anteriores bem-sucedidas serão propagadas em algum momento, não importa por quanto tempo a região permaneça isolada.
