Megadata, nova tendência para os banco de dados

Interessante este artigo de Joe Gregorio onde ele expõe uma tendência de crescimento do uso de quantidades absurdas de dados, exigências de robustez, facilidade para alteração constante da forma da representação dos dados e buscas praticamente instantâneas neste universo.

Os servidores de banco de dados comerciais já não dão conta desta demanda a vários anos. A Google, a Amazon, o eBay (leia isso!), e muitos outros já aprenderam na prática que vários conceitos aprendidos no passado de depender de uma caixa preta (banco de dados) para implementar garantias transacionais e integridade referencial não é mais viável.

Joe Gregorio tenta formular o conceito do Megadata:

• dados distribuidos em múltiplas máquinas, em vez de centralizado num servidor gigante;
• Joinless, sem joins e sem integridade referencial, pelo menos não no local de armazenamento;
• De-normalizado, para evitar os joins;
• Sem transações. Se as transações numa máquina separada já é cara, transações distribuidas em servidores torna isso completamente inviável pela perda de performance.

Ele termina argumentando que estas necessidades começaram em algumas grandes empresas de atuação global pela Internet, mas que logo caminharão para muitas outras aplicações, onde processamento e armazenamento massivo de baixo custo possam contruir novas oportunidades.

Processamento seguro dos dados na Amazon e na Google

Já comentei sobre como grandes volumes de dados são armazenados de forma segura pela Amazon e pela Google. Também comentei como o processamento ocorre nos servidores destas empresas.

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.

Computação sob demanda da Amazon: EC2

Além do serviço S3 de storage, a Amazon também oferece o serviço Elastic Computing Cloud (EC2) para o provimento de servidores virtuais onde aplicações podem ficar ativas para oferecer serviços pela Internet.

Segundo a Amazon, o servidor virtual se comporta como um computador x86 de 1,7Ghz, com 1,75GB de RAM, 160GB de disco local, e 250Mb/s de banda de rede.

O EC2 funciona assim: você primeiro precisa de um AMI (Amazon Machine Images) que é basicamente uma imagem de um disco contendo o sistema operacional e que deve estar armazenado no S3.

Já existem vários AMIs públicos que podem ser usados para testes ou como base para a construção do seu próprio AMI.

Com o AMI definido, você requisita a iniciação de uma instância através de um web service autenticado que responde o IP que o servidor virtual vai ser encontrado em alguns minutos.

Após passados estes minutos, o servidor está pronto para usar e pode ser acessado por ssh, pela web, ou qualquer outro protocolo implementado em aplicações instaladas no AMI.

Não há nenhuma garantia quanto a permanência da instância. O servidor pode sair de operação por problemas de hardware por exemplo e perder todos os dados armazenados no disco local e na RAM. Portanto a Amazon recomenda implementar persistência ou no S3 ou replicada em várias instâncias de servidores virtuais EC2.

Não há necessidade de acordar nenhum tipo de período de uso e de quantidade de instâncias com a Amazon (dentro dos limites práticos para a Amazon), e você paga apenas $0,10 centavos de dólar por hora-instância consumidos. Uma instância pode ser desativada da mesma maneira que foi iniciada: através de outro web service.

A Google provavelmente implementa mecanismos parecidos para distribuir suas atividades computacionais, entretanto seu mecanismo não é de conhecimento público. De conhecimento público existe o modelo de programação MapReduce que é usado para implementar comutação distribuída e robusta. Com esta abstração, um escalonador de tarefas é capaz de distribuir processamento entre grande quantidades de servidores e garantir sua conclusão.

O interessante deste serviço é que a Amazon disponibilizou, a qualquer empreendedor motivado, uma solução de baixo custo para processamento sob demanda. Solução esta que permite construção de clusters massivos de usos temporários, sem a necessidade de nenhum investimento de hardware ou de infraestrutura de suporte de TI.

Ninguém precisa ficar com inveja da Google.