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.

O banco de dados da Google

Falei sobre o armazenamento, administração de alterações e servidores de processamento nas plataformas do Google e da Amazon. Agora resta saber como se utilizar destas ferramentas para construir abstrações mais convencionais de base de dados.

No caso do Google, a principal ferramenta hoje é o BigTable. O BigTable é uma aplicação distribuída que opera sobre o Google File System (GFS) e implementa tabelas 3D genéricas, cujos vetores são linha, coluna e tempo. Todo o mapeamento é feito String para String, ou seja, as chaves linha, coluna e tempo são string e o condeúdo dos campos são também strings.



As tabelas são obrigadoriamente ordenadas por linha, dentro da linha por coluna, e então por tempo, e são quebradas em unidades menores de tamanhos típicos de 200MB chamadas "tablets" para mapear melhor com o GFS. As "tablets" sempre contém linhas inteiras, ou seja, a fronteira da linha é usada para quebrar os "tablets".



Então os "tablets" ficam sendo os motores de armazenamento de dados e alterações, onde um "log" em disco e uma versão em memória das alterações do "log" são usadas para registrar e preservar as alterações recentes, e tabelas chamadas "SSTables" contém mapas mais antigos de <linha,coluna,tempo> para <dado>.



Uma aplicação em batch faz compilações dos "logs" para novas "SSTables" constantemente, e outra mais esporádica agrupa as "SSTables" em uma única "SSTable" para reclamar o espaço em disco dos elementos que foram retirados ("Garbage Collection").

Para quem tiver interesse, existe uma apresentação sobre o BigTable feita pelo Jeff Dean da Google na Universidade de Washington no Google Video.

O BigTable não possui interface SQL, não é uma base relacional e nem transacional, implementando apenas garantias de alterações atômicas ao nível de linha. Entretanto, com os devidos cuidados, esta é a base para aplicações gigantescas oferecidas pelo Google, como o Google Earth (70TB de dados), Google Analytics (200TB de dados) e a base de buscas do Google (800TB de dados).


Já a Amazon não fala muito como implementa suas aplicações, apenas que utiliza exatamente a mesma infraestrutura de serviços web sendo oferecida hoje (S3, EC2 e SQS).

Existe um artigo bastante interessante de Pat Helland (ex-funcionário da Amazon) onde ele comenta sobre como implementar aplicações massivas e distribuídas em centenas de computadores.

Ele argumenta que para distribuir aplicações, é necessário separar os "estados" em entidades ("entities"). Entidades seriam uma coleção de dados com uma única chave para sua localização. Exemplos: uma Ordem de Compra (chave OrderId) , um Ítem em Estoque (ItemId), etc.

Então para considerar uma aplicação "escalável", você não pode assumir que transações atômicas sejam possíveis envolvendo mais de uma entidade. O artigo apresenta o conceito de operações canceláveis (tentativas de operações) como a única forma de manter consistência em ambientes distribuídos.

O interessante é que de certa forma tanto a Amazon como a Google chegaram em conceitos semelhantes, o que a Google chama de "linha" numa tabela BigTable acaba sendo uma entidade da Amazon.

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.

Storage na Amazon e na Google

Como é que a Amazon e a Google armazenam suas absurdas demandas de persistência de informação?

Se você acha que é com grandes storages fiberchannel em RAID5, RAID6 ou RAID10 e instalações gigantescas de bancos de dados comerciais você estaria completamente enganado.

Tanto uma como a outra desenvolveu seus próprios mecanismos de armazenamento de informação em servidores convencionais usando simples discos ATAs.

A idéia é utilizar muitas máquinas com dados espalhados e com cópias redundandes em vários lugares, normalmente 3 cópias independentes.


A Amazon utiliza do serviço S3 internamente para implementar seus mecanismos de redundância. Este serviço permite o armazenamento e a recuperação de arquivos de até 2GB em uma estrutura de diretório, a remoção dos mesmos e a listagem destes diretórios.

Internamente o S3 implementa tudo o que é necessário para garantir a preservação dos dados e a acessibilidade dos mesmos. Os arquivos são copiados automaticamente para vários datacenters da Amazon.

O interessante deste serviço S3 é que a Amazon oferece este serviço para qualquer pessoa que tenha interesse de desenvolver aplicações com dados seguros por preços muito baixos: $0,15 centavos de dólar por GB armazenado, $0,10 por GB enviado à Amazon, até $0,18 por GB recebido da Amazon, e mais $0,01 por 1.000 envios ou listagens e $0,01 por 10.000 recebimentos.

Este é o caso da SmugMug, que se utiliza da estrutura da S3 para armazenar mais de 100 TB de fotos dos clientes deles.



Já a Google se utiliza da tecnologia do Google File System, que implementa de forma semelhante um mecanismo robusto de armazenamento dos dados.

A Google não oferece acesso por terceiros a este sistema, mas seu funcionamento é documentado neste paper.

O Google File System (GFS) implementa um mecanismo de quebrar os arquivos a serem preservados em chunks de 64MB por default, chunks estes que são replicados em 3 servidores ou mais.

As leituras são distribuidas entre as cópias permitindo multiplicar o throughput, já as escritas são feitas em seqüência entre os servidores e sempre na mesma ordem para que situações de corrida não façam as cópias ficarem diferentes. As escritas só são confirmadas para a aplicação se todas as cópias estão com o dado gravado corretamente.

Tanto a solução da Google como da Amazon não implementam mecanismos esperados em sistemas de arquivos convencionais, como a alteração no meio de um arquivo já gravado. A solução da Google entretanto permite a leitura a partir de um endereço aleatório e pelo menos anexar dados no final de arquivos previamente guardados.

E como é possível usar isso para substituir um banco de dados convencional?

Não é simples, mas com esta base funcional as duas empresas implementaram abstrações, tipo o BigTable (paper) do Google, que permitem hoje fazer ambas as empresas operar os seus negócios em escalas impensáveis para bancos convencionais.