SQL ou NoSQL, é uma questão?

No ano passado, iniciando um projeto para formação de uma base de dados de valores históricos de ativos financeiros, nos deparamos com a questão de qual motor de banco de dados utilizar no projeto. Um SGBD SQL é sempre uma decisão óbvia, em função das n possibilidades de escolha e do amplo suporte dado pelas ferramentas de desenvolvimento, mas a natureza dos dados não parecia se beneficiar das ferramentas oferecidas por estes produtos.

No piloto automático, a escolha recairia no MySQL rodando em um servidor Linux, acessado pelo servidor de aplicações usando JPA ou Hibernate (sim, é uma aplicação JEE), já que esta combinação ja vinha sendo utilizada em outros projetos de sucesso na Empresa.

Influenciado pelo meu grande amigo Carlos Okada, acabamos olhando para os bancos de dados NoSQL, ou de armazenamento estruturado, especialmente quando os testes de performance inicial acenderam o sinal amarelo para a capacidade do MySQL aguentar a taxa de atualizações e consultas da base de dados em questão.

Esta técnica de armazenamento, amplamente utilizada pelo Google e o seu BigTable, vem ganhando força no mundo das aplicações Web pelas mesmas razões que nós estávamos apanhando para montar uma base eficiente em SQL: pouca ou nenhuma taxa de atualização (apenas inserções), necessidade de baixa latência para inclusões, maioria das consultas com padrão semelhante, alta demanda de consulta e outras coisinhas mais.

Então se o Twitter, o Google e o Facebook estavam usando este tipo de motor, tínhamos a obrigação de dar uma olhada nestas opções com bastante carinho.


Superado o susto inicial e a crueza de algumas ferramentas que analisamos, optamos pelo MongoDB, um motor que já está em um grau de maturidade de produção e que conta com uma excelente documentação e bom suporte para as principais linguagens que estão no nosso radar (Java, Python, Ruby).

Enquanto colhemos resultados excelentes no contexto do projeto em questão, comecei a me questionar o por quê de não utilizar esta abordagem em aplicações mais tradicionais, com mais cara de SGBD tradicionais. Lendo este artigo do InfoGrid, piado pelo @rafanunes, que questiona fortemente a necessidade do conceito de ACID nas aplicações do mundo real, comecei a levar mais a sério este questionamento.

Na verdade, estou roubando quando digo que o conceito de ACID não é necessário.

Em um projeto ideal, no mundo ideal, a Princesa Encantada encomenda um programa para gerenciar a Festa Real e o Programador Oficial escreve um sistema sozinho, usando a última versão do Visual Studio ou do Eclipse, explorando todo o potencial dos Mágicos do Código, gerando uma linda e íntegra aplicação, que será utilizada para as confirmações de presença dos convidados do Reino  Distante, pelos Cozinheiros Reais no planejamento das refeições, pelas Camareiras Camaradas e pelos Cocheiros da Corte, etc., etc.

Neste mundo imaginários, tudo é lindamente resolvido por classes projetadas em torno dos dados e uma aplicação que se beneficia completamente desta maturidade das ferramentas.

No mundo real, porém, a mensagem de RSVP da Festa Real precisaria ser integrada com o sistema de reservas de passagens aéreas Amadeus, a Associação de Cocheiros já tem um software para gerenciar os seus outros clientes  e o novo software das Festas Reais precisa se integrar com tudo isto e ainda utilizar o velho Cadastro de Amigos do Rei que roda há 15 anos numa base SQL 6.5, em um servidor trancado na Torre Real que ninguém encontra a chave há 3 anos...

Assim, o Arquiteto de Software Real precisa resolver estas integrações sem ajuda dos Mágicos do Código, sem um modelo ER bem definido e nem suporte de transações protegidas pelo modelo ACID gerenciado pelo Hibernate ou LINQ de plantão.

Seja nesta fábula, seja nos sistemas do nosso dia-a-dia (como o descrito no artigo citado acima), o ACID acaba sendo mais uma fantasia estimuladas pelos fornecedores de ferramentas, assim como muitas outras "facilidades" que só são úteis no Reino Encantado.

No mundo real das aplicações que mudam constantemente e precisam se adaptar a um ambiente complexo e heterogêneo, soluções baseadas em linguagens dinâmicas apoiadas por bases de dados também dinâmicas me parece, hoje, fazer muito mais sentido.

A possibilidade de armazenar tipos de dados heterogêneos tanto horizontalmente (registros diferentes na mesma coleção) quanto verticalmente (valores, textos, imagens, etc.) facilita ou pode facilitar imensamente a solução dos problemas de negócio reais.

Vou explorar este assunto mais um pouco nas próximas semanas, estruturando uma visão completa de uj modelo de programação com Python + MongoDB e postarei depois por aqui.

Por enquanto fica a reflexão de que talvez todas estas facilidades oferecidas pelas ferramentas de ORM estejam apenas mascarando o fato de que o modelo ER já tem 40 anos e sua adaptação ao mundo dos objetos seja sempre uma licença poética.