NoSQL: alguns mitos

Texto escrito em 2013

Logotipo cretino
Como todo buzzword NoSQL gera muito hype e, consequentemente, muita bobagem é falada e escrita. Neste post lotado de referências vou expor algumas das mais comuns que leio e escuto por aí. Quem sabe assim pelo menos os leitores deste blog evitam cair nestas ciladas. :)

Mito #1: NoSQL é novidade

A principal característica por trás dos bancos de dados NoSQL é o fato destes não serem baseados no modelo relacional. Neste ponto pode ser que eu esteja errado, mas o artigo de Codd - A Relational Model of Data for Large Shared Data Banks - em que o modelo relacional é apresentado sai em 1970.

Se a principal característica for a não adoção do modelo relacional, e NoSQL é novidade, isto quer dizer que antes de 1970 não existiam bancos de dados? Acho que não: em 1959 temos por exemplo a publicação da primeira versão do CODASYL que criou a linguagem COBOL e também definiu um novo padrão de banco de dados, o navegacional. Ainda mais interessante, em 1968 o mesmo comitê faz uma pesquisa sobre os gerenciadores de bancos de dados existentes até o momento para análise. E ei: haviam mutos! Aqui está um link com esta pesquisa.

Outra: já vi gente dizendo que o modelo documental é novidade. Nope! O Lotus Notes já tinha um banco documental na década de 1990. Mais sobre a história do Notes pode ser visto neste link.

Mito #2: que se dane o esquema!

Cabeças rolam no futuro graças a isto :)

Este é o mito que provávelmente gera mais dor a médio prazo e é bastante comum. É bacana ter um SGBD que te permita flexibilidade nos atributos presentes na definição de cada entidade. Martin Fowler, por exemplo, coloca a ausência de esquema como um dos principais atributos deste tipo de sistema gerenciador de bancos de dados. De fato, para entidades nas quais os dados não sejam exatamente registros, tal como muito bem definido no excelente artigo de Kent publicado em 1979 - Limitations of Record-Based Information Models - o esquema muito mais atrapalha que ajuda.

Conforme o tempo passa vemos que apenas uma minoria dos casos a informação de fato cai na categoria registro. Pergunto: será que com isto devemos ligar o foda-se para a definição do esquema? Não: é exatamente o oposto. Justamente por você possuir liberdade total na definição dos campos que compõem seus dados você deve possuir uma documentação ultra detalhada a respeito do que deve ou não estar presente em cada documento/nó/whatever! Se tudo for válido, então nenhuma regra existe. Se nenhuma regra existe, o que você tem no final? Tem uma armadilha. E das brutas!

E ei: não tem muito como fugir do esquema. Aqui um excelente post a respeito.

Mito #3: a escalabilidade NoSQL sempre é superior por ser NoSQL oras!

Um dos pontos de venda destes bancos de dados é o fato de ser possível obter alta escalabilidade apenas por adotá-los em seu projeto. Ouch. Alta escalabilidade é obtida não é porque você usa NoSQL: é por que sua arquitetura é boa: simples assim.

Já vi casos em que em um projeto se trocou todos os DAOs do relacional para algo NoSQL e o ganho de performance foi monstruoso. Analisando mais a fundo você percebe que este ganho na realidade é obtido porque a estrutura de dados tabular não era a mais adequada para persistir o estado do sistema. Já falei sobre isto aqui: o grande problema é notacional.

Pergunto: um sistema no qual os dados sejam registros estritos, tal como no texto de Kent será que seria realmente mais rápido em um SGBD documental, chave-valor ou baseado em grafos? Só pra lembrar, você pode ter um SGBD relacional com ACID mais fraco, como por exemplo SQLite ou o motor MyISAM do MySQL.

Martin Fowler coloca como um dos aspectos do NoSQL o fato de serem sistemas projetados para serem executados em grandes clusters (é assim mesmo que se escreve? "clusters" ou "clusteres"?), mas você não pode levar isto ao pé da letra, pois se assim for, o Oracle cairia na categoria NoSQL.

Mito #4 Benchmarks sem sentido e completamente injustos

Fácil de quebrar: como você pode comparar de forma justa modelos de persistência tão distintos quanto chave-valor, relacional, documental, orientado a grafos, colunar, etc? Vejo alguns benchmarks por aí que dizem coisas do tipo "nossas buscas ficaram ordens de magnitude mais rápidas ao usarmos um banco de dados chave-valor ao invés do relacional".

Você bate um olho no sistema e percebe que as consultas todas são por identificador. Claro que o chave-valor irá ganhar: ele é feito pra isto. Ou então vemos comparativos que mostram, por exemplo, que lidar com relacionamentos fica mais rápido com algo como Neo4J ao invés de MySQL. Óbvio: Neo4J é feito pra isto!

O que quero dizer é o seguinte: dado que cada SGBD é feito para lidar com um tipo específico de estrutura de dados, a comparação só é justa quando os competidores lidam todos com as mesmas estruturas de dados. Riak vs Redis, MongoDB vs CouchDB, por exemplo é uma comparação justa. Oracle (relacional) vs Tokyo Cabinet (chave-valor), não

Mito #5: minha produtividade com NoSQL é muito maior!

"É como se você tivesse inúmeros braços com NoSQL". Rá!

Muito gerente cai nesta. Sim, você pode obter maior produtividade com NoSQL: o fato de muitas vezes não haver um esquema obrigatório te permite, por exemplo, evoluir seu modelo conforme novas situações vão surgindo. Pesquisas em um grafo são mais fáceis de escrever, lidar com consultas por chave-valor são simples. É inegável isto: você esta usando as estruturas de dados corretas desta vez uai!

É engraçado notar que o lado negativo pouca gente fala: o principal sendo o cultural. Se sua equipe já está acostumada com o modelo relacional, a adoção de algo não-relacional se mostra um desafio monstruoso. Não é raro observarmos um nível altíssimo de rejeição, especialmente ao observar na sua implementação NoSQL a ausência de um recurso que tornava a vida do desenvolvedor bastante confortável, como por exemplo integridade referencial. Sim, eu sei que não precisamos dela sempre, mas muita gente chora quando não a encontra, especialmente ao lidarem com o modelo documental que lembra o relacional.

Outro problema: muitas vezes você transfere para o código fonte do seu projeto responsabilidades que até então eram do SGBDR, como por exemplo otimização de consultas, integridade dos dados, etc. Você não tem validação de atributos no MongoDB, por exemplo. Sobre esta transferência de responsabilidade, recomendo a leitura deste artigo: "The NoSQL Ecosystem", do excelente livro "The Architecture of Open Source Systems".

E eu mencionei aqui que, ao contrário do modelo relacional que possuí uma linguagem padrão de consulta - o SQL - o mesmo não ocorre no mundo NoSQL mesmo com a Spring Source tentando algo nesta direção?

Concluindo

A cada dia que se passa mais bobagens vejo sendo escritas e faladas sobre NoSQL devido ao hype envolvido. Sinceramente, acredito que este movimento NoSQL é a melhor coisa que poderia nos acontecer. Mas antes de se empolgar em excesso e topar com este tipo de argumento, lembre-se do seguinte: assim como a rapadura, NoSQL é doce, mas não é tão mole quanto nos vendem. :)

PS:

Podem esperar uma parte 2 deste post.