Há dois meses, 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 saiba 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 à 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 sob 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 têm 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
🙂