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.
17 julho 2008
Um guia curto para dominar o mundo...
Você quer ser uma peça do tabuleiro ou você quer jogar o jogo da sua vida?
Este pequeno e-book é muito interessante porque levanta as perguntas mais importantes da vida de todos:
O bacana é que na prática maximizar os objetivos de resultados para si e para o mundo não é contraditório. Na realidade o sucesso de um só é possível pelo sustento do sucesso do outro.
Sair da mediocridade é difícil mas você deve a você e ao mundo pelo menos tentar começar. O que você fará hoje para começar a tomar o mundo?
Este pequeno e-book é muito interessante porque levanta as perguntas mais importantes da vida de todos:
- O que você realmente quer desta vida?
- O que você pode oferecer ao mundo que ninguém mais pode?
O bacana é que na prática maximizar os objetivos de resultados para si e para o mundo não é contraditório. Na realidade o sucesso de um só é possível pelo sustento do sucesso do outro.
Sair da mediocridade é difícil mas você deve a você e ao mundo pelo menos tentar começar. O que você fará hoje para começar a tomar o mundo?
08 julho 2008
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.
É 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.
13 junho 2008
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.
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.
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.
09 junho 2008
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.
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.
06 junho 2008
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.
Assinar:
Postagens (Atom)