Desconstruindo NoSQL: em busca de melhores termos

Texto escrito em 2013

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

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.