A hora e vez do NOSQL (Not Only SQL): Persistência Poliglota

A primeira vez que me deparei com o termo NoSQL imaginei que ele se referia a "No SQL": nada de SQL, uma ruptura com o nosso modo relacional de pensar em persistência. Como todo conceito revolucionário, causa muita resistência na maioria das pessoas por trazê-las fora da "zona de conforto".

Uma releitura necessária sobre o assunto me trouxe o acrônimo NOSQL como "Not Only SQL": não somente SQL. Esta sim, uma definição muito mais palatável e apropriada sobre o assunto. O "Not Only" pressupõe a convivência (pacífica, espero) entre tecnologias consolidadas e a inovação. Chamo de inovação, mas vale enfatizar que estas soluções já encontram-se num nível bastante avançado de maturidade.

NOSQL não é a solução para todos os problemas. Mas trouxe à luz da discussão uma máxima da computação que é "utilizar a ferramenta correta para o problema correto". Não consegui rastrear o autor original, mas esta citação é uma de minhas favoritas:

"A good algorithm is like a sharp knife - it does exactly what it is supposed to do with a minimum amount of applied effort. Using the wrong algorithm to solve a problem is trying to cut a steak with a screwdriver: you may eventually get a digestible result, but you will expend considerable more effort than necessary, and the result is unlikely to be aesthetically pleasing."

Ou numa tradução literal:

"Um bom algoritmo é como uma faca afiada - faz exatamente o que deve ser feito com uma quantidade mínima de esforço. Utilizar o algoritmo errado para resolver um problema é como tentar cortar um bife com uma chave de fenda: você eventualmente pode conseguir um resultado digerível, mas vai gastar muito mais esforço do que o necessário, e o resultado não será esteticamente agradável".

Como todo conceito "novo" muita coisa vai mudar antes de se consolidar, mas baseado na minha experiência no assunto, o que eu posso recomendar é:

• Se os seus dados são homogêneos, com poucos relacionamentos entre entidades e numa grande quantidade: use um banco de dados. O modelo relacional foi feito pra isso.
• Se os seus dados possuem muita variação entre um e outro (o que num banco de dados implicaria em muitas colunas vazias ou em muitos relacionamentos com outras tabelas): use uma base de documentos como o MongoDB.
• Se os seus dados possuem muitos relacionamentos com outras entidades (com possível necessidade de geolocalização): use uma base de grafos como o Neo4j.
• Se os seus dados são do tipo chave-valor (key-value) e você precisa computar grandes quantidades (voláteis) desses dados com alto desempenho: use uma base de dados chave-valor em memória como o Redis.
• Se os seus dados são do tipo chave-valor (key-value) e você precisa persisti-los: use uma base de dados chave-valor persistente como o Riak.

Farei uma menção honrosa para as situações em que você precisa de uma base de dados confiável, de altíssimo desempenho e transacional: use o Prevayler ou o Disruptor para prevalência de objetos.

Vale ressaltar que a persistência poliglota pressupõe a coexistência destas diferentes bases de dados na mesma aplicação. Avalie e considere a utilização de mais de uma base de dados se for adequada ao seu problema. Mas não caia na tentação de "vou usar o XXX porque é bacana". É o mesmo pecado de se utilizar um Design Pattern só porque ele é "bonito". Tem que resolver um problema.

Todo essa excitação ao redor do NOSQL também está relacionada, claro, ao conceito de BigData. Todas estas bases de dados alternativas foram construídas com a premissa de tratar imensos volumes de dados que bancos de dados relacionais não estão preparados para lidar.

Avaliem todas estas novas alternativas e estejam preparados para, no problema certo, utilizarem a base de dados certa. Boa sorte!