Modo de gravação em uma região (primária única)

O modo de gravação em uma região é ativo-passivo e direciona todas as operações de gravação de tabela para uma única região ativa. (O DynamoDB não tem a noção de uma única região ativa; a camada externa ao DynamoDB gerencia isso.) O modo de gravação em uma região evita conflitos de gravação ao garantir que as operações de gravação fluam somente para uma região por vez. Esse modo de gravação ajuda quando você deseja usar expressões ou transações condicionais. Essas expressões não são possíveis a menos que você saiba que está agindo com base nos dados mais recentes. Portanto, elas exigem o envio de todas as solicitações de gravação para uma única região que tenha os dados mais recentes.

Eventualmente, operações de leitura consistentes podem ir para qualquer uma das regiões de réplica para obter latências mais baixas. Operações de leitura altamente consistentes devem ir para a única região primária.

Às vezes, é necessário mudar a região ativa em resposta a uma falha regional, conforme discutido posteriormente. Alguns usuários alteram a região atualmente ativa regularmente, como a implementação de uma follow-the-sunimplantação. Isso coloca a região ativa próxima à geografia que tem mais atividade (geralmente onde é dia, daí o nome), o que resulta nas operações de leitura e gravação de menor latência. Ele também tem a vantagem de chamar o código que muda de região diariamente e garantir que ele seja bem testado antes de qualquer recuperação de desastre.

As regiões passivas podem manter uma infraestrutura reduzida em torno do DynamoDB, que só será construída se ele se tornar a região ativa. Este guia não aborda designs de iluminação piloto e de espera quente. Para obter mais informações, você pode ler a postagem do blog Arquitetura de recuperação de desastres (DR) na AWS Parte III: Pilot Light and Warm Standby.

Usar o modo de gravação em uma região funciona bem quando você usa tabelas globais para operações de leitura de baixa latência distribuídas globalmente. Um exemplo é uma grande empresa de mídia social que precisa ter os mesmos dados de referência disponíveis em todas as regiões do mundo. Eles não atualizam os dados com frequência, mas quando o fazem, escrevem em apenas uma região para evitar possíveis conflitos de gravação. As operações de leitura são sempre permitidas em qualquer região.

Como outro exemplo, considere a empresa de serviços financeiros discutida anteriormente que implementou o cálculo diário de reembolso. Eles usavam o modo de gravação em qualquer região para calcular o saldo, mas gravavam em um modo de região para rastrear os pagamentos de reembolso. Se quiserem recompensar um centavo por cada $10 gastos, devem calcular Query o total gasto, anotar a decisão de reembolso em uma nova tabela, excluir o conjunto de itens consultado para marcá-los como consumidos e substituí-los por um único item que armazene o restante que deva entrar nos cálculos do dia seguinte. Esse trabalho requer transações, portanto, funciona melhor com o modo de gravação em uma região. Um aplicativo pode combinar modos de gravação, mesmo na mesma mesa, desde que as cargas de trabalho não tenham chance de se sobrepor.