Modo de gravação em qualquer região (sem primária) - AWS Orientação prescritiva

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á.

Modo de gravação em qualquer região (sem primária)

O modo de gravação em qualquer região, ilustrado no diagrama a seguir, é totalmente ativo-ativo e não impõe restrições sobre onde uma operação de gravação pode ocorrer. Qualquer região pode aceitar uma solicitação por escrito a qualquer momento. Esse é o modo mais simples; no entanto, ele pode ser usado somente com alguns tipos de aplicativos. Esse modo é adequado para todas as tabelas MRSC. Também é adequado para tabelas MREC quando todas as operações de gravação são idempotentes. Idempotente significa que elas podem ser reproduzidas com segurança para que as operações de gravação simultâneas ou repetidas entre regiões não entrem em conflito, por exemplo, quando um usuário atualiza seus dados de contato. Também funciona bem para um conjunto de dados somente para anexar, em que todas as operações de gravação são inserções exclusivas sob uma chave primária determinística, que é um caso especial de idempotência. Por fim, esse modo é adequado para MREC, onde o risco de operações de gravação conflitantes é aceitável.

Não há modo de gravação principal nas tabelas globais do DynamoDB.

O modo de gravação em qualquer região é a arquitetura mais simples de implementar. O roteamento é mais fácil porque qualquer região pode ser o destino de gravação a qualquer momento. O failover é mais fácil porque, com as tabelas MRSC, os itens estão sempre sincronizados e, com as tabelas MREC, qualquer operação de gravação recente pode ser repetida quantas vezes quiser em qualquer região secundária. Sempre que possível, defina o design para usar esse modo de gravação.

Por exemplo, vários serviços de streaming de vídeo usam tabelas globais para rastrear favoritos, avaliações, sinalizadores de status de exibição e assim por diante. Essas implantações usam tabelas MREC porque precisam de réplicas espalhadas por todo o mundo, com cada réplica fornecendo operações de leitura e gravação de baixa latência. Essas implantações podem usar a gravação em qualquer modo de região, desde que garantam que cada operação de gravação seja idempotente. Esse será o caso se cada atualização — por exemplo, definir um novo código de horário mais recente, atribuir uma nova avaliação ou definir um novo status do relógio — atribuir diretamente o novo estado do usuário, e o próximo valor correto para um item não depender de seu valor atual. Se, por acaso, as solicitações de gravação do usuário forem encaminhadas para regiões diferentes, a última operação de gravação persistirá e o estado global será estabelecido de acordo com a última atribuição. As operações de leitura nesse modo acabarão se tornando consistentes, atrasadas pelo ReplicationLatency valor mais recente.

Em outro exemplo, uma empresa de serviços financeiros usa tabelas globais como parte de um sistema para manter um registro contínuo das compras com cartão de débito para cada cliente, a fim de calcular as recompensas de cashback desse cliente. Eles querem manter um RunningBalance item por cliente. Esse modo de gravação não é naturalmente idempotente porque, à medida que as transações chegam, elas modificam o saldo usando uma ADD expressão em que o novo valor correto depende do valor atual. Ao usar tabelas MRSC, eles ainda podem gravar em qualquer região, porque cada ADD chamada sempre opera com base no valor mais recente do item.

Um terceiro exemplo envolve uma empresa que fornece serviços de colocação de anúncios on-line. Essa empresa decidiu que um baixo risco de perda de dados seria aceitável para obter as simplificações de design da gravação em qualquer modo de região. Quando veiculam anúncios, eles têm apenas alguns milissegundos para recuperar metadados suficientes para determinar qual anúncio exibir e, em seguida, registrar a impressão do anúncio para que não repitam o mesmo anúncio em breve. Eles usam tabelas globais para obter operações de leitura de baixa latência para usuários finais em todo o mundo e operações de gravação de baixa latência. Eles registram todas as impressões de anúncios de um usuário em um único item, o que é representado como uma lista crescente. Eles usam um item em vez de anexar a uma coleção de itens, para que possam remover impressões de anúncios mais antigas como parte de cada operação de gravação sem pagar por uma operação de exclusão. Essa operação de gravação não é idempotente; se o mesmo usuário final vê anúncios veiculados em várias regiões aproximadamente ao mesmo tempo, há uma chance de que uma operação de gravação para uma impressão de anúncio substitua outra. O risco é que um usuário veja um anúncio repetido de vez em quando. Eles decidiram que isso é aceitável.