MongoDB na Ahgora

Depois de várias experiências de uso de armazenamento de dados na plataforma S3 e SimpleDB da Amazon, nós na Ahgora acabamos decidindo pelo uso do MongoDB.

Desde o ano passado já tínhamos decidido abandonar a estruturação convencional de dados por um banco relacional convencional e caminhar para uma modelagem mais simples orientada a documentos.

Nossa idéia era utilizar o S3 como um "document store" e o SimpleDB como uma maneira de indexação simples dos documentos e de vetores de dados que precisassem de busca rápida.

Os serviços S3 e SimpleDB da Amazon são bem feitos e muito confiáveis, implementando mecanismos poderosos de redundância e com escalabilidade massiva, mas dois pontos complicam seu uso: a consistência eventual e as ferramentas de acesso e depuração um tanto complicadas.

A consistência eventual dá para lidar simplesmente evitando a tentativa de reler imediatamente o dado que acabou de escrever ou por cache local ou por temporização forçada. Já a falta de ferramentas simples de depuração e acompanhamento dificulta bastante.

Estávamos usando as extensões do Firefox S3Fox e SDBTool, mas eles não são ferramentas rápidas e são complicadas de lidar quando se tem plataformas separadas de teste e produção, além de depender de conectividade constante para cada ciclo de teste.

Tentando buscar uma alternativa que pudesse nos ajudar a acelerar o desenvolvimento e simplificar os conceitos, começamos a olhar os "document stores" (CouchDB/MongoDB) e "key-value stores" (Riak/Redis) que estão em voga na Internet.

Coincidentemente observamos um crescimento muito acentuado do uso do MongoDB neste início de ano, o que incentivou uma prototipação interna para uma parte do sistema da Ahgora.

A prototipação foi um sucesso e observamos que usando o MongoDB conseguimos unificar as demandas para S3 e SimpleDB a apenas um mecanismo de armazenamento de dados.

Fora isso, ele possui uma interface de linha de comando que lembra a interface de linha de comando do MySQL, permitindo manipulação simples e rápida dos dados, mesmo em nossos notebooks, com ou sem conectividade para a Internet.

A instalação é simples e dá para começar a brincar em 10 minutos em seu computador. Pelo browser dá para brincar em 10 segundos pelo link: http://try.mongodb.org/.

A documentação não é perfeita, mas é muito melhor do que a disponibilizada para as plataformas da Amazon. Inclusive apresentando documentações extensivas para várias linguagens de programação diferentes.

A modelagem de dados é diferente com um "document store" devido a flexibilidade permitida. O item mais importante da modelagem é descobrir como o dado vai ser lido e escrito, e tentar modelar os documentos o mais próximo destes ciclos de leitura e escrita. Só brincando mesmo para entender o impacto, e o MongoDB permite brincar rapidamente e testar as alternativas.

Semanas atrás conseguimos concluir a mudança completa do nosso sistema de gestão de controle de ponto para o MongoDB. Foi muito mais fácil que pensávamos, já que já estávamos com vários dados modelados como documentos.

A principal desvantagem desta troca é que perdemos a escalabilidade e redundância nativa da Amazon e temos que manter nossas estruturas próprias de redundância entre servidores. Entretanto o MongoDB possui mecanismos bons para replicação, e bem mais simples que do MySQL.

Obs: No Slideshare tem uma apresentação ótima para uma primeira visita ao MongoDB.

Brincando nas núvens com o SimpleDB da Amazon

Dias atrás apresentei o serviço S3 da Amazon e como ele serve como uma boa ferramenta de backup usando o S3Fox.

Agora vou apresentar como brincar com o SimpleDB da Amazon que nada mais é que um banco de dados distribuído rodando na Internet.

Como faz muito tempo que não brinco com php, vou usar o php com uma biblioteca de acesso aos serviços da Amazon chamado de Tarzan.

Feito o download, basta configurar no diretório de trabalho suas permissões de acesso ao serviço da Amazon (variáveis AWS_KEY e AWS_SECRET_KEY, as mesmas usadas para o S3Fox). Não esquecer que o serviço SimpleDB precisa ser assinado na Amazon antes de poder usá-lo.

Teste simples para ver os domínios (equivalentes a tabelas no caso de SQL):

$ php -r 'require_once "tarzan.class.php";$sdb = new AmazonSDB();print_r($sdb->list_domains()->body->ListDomainsResult);'

O resultado no caso de não existir nenhum domínio seria:

SimpleXMLElement Object

(

)

Seguindo as documentações do SimpleDB do Tarzan, toda a API do SimpleDB está disponível. Vamos criar um domínio novo:

$ php -r 'require_once "tarzan.class.php";$sdb = new AmazonSDB();print_r($sdb->create_domain("dominio1"));'

