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!
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!
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.
Isso acontece, aliás, hypes existem justamente porque a maioria das pessoas não querem estudar e entender PARA QUE SERVE. Querem seguir uma “tendência”, uma onda, alguém dizendo: é ISTO que vc deve usar.
Discordo do que você chamou de Mito #1
1) Em 1970 não existia ainda o conceito de banco de dados na prática. Ou seja, ninguém usava e não havia nenhum para vender. Isto não significa que os modelos não estivessem sendo estudados.
2) Os bancos de dados não relacionais que existiam antes tinham propósito completamente diferente do NoSQL de hoje em dia. Então não procede o mito #1. NoSQL é realmente uma novidade deste milênio. Isto não significa que a teoria não tivesse sido estudada antes.
3) O fato do Lotus Notes ter usado algum modelo não significa que este modelo estivesse disponível a todos.
Resumindo: é preciso cuidado com a história. Há gente sempre colocando conceitos mais recentes como se já estivessem em uso muito antes do que realmente aconteceu. Eu me lembro claramente quando surgiu o conceito de banco de dados e posso garantir que foi uma enorme revolução no mundo de processamento de dados. Isto aconteceu no fim da década de 70, início dos anos 80. Quando escrevo surgir estou querendo dizer estar disponível a todos e não apenas em um paper acadêmico.
Oi Luca, e eu discordo de você. Vamos aos fatos.
Sim: em 1970 já existia o conceito de SGBD na prática, conforme você pode ver em dois pontos. Talvez não no Brasil, mas fora com certeza sim.
1) Comercialização do Natural Adabas em 1970 não como solução relacional
2) A pesquisa do CODASYL que menciono no próprio post: http://www.sqlsummit.com/PDF/DatabaseSurvey_CODASYL_1968.pdf
3) Já era comercializado por exemplo o sistema R da IBM
4) Os próprio banco de dados proposto pelo CODASYL inicialmente proposto em 1959 e comercializado pelos participantes do consórcio para os seus clientes.
5) Tem também o IMS da IBM que já era comercializado em 1966 (http://en.wikipedia.org/wiki/IBM_Information_Management_System)
Sobre o ponto 2
Não existia o termo NoSQL porque ele sequer fazia sentido, pois o modelo relacional começa a engatinhar em 1970, tem sua primeira implementação ruim em 1974 (o R da IBM) e a primeira implementação de sucesso em 1976 com o Oracle. Neste caso, olhando pro NoSQL você percebe que os mesmos conceitos de modelagem de dados já existiam: chave-valor, navegacional (que vai dar origem ao baseado em grafos) (CODASYL).
O que temos hoje é a reciclagem terminológica de um conjunto de SGBDs que é bastante complicada (muito bom o texto do Fowler que cito a respeito). O que existia antes eram os bancos de dados que não usavam o modelo relacional.
Sobre o ponto 3
Este modelo estava disponível para os usuários do sistema que o compram a partir de 1989. E sim, era bastante popular entre eles, até que surgiu o Office e colocou a Lotus no chinelo.
Ser popular e existir são coisas bem diferentes. :)
Pra enriquecer um pouco a discussão, alguns links bem legais.
Uma timeline da história dos SGBDs: http://lyle.smu.edu/~fmoore/timeline.pdf
Um texto que acho interessantíssimo sobre a evolução dos modelos de bancos de persistência: http://www.fing.edu.uy/inco/grupos/csi/esp/Cursos/cursos_act/2000/DAP_DisAvDB/documentacion/OO/Evol_DataModels.html