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

O modo de gravação em uma região é ativo-passivo e encaminha todas as operações de gravação da tabela para uma única região ativa. (O DynamoDB não tem a noção de uma única região ativa; a camada externa do DynamoDB gerencia isso.) O modo de gravação em uma região evita conflitos de gravação, garantindo 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, então 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. As operações de leitura altamente consistentes devem ir para a única região primária.

Às vezes, é necessário alterar 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 perto da geografia que tem mais atividade (geralmente onde é diurno, 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 desastres.

As regiões passivas podem manter uma infraestrutura reduzida em torno do DynamoDB, que é construída somente se ela se tornar a região ativa. Este guia não aborda a luz piloto e os designs de espera quente. Para obter mais informações, você pode ler a postagem do blog Disaster Recovery (DR) Architecture on AWS, Part 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 distribuídas globalmente e de baixa latência. 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, gravam em apenas uma região para evitar possíveis conflitos de gravação. As operações de leitura sempre são 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 o modo de gravação em uma região para rastrear os pagamentos de reembolso. Se quiserem recompensar um centavo por cada $10 gastos, devem calcular Query o total gasto em todas as transações do dia anterior, registrar a decisão de reembolso em uma nova tabela, excluir o conjunto de itens consultados para marcá-los como consumidos e substituí-los por um único item que armazene o restante que deva ser incluído nos cálculos do dia seguinte. Esse trabalho requer transações, por isso funciona melhor com o modo de gravação em uma região. Um aplicativo pode misturar modos de gravação, mesmo na mesma tabela, desde que as cargas de trabalho não tenham chance de se sobrepor.