Redis e Java - Revista Java Magazine 114

A consolidação do modelo relacional nas últimas três décadas trouxe a falsa impressão de que esta se trata da única abordagem existente ao lidarmos com o problema da persistência de dados. Quando pensamos em banco de dados, logo vêm à mente ideias como tabelas, índices, linhas e colunas.

Com o tempo observou-se um crescimento significativo do tamanho das bases de dados e, com este aumento, as limitações do modelo relacional – não raro resultantes de sua má aplicação – se tornaram mais claras, colocando em evidência uma série de bancos de dados identificados por NoSQL, que nos oferecem uma alternativa ao SQL e ao modelo relacional.

Neste novo contexto o desenvolvedor se vê diante de novas abordagens no modo como a informação é persistida e recuperada. Enquanto no SQL lidamos com uma linguagem declarativa, no NoSQL muitas vezes recuperamos os dados de forma imperativa: um modo de trabalhar bastante diferente daquele com o qual estamos habituados.

E nesta nova e inicialmente “assustadora” realidade temos o Redis, um banco de dados NoSQL baseado no modelo chave-valor que, como veremos, é um poderoso complemento ao cinto de utilidades de todo desenvolvedor e arquiteto que tenha por objetivo suprir as fissuras que agora se mostram evidentes no modelo relacional.

NoSQL?

NoSQL compreende um conjunto de ferramentas complementares e concorrentes que nos fornecem uma rica alternativa ao modelo relacional e à linguagem SQL, que é intrinsecamente relacionada a este tradicional paradigma. O significado do termo NoSQL possui duas interpretações. A mais ingênua o entende como um substituto completo ao padrão relacional, enquanto a segunda o vê como um complemento.

Para melhor entender o NoSQL, faz-se necessário que sejam expostas as características básicas do modelo relacional (SQL) que, simplificando, seriam as seguintes:

· Toda informação é armazenada em tabelas, que são estruturas de dados compostas por linhas (registros) e colunas (campos);

· Todo registro é bem estruturado, ou seja, é composto por um número finito de campos, cada qual com um tipo de dados bem definido e, muitas vezes, com regras de validação em cada um já embutida;

· Tem o objetivo de minimizar a redundância dos dados, o que é feito através do relacionamento entre as tabelas;

· É recomendada a existência de uma coluna para identificar unicamente o registro (a famosa chave primária), que será usada, dentre outras coisas, também no relacionamento entre as tabelas.

Uma característica fundamental do modelo relacional diz respeito ao modo como recuperamos as informações: por meio da linguagem SQL. Toda consulta é feita declarativamente, ou seja, informamos o quê deve ser buscado e não como. É trabalho do SGBD escolher quais algoritmos devem ser empregados, escolha esta na maior parte das vezes bem sucedida, aumentando significativamente a produtividade do desenvolvedor, que antes do sucesso do modelo relacional precisava implementar estes algoritmos manualmente. Entretanto, conforme nossa modelagem se torna mais complexa e o tamanho dos bancos de dados aumenta, perdemos a previsibilidade do custo computacional de nossas consultas. Deste modo, uma consulta envolvendo junções que inicialmente apresentava performance excelente, ao lidar com bases de dados maiores, normalmente distribuídas em mais de um servidor, acaba por se mostrar ineficiente, muitas vezes forçando a equipe de desenvolvimento a desnormalizar tabelas ou buscar estratégias alternativas para resolver o problema.

Neste momento, a natureza declarativa que até então se mostrava como vantajosa, se torna um problema. Normalmente a solução para estas limitações do modelo relacional consiste em transferir a responsabilidade da implementação dos algoritmos de busca para o interior da nossa aplicação, tornando a solução SQL aquilo que ela não é, isto é, imperativa.

O modo como as informações são organizadas no modelo relacional também se mostra um desafio neste mundo de bases de dados enormes em complexidade e/ou tamanho. Estamos lidando com uma solução restritiva, onde cada campo agrega uma série de regras que definem o tipo de informação a ser armazenada. Chamamos estas regras de esquema (ver Nota DevMan 1), e sua presença é uma solução excelente quando lidamos com informações bem estruturadas. Infelizmente o que se mostra com o passar do tempo é que a maior parte das informações presentes no mundo não é estruturada. Não raro o desenvolvedor se depara com situações nas quais apenas uma parcela pequena das colunas de uma tabela é preenchida, o que torna todas as demais inúteis na maior parte dos registros.

É importante que não caiamos aqui na ilusão causada pela empolgação atual com bases de dados NoSQL. O modelo relacional é sem sombra de dúvidas o mais bem sucedido da história da computação. Suas deficiências são em sua maior parte fruto de sua má aplicação. Para o que foi originalmente concebido: armazenar informações bem estruturadas na forma de tabelas relacionadas entre si, temos um modelo com raríssimas falhas. No entanto, é interessante observar que há diversos casos nos quais não obtemos os dados de forma declarativa por estes não serem facilmente representáveis no formato tabular. Para estes casos entram em cena as opções NoSQL, que na maior parte das vezes se mostram não como substitutos, mas como excelentes acessórios à disposição do desenvolvedor ao enfrentar este tipo de dificuldade.