O Mysql e o NoSql

Há dois meses, os sites e blogs sobre tecnologia anunciaram que a Oracle fechara a compra da Sun. Mas enquanto os principais produtos desta são o Java e os servidores Enterprise, a reação mais comum no meu círculo de contatos no twitter  mostrava preocupação instantânea com um outro produto muito conhecido da Sun: “E o que vai acontecer com o Mysql?”, indagavam.

Embora a gente nunca sabe exatamente o que vai sair das atas das reuniões de executivos de mega-corporações, de cabeça de juiz e de bunda de neném, arrisco a dizer que não vai acontecer nada. Pelo menos nada de ruim, como podem ter imaginado inicialmente, o que até se justifica pelo fato de que a Oracle não tem sido exatamente a melhor amiga do Open Source: mas a menos que Larry Ellison e seu board tenham tendência a rasgar dinheiro, a Oracle não vai fechar o fonte do Mysql, não vai descontinuá-lo e não vai deixar seu desenvolvimento estagnar para favorecer seu outro SGDB.

E se as coisas no Mysql vão continuar sendo como sempre foram, o mesmo não pode ser dito sobre o mundo ao seu redor. Neste momento, talvez o que os milhões de desenvolvedores que usam o mysql deveriam começar a questionar é se ele ainda é a ferramenta  mais adequada para armazenar os dados de suas aplicações. Desde a versão 3, quando começou a ser reconhecido como o SGDB mais veloz para a web justamente por suas funcionalidades espartanas, o Mysql veio adicionando muitas novidades e no atual momento, com chegada da versão 5.4, tem tantos recursos quanto os outros bancos outrora considerados “mais parrudos”.

Mas não é na discussão de funcionalidades vs performance que quero entrar. A rigor, a bola a ser levantada neste post nem é unicamente relacionada ao mysql. A questão é relativa aos bancos de dados relacionais. Criados em meados de 1970, os bancos relacionais e sua linguagem SQL dominaram completamente o mercado a partir da década de 80 e desde então se tornaram uma espécie de “pau pra toda obra”, sendo usados até mesmo pra armazenar dados de aplicações que muitas vezes sequer se encaixam em modelos relacionais e seriam melhor servidas por outras classes de sistemas de gerenciamento de bancos de dados existentes.

Até que surgiu a web. Sim, essa mesma mídia transformadora que forçou o fim ou declínio de alguns dos maiores modelos de negócio da história do capitalismo, causa disrupção também no modo como os desenvolvedores precisam armazenar e acessar os dados de suas aplicações.  Começando com a emergência da Web 2.0 (ou qualquer outro nome que você dê para a tendência de os usuários passarem a também publicar conteúdo, ao invés de apenas consumir), o volume de dados que os sites agora precisam armazenar e processar cresceu a níveis nunca antes vistos na história. E aí a bicicletinha quebrou.

O mysql é usado por milhões de sites (incluindo alguns dos maiores do mundo), mas claramente nem ele nem qualquer outro banco relacional é o mais adequado para importantes classes de aplicações web, principalmente quando elas crescem. Pergunte a qualquer desenvolvedor web qual a maior dificuldade que enfrentam quando precisam escalar suas aplicações pra rodar em mais de uma máquina e 10 entre 10 vão responder que é o banco de dados.  Enquanto é relativamente simples e bem conhecido o que precisa ser feito para escalar servidores de aplicações, de emails e de arquivos, quando a conversa chega no banco, a cuca ferve. Por que? Porque, replicações, clusters e proxys a parte, bancos de dados relacionais não foram planejados para prover escabilidade nem com facilidade, nem com eficiência.

A consequência disso é que os desenvolvedores das aplicações de grande tráfego que usam o mysql ou outros bancos relacionais têm recorrido a todo tipo de “hacks e workarounds” pra dar conta do recado. E foram ajudados ainda pelo surgimento de coisas boas como o memcached, que possibilita diminuir drasticamente a necessidade de acesso ao banco e sem o qual, arrisco dizer, provavelmente 50% dos seus sites favoritos talvez não seriam viáveis.

Porém, outras alternativas estão surgindo além dos bancos relacionais. Os desenvolvedores do Sillicon Valley os estão agrupando sobre o rótulo de “NoSQL”, e nos últimos meses tenho visto vários posts em blogs de tecnologia  discutindo esses SGDBs, que via de regra, foram projetados com as necessidades das aplicações web em mente e tem como características comum o fato de serem open-source, distribuídos (visando facilitar escalabilidade) schema-free e acessíveis via RESTful Http. Alguns funcionam simplesmente como uma grande tabela hash no esquema key-value, outros são orientados a documentos.

Por já ter perdido noites e noites pra escalar e/ou melhorar a performance dos servidores de Mysql quando era o desenvolvedor do Flogão, tenho acompanhado com bastante interesse o desenvolvimento desses bancos e as discussões a seu respeito. Desses novos SGDBs, Voldemort (criado pelo Linked-in), CouchDB, Cassandra (criado pelo Facebook) , MemcacheDB e MongoDB (meu favorito até agora) me parecem os mais interessantes e promissores.

É verdade que são todos projetos bastante jovens (se comparados à maturidade até mesmo do mysql) e cuja adoção é mais benéfica e justificada principalmente para o pequenino percentual (menos de 1%, certamente) das aplicações web de maior tráfego e volume de dados. Mas, se por um lado a turma que não é chegada em hype alerte aos mais afoitos que os bancos relacionais como o Mysql são suficientemente adequados pra grande maioria dos projetos (com o que eu concordo plenamente), ainda assim acho que vale a pena no mínimo acompanhar essa tendência. As aplicações na internet estão se tornando cada vez mais complexas e famintas por dados, e eu acredito que dentro de 5 ou 10 anos mesmo os considerados “pequenos” vão precisar das vantagens introduzidas por esses novos bancos, que devem se tornar muito mais difundidos e respeitados com o tempo. Fica a dica :)

Tags: couchdb, Database, Larry Ellison, mongodb, mysql, nosql, open source, Sun Microsystems