03 junho 2008

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.

Nenhum comentário: