O Facebook dispensa qualquer tipo de apresentação. Até acho que existe mais gente no “face” do que viva no mundo real. Durante muitos anos o Facebook rodou e confiou na plataforma LAMP com Linux, Apache, MySQL-MemCache e PHP. Com o passar dos anos sua base de dados foi crescendo: 1TB, 10TB, 50TB, 100TB… 200TB, 500TB e continua crescendo.

De fato, o Facebook usou, ativamente, o MySQL até por volta de 100TB. Ooops, quer dizer que o MySQL pode ser escalado até 100TB de base? Sim e não! Eu, particularmente, acredito que o MySQL é muito competente, mas, eu não me sentiria confortável com uma base maior que 2TB ou 3TB. A dificuldade de manutenção acima disso é muito grande. Até 1TB é tranquilo. Mas, voltando ao Facebook, para conseguir a façanha de usar o MySQL com 100TB eles lançaram mão de milhares de “shards” lógicos controlados pela aplicação e sistema operacional. Inclua-se na aplicação, não só o site, mas também o MySQL personalizado pela equipe interna de desenvolvimento. Personalizar o MySQL não é para qualquer um. E, passa a ser mais um ponto de atenção… a cada atualização da comunidade e/ou do fabricante é preciso ser revista com atenção pela equipe de desenvolvimento. Controlar uma dezena de “shards” lógicos já é um drama, imagine milhares. É muito “if”! “If” nome do fulano começa com “A” os dados estão no servidor tal, “If” o nome do ciclano inicia com “C’, e, mora na Holanda, os dados estão no servidor 1.321! “If’ o desenvolvedor se perdeu no monte de “If”… só sobra o “f” (complete a palavra)!

KISS – Keep it Simple Stupid! Acredito muito nisso! Se alguma coisa está ficando muito complexa de implementar, volte a pensar!

E foi isso que o Facebook fez, dando origem ao TAO (“The Association Objects”). O TAO é um “data store”, um armazenador de dados, um banco de dados OLAP, otimizado para leitura, distribuído geograficamente, especializado em soluções por grafos. Com enorme capacidade de armazenamento, porém,  não tem como virtude manter bases consistentes entre os membros de seu cluster.

O TAO é um big data? Sim, o TAO pode ser entendido como um motor (engine) de big data, assim como é o Hadoop e seu HDFS. Uma de suas virtudes é criar uma camada de abstração, como é esperado de um sistema armazenamento clusterizado e distribuído, na qual toda a complexidade da computação distribuída é “escondida” do programador. Envia a consulta para a “nuvem” TAO e colete o resultado.

O Facebook iniciou suas andanças pelo mundo do big data explorando o ecossistema do Hadoop, inclusive, deu uma enorme contribuição ao criar o Hive e sua linguagem HiveQL. O HiveQL é uma linguagem SQL que torna mais simples o uso do Hadoop. Não está certo, ainda, se o TAO contará com uma implementação do HiveQL.

O TAO foi desenhando para rodar distribuída e geograficamente, com massa de dados na ordem de centenas de Petabytes. E com uma performance sobrenatural: 1.6 bilhões de leituras por segundo e mais de 3 milhões de escrita por segundo. Testes com o MySQL Cluster revelou uma capacidade de até 1 bilhão de inserts por minuto. Consegue enxergar o quanto o TAO é mais otimizado para leitura? Obviamente, não o é para escrita. E mais, como ele é “eventualmente” consistente, é possível leituras sujas aos montes 🙂 OLAP gente, OLAP!

O TAO roda, prioritariamente, em memória para aumentar sua performance. O Facebook divulgou os “papers” conceituais do TAO, mas não o seu código fonte e/ou binários, e, tudo indica que isto não está em seus planos. De qualquer forma, é um “banco de dados NoSQL” para ser acompanhado de perto.