Muito provavelmente minha maior neurose é a linguagem: talvez isto explique a razão pela qual o termo NoSQL me irrite tanto, pois como exporei neste post, é bastante inadequado e, acredito, pode nos gerar uma série de problemas em um futuro não muito distante. Na realidade, já vejo alguns hoje.
Este post possuí uma proposta: remover este termo do nosso jargão substituindo-o por algo que, acredito, faz muito mais sentido e descreve melhor a realidade.
A definição segundo Fowler
No dia do meu aniversário ano passado Martin Fowler publicou em seu blog um post interessante no qual apresenta uma definição do que vêm a ser NoSQL que se tornou bastante aceita entre todos nós desenvolvedores e que usarei como base neste post.Curiosamente, não estou sozinho, o próprio Fowler diz em seu post que o termo é bastante fraco. Bom: ele apresenta cinco características definidoras destes sistemas gerenciadores de bancos de dados que, analisando com maior profundidade, nada definem.
Primeira característica: não usam o modelo relacional (ou a linguagem SQL)
Um rápido sofisma contra este que é o atributo mais popular. Se aponto para um SGBD e o caracterizo como relacional já o distingo de todos os demais que, consequentemente, seriam não relacionais, ou seja, ao nascer o modelo relacional criou-se o “nosql”. Eu avisei que seria um rápido sofisma: não consegui segurar.
Por exemplo: se digo que meu computador não é de ouro – “NoGold” – isto quer dizer que ele pode ser de qualquer outra coisa, ou seja, não estou o caracterizando de uma forma que agregue significado.
Voltemos para a segunda parte desta característica: não usar a linguagem SQL. Novamente, uma definição engadora, pois se for levada à risca, Hadoop, que muitos caracterizam como NoSQL vai sair da lista, pois já há iniciativas como esta que levam a linguagem de consulta SQL para bancos de dados não relacionais. E convenhamos, iniciativas como UnQL nada mais são do que tentativas de trazer para estes SGBDs todas as vantagens que o SQL nos dá.
(sobre os problemas do SQL, sugiro a leitura deste excelente texto)
Segunda característica: open source
Não há muito o que dizer a respeito pois não os diferencia em absolutamente nada. MongoDB, MySQL, PostgreSQL, Riak, Redis, tudo se iguala pensando neste atributo isoladamente.
Terceira característica: desenvolvidos para serem executados em grandes clusteres (ou clusters?)
O movimento NoSQL surge como uma alternativa de escalabilidade: ao invés da mais popular até então, a vertical, maior atenção foi dada à horizontal, ou seja, à possibilidade de atingirmos uma melhor performance adicionando novas máquinas à nossa rede distribuindo o processamento.
Ok, diversas soluções NoSQL foram criadas pensando nisto, no entanto há bancos de dados relacionais que também foram criados com o mesmo objetivo. Até então a maior parte das soluções relacionais escalava com muita dificuldade quando as bases de dados cresciam significativamente, então você começa a abrir mão de um ACID completo, teorema de CAP ganha popularidade, etc.
Mas vemos há anos soluções relacionais como Oracle, PostgreSQL ou soluções como JustOneDB (mais nova, mas muito interessante este último) também obtém este resultado. Mais um atributo que não diz muita coisa. Alguém poderia dizer que estas soluções não surgiram para este fim, é verdade: mas conforme elas evoluiram com o tempo, este se tornou um requisito importante que em grande parte foi satisfeito.
Quarta característica: baseados nas propriedades da web do século XXI
Quais seriam estas características? Clusteres gigantes? Já falei sobre isto nos parágrafos anteriores. Baixo custo? Firebird, SQLite, Access (sim, Access), MySQL e outros são soluções de baixo custo. Necessidade de mudanças constantes nos atributos? Ok: você não devia estar usando um banco de dados relacional, pois o foco deste são registros (leia este texto fantástico de 1979 sobre as limitações dos registros).
Novamente, muito amplo: e todo revendedor de soluções relacionais atualmente diz que estes são adequados para os tais desafios da web do século XXI.
(to torcendo para não aparecer um vendedor por aqui com aqueles folders “propriedades da web do século XXI”)
Quinta característica: ausência de esquema
Este atributo acaba nos jogando de volta à primeira característica e outra: nos trás outro problema. O fato de que, tomado isoladamente igualar os modelos documental, chave-valor, baseado em grafos e outros.
Tá: qual a solução então?
A mais simples possível: evitar usar o termo NoSQL já que como expus não diz muita coisa. Ao invés é muito mais interessante usar apenas o nome que caracteriza o modelo usado. Por exemplo: ao invés de dizer coisas do tipo “eu uso uma solução NoSQL chamada MongoDB”, diga “uso um SGBD documental chamado MongoDB”.
Isto evitaria frases que não fazem muito sentido, como por exemplo “vou fazer um curso de NoSQL” (um curso eterno, pois os modelos são infinitos), “programo em NoSQL”, etc. Começariam a surgir frases mais interessantes como “sou especialista no modelo documental, chave-valor, colunar, etc.”.
Claro que eu vou continuar usando o termo (to usando neste post) pois há inércia e pressão social para tal, mas acredito que a partir do momento em que passarmos a usar mais os nomes dos paradigmas, melhor. E convenhamos, o termo, como o próprio Fowler diz em seu post, surgiu por acaso: pra quê eternizar o erro, não é mesmo?
E quando penso em NoSQL como “not only SQL”?
Pior ainda, porque agora você colocou o relacional JUNTO com o não relacional: tudo se igualou e nada foi caracterizado. Neste sentido, acho muito mais interessante a emergência de termos como persistência poliglota (Fowler de novo) que, aliás, acredito ser o caminho que deveríamos seguir.
PS: esse Fowler é foda hein? Adoro os artigos dele em que há este tratamento conceitual.
Salve, Kico!
Eu ainda não sei absolutamente nada sobre bancos de dados que não sejam relacionais, mas estou acompanhando seus últimos posts e isso está me despertando o interesse. Só que eu não sei por onde começar, já que “NoSQL” em si não quer dizer nada mesmo. Por exemplo, que tipo de aplicação eu poderia desenvolver mais facilmente com cada modelo?
Uma coisa que eu achei interessante, sobre a persistência poliglota: vc sabe se ainda não há nenhuma iniciativa para “juntar” N modelos em uma solução integrada, por exemplo: em *uma transação* eu poder atualizar o grafo dos “amigos” de meu usuário, um registro na tabela de comentários relacionado a esse usuário no grafo, e o documento do perfil desse usuário? (sim, eu sei que viajei, mas não é nesse sentido que as coisas tinham que caminhar?)
Oi Éderson,
neste caso, o que você precisa são das transações distribuídas (XA). Já há bastante coisa nesta direção inclusive. O problema no entanto é o seguinte: nem todo SGBD implementa transações que sejam 100% ACID. Então neste caso você tem um desafio bem maior, e vai variar demais de acordo com o contexto.
(criei um novo post porque o Reply está dando a mensagem: “ERROR: Can’t find the ‘commentformid’ div”)
O que vc quer dizer é que não adiantaria usar o XA se meus NoSQL’s não forem completamente ACID? Foi o que eu entendi, depois de ler o que a Wikipedia em inglês diz sobre XA. Inclusive necessitaria que o commit de cada SGBD fosse em 2 fases, correto?
O que eu quis dizer é que na realidade não sei se já existe uma solução satisfatória para este problema. Varia demais de acordo com cada situação, então fica bastante complicado poder dar uma resposta genérica.
Eu acredito que soluções para estes problemas vão surgir, especialmente se termos como persistência poliglota se tornarem mais populares, mas até lá o que temos de fazer mesmo é esperar ou, quem sabe, melhor ainda, bolar uma solução para isto. :)
Gostei muito post!
Sempre achei estranho o termo “NoSQL” e a maneira como o pessoal usa por aí.
Também acho que algumas características que o pessoal costuma falar nem sempre funcionam bem na prática.
Schema-free por exemplo, por mais que seja dessa forma, não consigo imaginar um banco de dados orientado a documentos em que não se siga um esquema padrão nas coleções de dados, pelo menos na parte da aplicação.
que bom que gostou Everton, valeu!
Interessante o post, creio que foi único que achei desconstruindo o NoSQL.
Uma questão que fica seria:
Se as grandes empresas, que possuem BigData, estão utilizando quer dizer que isso “solucionou” o problema que tinham antes com um banco de dados relacional?
Ou o NoSQL aparenta uma “solução” mas na verdade seria a máscara de um problema maior?
Ótimo post Kico.
Oi Herlon, obrigado!
O que eu me pergunto é o seguinte: foi somente com NoSQL que se “resolveu” (se é que resolveu) o problema do Big Data (se é que é realmente um problema) ou seria tudo isto muito mais hype que o necessário?
O grande lance que vejo no uso do NoSQL é que o modelo de dados muitas vezes é o mais apropriado. Pega o modelo documental, por exemplo: é ideal quando você lida com informação que não se encontra rigidamente formatada, ou que possuí uma variação muito grande. Torna sua vida mais simples. No entanto é interessante observar que muitas vezes o que chamam de Big Data na realidade é o nosso bom e velho Business Inteligence usando ferramentas mais antigas como o OLAP por exemplo.
Se entendi bem então o NoSQL foi feito para trabalhar com grandes variações de dados sem (muita) formatação?
Por exemplo, quando eu estava dando uma olhada em como usar eu percebi (pode ter sido um erro meu) que criando uma estrutura de blog (post,autor,comentários) eu teria que relacionar o post ao autor ou teria que duplicar os dados de quem é o autor:
Post -> titulo (varchar)
data (datetime)
conteudo (text)
autor(_id?) (ObjectID)
Com isso não tornaria a ser um modelo relacional novamente? Pois estou relacionando a postagem com um autor.
Em alguns testes que fiz (em uma tabela com 200 000 resultados) percebi que em alguns casos o MySQL saiu mais rápido e fácil que o MongoDB.
Uma consulta no MySQL eu usaria: SELECT id_produto FROM keywords WHERE keyword LIKE ‘%notebbok%acer%3gb’
Já no MongoDB (pode ter sido outro erro meu criar o seguinte Regex) tive que criar um Regex que combinava as palavras: notebook acer 3gb. Resultando em: /notebook.+acer.+3gb|acer.+3gb.+notebook|3gb.+notebook.+acer/i
E o tempo para executar a query foi assombroso.
Creio que eu devo ter feito algo errado.
Abraço.
Oi Herlon, aí que tá.
Eu não sei nem se podemos dizer que NoSQL “foi inventado”, porque é algo que sempre existiu. NoSQL se for tudo o que não é baseado no modelo relacional engloba qualquer coisa não relacional. Um arquivo texto, por exemplo, que pode ser visto como um banco de dados, cairia na categoria NoSQL.
Mas a aplicação para informação que não é rígidamente definida é uma opção sim, e é justamente um ponto no qual o modelo relacional pode dificultar a sua vida.
Saudações!
Kico, é a primeira vez que leio seu blog e quero dar os parabéns pelo conteúdo. Comecei há pouco a estudar “NoSQL” e a primeira coisa que em intrigou nesse novo mundo foi justamente o nome. Realmente o termo NoSQL não define a estrutura de dados que está sendo utilizada e ainda dificulta a pensar no problema que está se propondo resolver.
Comecei estudando bancos de dados orientados a grafos justamente porque meu problema era referente a redes sociais, relacionamentos.
Outra coisa que percebi é que os desenvolvedores estão muito focados em usar a tecnologia só porque é novidade. Tem um milhão de tutoriais sobre como configurar isso ou aquilo, mas não se vê quase nada focando em arquitetura, solução de problemas, modelagem, etc.
Acho que já está na hora de amadurecer mais estas questões, pois a ideia de “NoSQL” já não é mais tão novinha assim.
Oi Rodrigo, que bom que gostou, valeu!
Na realidade, se você olhar com atenção, vai ver que a maior parte dos nossos problemas surge da nossa má compreensão da linguagem. Especialmente os nomes que damos às coisas.
Sim. A semântica é algo importantíssimo e que muitos desprezam.
Trabalho com BI há alguns anos e um dos grandes problemas na hora de construir um DW é justamente entender o significado dos termos de negócio. Cada área de negócio dá um nome diferente pra mesma coisa, ou o mesmo nome para coisas diferentes e isso dentro da mesma corporação. Até homogeneizar a bagaça toda é um Deus nos acuda. rs E Infelizmente na TI não é tão diferente.