As seções a seguir descrevem os conceitos e os comportamentos das tabelas globais no Amazon DynamoDB.
Conceitos de tabela global
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. Para obter mais informações sobre conceitos básicos de tabelas globais, consulte Tutorial: criar uma tabela global.
Quando uma tabela global do DynamoDB é criada, ela 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.
Você pode adicionar tabelas-réplica à tabela global para que ela fique disponível em outras regiões.
Com a versão 2019.11.21 (atual), quando você cria um índice secundário global em uma região, ele é automaticamente replicado para as outras regiões, bem como automaticamente preenchido.
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. Você pode copiar a tabela global em uma tabela local nessa região e, depois, excluir a réplica global dessa região.
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:
Permitir gravações na tabela somente em uma região.
Rotear o tráfego de usuários para diferentes regiões de acordo com suas políticas de gravação, a fim de garantir que não haja conflitos.
Evitar o uso de atualizações não idempotentes, como Marcador = Marcador + 1, em favor de atualizações estáticas, como Marcador = 25.
Lembre-se de que, quando você precisa direcionar gravações ou leituras para uma região, cabe à aplicação garantir que o fluxo seja seguido.
Monitorar tabelas globais
Você pode usar o CloudWatch para observar a métrica ReplicationLatency. Isso registra o tempo decorrido entre quando um item foi gravado em uma tabela de réplicas e quando ele aparece em outra réplica na tabela global. É expressa em milissegundos e emitida para cada par de regiões de origem e destino. Essa métrica é mantida na região de origem. Essa é a única métrica do CloudWatch fornecida pelo Global Tables v2.
A latência de replicação que você experimentará dependerá da distância entre as Regiões da AWS escolhidas, bem como de outras variáveis. Se a tabela original estivesse na região Oeste dos EUA (Norte da Califórnia) (us-west-1), uma réplica em uma região mais próxima, como a região Oeste dos EUA (Oregon) (us-west-2), teria menor latência de replicação em comparação com uma réplica em uma região bem mais distante, como África (Cidade do Cabo) (af-south-1).
nota
A latência da replicação não afeta a latência da API. Se você tiver um cliente e uma tabela na região A e incluir uma réplica de tabelas globais na região B, o cliente e a tabela na região A terão a mesma latência de antes de incluir a região B. Se você chamar a operação de API PutItem na região B, em algum momento ela estará disponível para leitura na região A, após um atraso próximo à estatística de ReplicationLatency disponível no Amazon CloudWatch. Antes da replicação, você receberia uma resposta vazia e, depois da aplicação, receberia o item; as duas chamadas teriam aproximadamente a mesma latência de API.
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 é fornecido como um número em segundos desde o início do epoch do Unix. Depois desse período, o DynamoDB poderá excluir o item sem incorrer em custos de gravação.
Com tabelas globais, você configura a TTL em uma região, e essa configuração é replicada automaticamente para as outras regiões. Quando um item é excluído por meio de uma regra de TTL, esse trabalho é executado sem consumir unidades de gravação na tabela de origem, mas as tabelas de destino incorrerão em custos de unidade de gravação replicada.
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 operação TransactWriteItems 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 forem 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 ele está mantendo dados obsoletos. O cache do DAX só será atualizado quando a TTL do cache expirar.
As tags 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 ajuste de escala automático ou estiver no modo sob demanda, a sincronização da capacidade de gravação será automática. Isso significa que uma alteração na capacidade de gravação em uma tabela é replicada para as outras.
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, é possível 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. 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 sua aplicação exigir leituras fortemente consistentes, ela precisará executar todas as suas leituras e gravações fortemente consistentes na mesma região. O DynamoDB não comporta leituras altamente consistentes entre regiões. Portanto, se você gravar em uma região e ler em outra, a resposta lida poderá incluir dados obsoletos que não refletem 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. Isso é realizado no nível do item. 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 tornar-se isolada ou degradada, o DynamoDB acompanhará as gravações executadas que ainda não foram propagadas para todas as tabelas de 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 retoma a propagação de gravações de outras tabelas de réplica para a região que está novamente on-line.