$ php -r 'require_once "tarzan.class.php";$sdb = new AmazonSDB(); print_r($sdb->list_domains()->body->ListDomainsResult);'

O resultado do último comando mostra:

SimpleXMLElement Object
(
    [DomainName] => dominio1
)

Legal! O dominio1 apareceu. Colocando dados de Santa Catarina, São Paulo e Ceará:

$ php -r 'require_once "tarzan.class.php";$sdb = new AmazonSDB();print_r($sdb->put_attributes("dominio1", "Santa Catarina", Array("capital"=>"Florianopolis", "populacao"=>"0005866568")));'

$ php -r 'require_once "tarzan.class.php";$sdb = new AmazonSDB();print_r($sdb->put_attributes("dominio1", "Sao Paulo",Array("capital"=>"Sao Paulo","populacao"=>"0040442795")));'

$ php -r 'require_once "tarzan.class.php"; $sdb = new AmazonSDB(); print_r($sdb->put_attributes("dominio1","Ceara", Array("capital"=>"Fortaleza","populacao"=>"0008097276")));'

Aí, com uma pesquisa simples do tipo SQL dá para procurar estados com mais de 10 milhões de habitantes:

$ php -r 'require_once "tarzan.class.php"; $sdb = new AmazonSDB();print_r($sdb->select("select populacao from dominio1 where populacao>\"0010000000\"")->body->SelectResult);

O que reporta o estado esperado e sua população:

SimpleXMLElement Object
(
    [Item] => SimpleXMLElement Object
        (
            [Name] => Sao Paulo
            [Attribute] => SimpleXMLElement Object
                (
                    [Name] => populacao
                    [Value] => 0040442795
                )
        )

)

Backups na núvem com S3 da Amazon

E agora? Como guardar aquelas 5.000 fotos que você guardou nestes últimos 10 anos de fotografia digital?

Existe uma quantidade enorme de serviços de backup na Internet hoje em dia, como Mozy, DropBox, Carbonite ou JungleDisk, mas eu já sou mais do gosto de mexer diretamente com os arquivos e não ficar tão refém dos serviços prestados por um software instalado no micro.

S3 é um serviço da Amazon de armazenamento robusto de arquivos sem limite de quantidade e com replicação pelo menos tripla. É muito mais segurança do que qualquer backup que você deve estar aprontando de dentro de sua casa hoje. E o preço é bem em conta, gasto algo como $1,50 dólares por mês para manter os meus 10GB de fotos lá.

E usando o S3Fox, que é uma extensão para Firefox, o serviço de download, upload e sincronização ficam bem simples, praticamente a um click do mouse.

O que você precisa para poder usar este serviço?

• criar uma conta no Amazon Web Services;
• contratar o serviço S3;
• instalar o S3Fox;
• cadastrar no S3Fox as credenciais do S3 (Your Account/Security Credentials no site da Amazon).
  

A partir daí, é como transferir arquivos para um servidor como se fazia com o FTP, e curtir a tranquilidade de ter suas valiosas memórias seguras na nuvem da Internet.

Cassandra: bigtable/dynamo em código aberto do facebook

Algumas semanas atrás o Facebook liberou sem chamar muita atenção sua implementação de uma base de dados robusta e replicada inspirada do BigTable do Google e utilizando conceitos de distribuição de dados do Dynamo da Amazon.

É um código feito em Java de cerca de 40 mil linhas que parece implementar um núcleo funcional mas sem todas as liberdades que existem nos sistemas da Google e da Amazon.

Foi implementado recentemente por uma equipe pequena interna a Facebook como uma alternativa mais simples que a plataforma Hadoop que já está sendo usada a algum tempo no Facebook.

O código está no Google Code e existe uma apresentação sobre o projeto discutindo alguns detalhes internos.

Consistência eventual de dados no eBay

A revista Queue da ACM publicou na edição maio/junho de 2008 um artigo chamado "ACID vs. BASE" de Dan Pritchett (eBay) falando do conceito de consistência eventual em armazenamento escalável de dados.

É uma ótima introdução dos conceitos de gerenciamento de dados distribuídos aonde a consistência perfeita "ACID" é abandonada para permitir níveis de performance e escalabilidade que são impossíveis de atingir numa plataforma monolítica.

Já fiz vários comentários sobre o conceito de dados distribuídos, o interessante é como que todos os grandes serviços na Internet (Google, Amazon, eBay, etc) só conseguiram atingir o público mundial abandonando a segurança da consistência tão defendida pelos fornecedores convencionais de banco de dados comerciais.

Na prática, quando os dados passam a ser divididos em milhares de servidores separados para conseguir a performance, a consistência "global" acaba sendo impossível de ser atingida.

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.