Agora temos que analisar como as interações com os sistemas são robustas a ponto de que nenhuma transação seja perdida mesmo com falhas nos servidores dos respectivos datacenters.
Os serviços S3 da Amazon e o GFS da Google são mecanismos para preservação de estado robustas, mas que não oferecem meios para alteração dos dados armazenados. Então como as transações são armazenadas de forma segura?
No caso da Google a solução é bastante interessante: utilizar do mecanismo de append em fim de arquivo como uma forma de implementar uma fila FIFO de transações. Ou seja, um "change log".
Como isto funcionaria?
Por exemplo, digamos que tenhamos um arquivo com uma base de informações grandes. Então uma transação é efetuada provocando a alteração lógica de algum elemento. Esta transação é então armazenada como uma alteração no final de um arquivo separado de "log de alteração".
Logicamente isto implica que toda consulta agora precisaria consultar a base original e consultar os "logs de alteração" para verificar o valor correto, mas se o "log" não for muito grande não há grandes problemas.
Para o "log" não crescer sem parar, uma operação em background pode construir num novo arquivo uma segunda base atual com as alterações do "log", ou um novo arquivo com a base original completa contendo também os dados não alterados. O paper do GFS comenta sobre este mecanismo.
Já a Amazon disponibilizou um outro serviço web chamado Amazon Simple Queue Service (Amazon SQS) que implementa filas robustas específicas para o fim de registrar ações, com custos de $0,10 centavos de dólar por 1.000 mensagens para quem desejar desenvolver aplicações sobre este serviço.
O modo de uso acaba sendo semelhante ao implementado pelo Google, onde algum processo em background gerencia estas alterações armazenadas nas filas para construções de novas bases atualizadas.
A solução SQS da Amazon acaba sendo uma abstração mais avançada e específica para o registro de eventos e ações.
Nenhum comentário:
Postar um comentário