Modos de gravação com tabelas globais do DynamoDB
As tabelas globais são sempre ativo-ativas no nível da tabela. No entanto, talvez você queira tratá-las como ativo-passivas ao controlar a forma como roteia as solicitações de gravação. Por exemplo, você pode decidir rotear solicitações de gravação para uma única região a fim de evitar possíveis conflitos de gravação.
Há três categorias principais de padrões de gravação gerenciada:
Modo de gravação em qualquer região (sem primária)
Modo de gravação em uma região (primária única)
Modo de gravação em sua região (primária mista)
Você deve considerar qual padrão de gravação se adapta ao seu caso de uso. Essa escolha afeta a forma como você roteia solicitações, evacua uma região e lida com a recuperação de desastres. As práticas recomendadas gerais podem ser diferentes dependendo do modo de gravação da sua aplicação.
Modo de gravação em qualquer região (sem primária)
O modo de gravação em qualquer região é totalmente ativo-ativo e não impõe nenhuma restrição sobre onde uma gravação pode ocorrer. Qualquer região pode aceitar uma gravação a qualquer momento. Esse é o modo mais simples. Pode ser usado somente com alguns tipos de aplicações. É adequado quando todos os gravadores são idempotentes e, portanto, repetíveis 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. Esse modo também funciona bem para um caso especial de idempotência, um conjunto de dados somente para anexos em que todas as gravações são inserções exclusivas em uma chave primária determinística. Por fim, esse modo é adequado quando o risco de gravações conflitantes é aceitável.
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 qualquer gravação recente pode ser repetida várias vezes em qualquer região secundária. Sempre que possível, defina o design para usar esse modo de gravação.
Por exemplo, os serviços de streaming de vídeo geralmente usam tabelas globais para rastrear favoritos, avaliações, sinalizadores de status de exibição e assim por diante. Essas implantações podem usar o modo de gravação em qualquer região, desde que garantam que cada gravação seja idempotente e que o próximo valor correto de um item não dependa de seu valor atual. Esse será o caso para atualizações do usuário que atribuem diretamente o novo estado ao usuário, como definir um novo código de horário mais recente, atribuir uma nova avaliação ou definir um novo status do relógio. Se 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á resolvido de acordo com a última atribuição. As operações de leitura nesse modo acabarão se tornando consistentes após serem atrasadas pelo valor mais recente de ReplicationLatency.
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. Novas transações chegam do mundo inteiro e vão para várias regiões. O design atual da empresa não aproveita as tabelas globais, pois usa um único item de balancete corrente por cliente. As ações do cliente atualizam o saldo com uma expressão ADD, que não é idempotente porque o novo valor correto depende do valor atual. Isso significa que o saldo ficaria fora de sincronia se houvesse duas operações de gravação no mesmo saldo aproximadamente ao mesmo tempo em regiões diferentes.
Essa mesma empresa poderia implantar o modo de gravação em qualquer região por meio de uma reformulação cuidadosa com as tabelas globais do DynamoDB. O novo design poderia seguir um modelo de “streaming de eventos”, que, essencialmente, é um livro contábil com um fluxo de trabalho somente para anexos. Cada ação do cliente acrescenta um novo item à coleção de itens mantidos para esse cliente. A coleção de itens é o conjunto de itens que compartilham uma chave primária, com chaves de classificação diferentes. Cada ação de gravação que acrescenta a ação do cliente é uma inserção idempotente, usando o ID do cliente como chave de partição e o ID da transação como chave de classificação. Esse design torna o cálculo do saldo mais complicado, pois exige uma Query para extrair os itens seguida de alguns cálculos no lado do cliente. Mas a vantagem é que isso torna todas as gravações idempotentes, o que proporciona simplificações significativas de roteamento e failover. Para ter mais informações, consulte Roteamento de solicitações com tabelas globais do DynamoDB.
Para um terceiro exemplo, digamos que há um cliente que realiza posicionamento de anúncios on-line. O cliente decidiu que um baixo risco de perda de dados seria aceitável para obter as simplificações de design do modo de gravação em qualquer região. Ao veicular anúncios, o cliente tem apenas alguns milissegundos para recuperar metadados suficientes para determinar qual anúncio exibir e, depois, para registrar a impressão do anúncio para que o mesmo anúncio não seja repetido para esse usuário. Com tabelas globais, o cliente pode obter leituras de baixa latência para usuários finais em todo o mundo e gravações de baixa latência. O cliente pode registrar todas as impressões de anúncios de um usuário em um único item e representar isso como uma lista crescente. Também pode usar um item em vez de anexá-lo a uma coleção de itens, pois dessa forma pode remover impressões de anúncios mais antigas como parte de cada gravação sem pagar pela exclusão. Essa operação de gravação NÃO é idempotente. Sendo assim, se o mesmo usuário final ver anúncios veiculados em várias regiões aproximadamente ao mesmo tempo, há uma chance de uma impressão de anúncio substituir a outra. Para o posicionamento de anúncios on-line, vale a pena correr o risco de um usuário ver ocasionalmente um anúncio repetido em troca de usar esse design mais simples e eficiente.
Primária única (“gravação em uma região”)
O modo de gravação em uma região é ativo-passivo e direciona todas as gravações de tabela para uma única região ativa. Observe que o DynamoDB não tem a noção de uma única região ativa; é o roteamento de aplicações fora do DynamoDB que gerencia isso. O modo de gravação em uma região evita conflitos de gravação ao garantir que as gravações fluam somente para uma região por vez. Esse modo de gravação é útil quando você deseja usar expressões ou transações condicionais, porque elas não funcionarão a menos que você saiba que está agindo com base nos dados mais recentes. Portanto, o uso de expressões e transações condicionais exige o envio de todas as solicitações de gravação para a única região com os dados mais recentes.
As leituras finais consistentes podem ir para qualquer região de réplica a fim de alcançar latências mais baixas. Leituras 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, para ajudar com os dados. Evacuar uma região com tabelas globais do DynamoDB é um exemplo desse caso de uso. Alguns clientes mudarão a região atualmente ativa em intervalos regulares, como uma implantação “follow-the-sun”. Isso coloca a região ativa próxima à geografia com mais atividade, proporcionando a ela a menor latência de leituras e gravações. Também oferece a vantagem de chamar diariamente o caminho do código de alteração de região, garantindo que esteja com os testes em dia antes de qualquer recuperação de desastres.
As regiões passivas podem manter um conjunto reduzido de infraestrutura em torno do DynamoDB, que só é aumentado caso se tornem a região ativa. Para uma discussão mais aprofundada sobre os designs de luz-piloto e espera de preparo, consulte Arquitetura de recuperação de desastres (DR) na AWS, parte III: luz-piloto e espera de preparo
O uso do modo de gravação em uma região funciona bem ao aproveitar tabelas globais para leituras de baixa latência distribuídas globalmente. Por exemplo, uma grande empresa de mídia social tem milhões de usuários e bilhões de postagens. Cada usuário é atribuído a uma região no momento da criação da conta, localizada geograficamente perto de sua localização. Todos os dados vão para essa tabela não global. A empresa usa uma tabela global separada para manter o mapeamento entre usuários e regiões de origem usando o modo de gravação em uma região. Isso mantém cópias somente para leitura em todo o mundo para ajudar a localizar os dados de cada usuário diretamente com o mínimo de latência adicional. As atualizações são raras (somente ao mudar a região de origem de um usuário) e sempre passam por uma região para gravar, para evitar qualquer chance de conflitos de gravação.
Como outro exemplo, considere um cliente de serviços financeiros que implementou um cálculo diário de cashback. O cliente usa o modo de gravação em qualquer região para calcular o saldo, mas usa o modo de gravação em uma região para rastrear os pagamentos de cashback. Se quiser recompensar um cliente com USD 0,01 por cada USD 10 gastos por dia, precisará usar Query para consultar todas as transações do dia anterior, calcular o total gasto, gravar a decisão de cashback em uma nova tabela, excluir o conjunto de itens consultado para marcá-los como consumidos e substituí-los por um único item armazenando qualquer valor restante que deve ser incluído nos cálculos do dia seguinte. Esse trabalho requer transações, portanto funcionará melhor com o modo de gravação em uma região. Uma aplicação pode combinar modos de gravação, até mesmo na mesma tabela, desde que as workloads não tenham chance de se sobrepor.
Primária mista (“gravação em sua região”)
O modo de gravação em sua região atribui diferentes subconjuntos de dados a regiões diferentes e permite operações de gravação somente em itens na respectiva região de origem. Esse modo é ativo-passivo, mas atribui a região ativa com base no item. Toda região é primária para seu próprio conjunto de dados não sobreposto, e as gravações devem ser protegidas para garantir a localidade adequada.
Esse modo é semelhante à gravação em uma região, exceto pelo fato de permitir gravações de latência mais baixa, pois os dados associados a cada usuário final podem ser colocados mais próximos desse usuário na rede. Também distribui a infraestrutura ao redor de forma mais uniforme entre as regiões e exige menos trabalho para desenvolver a infraestrutura durante um cenário de failover, porque todas as regiões terão uma parte de sua infraestrutura já ativa.
A determinação da região de origem dos itens pode ser feita de várias maneiras:
Intrínseca: alguns aspectos dos dados deixam claro em qual região eles estão hospedados, como sua chave de partição. Por exemplo, um cliente e todos os dados sobre esse cliente seriam marcados nos dados do cliente como hospedados em determinada região. Essa técnica é descrita em Usar a fixação de região para definir uma região inicial para itens em uma tabela global do Amazon DynamoDB
. Negociada: a região de origem de cada conjunto de dados é negociada de alguma forma externa, como com um serviço global separado que mantém as atribuições. A atribuição pode ter uma duração finita, após a qual estará sujeita à renegociação.
Orientada por tabelas: em vez de uma única tabela global de replicação, tenha a mesma quantidade de tabelas globais e regiões replicadoras. O nome de cada tabela indica sua região de origem. Nas operações padrão, todos os dados são gravados na região de origem, enquanto outras regiões mantêm uma cópia somente leitura. Durante um failover, outra região adotará temporariamente as tarefas de gravação dessa tabela.
Por exemplo, imagine que você trabalha em uma empresa de jogos. Você precisa de leituras e gravações de baixa latência para todos os jogadores em todo o mundo. Você pode hospedar cada jogador na região mais próxima a ele. Essa região faz todas as leituras e gravações desse jogador, garantindo sempre uma consistência sólida de leitura após gravação. No entanto, se esse jogador viajar ou sua região de origem sofrer uma interrupção, uma cópia completa de seus dados estará disponível em regiões alternativas. Assim, o jogador pode ser atribuído a uma região de origem diferente, conforme a necessidade.
Em outro exemplo, imagine que você trabalha em uma empresa de videoconferência. Os metadados de cada teleconferência são atribuídos a uma região específica. Os chamadores podem usar a região mais próxima de si para obter a latência mais baixa. Se houver uma interrupção na região, o uso de tabelas globais permitirá uma recuperação rápida, pois o sistema poderá mover o processamento da chamada para uma região diferente, onde já existe uma cópia replicada dos dados.
