Introdução ao NoSQL

O sucesso do modelo relacional costuma gerar a falsa impressão de se tratar da única solução possível para o problema da persistência e obtenção de dados. Dentre as consequências desta falsa impressão está a ausência de questionamento a respeito de quando este modelo deve ser aplicado, o que muitas vezes leva equipes de desenvolvedores a projetar soluções mais complexas que o necessário, caras do ponto de vista computacional e difíceis de serem mantidas. A emergência de soluções não relacionais – os bancos de dados NoSQL – trouxeram como grande ganho à TI o fato de termos agora de forma acessível outros modelos de persistência/consulta que nos permitem, em sua comparação com o modelo relacional, perceber de forma mais clara suas limitações e os contextos nos quais este de fato deveria ser aplicado.

Esta comparação entre diferentes soluções de persistência e obtenção de dados trouxe outro ganho interessante para a comunidade de desenvolvedores: o fato de terem sido colocadas em primeiro plano questões até então tidas como resolvidas, como por exemplo os problemas de escalabilidade decorrente do crescimento de tamanho e complexidade das bases de dados relacionais, além de também por em cheque diversas práticas que até o presente momento víamos como ótimas.

É importante salientar que quando falamos sobre as limitações do modelo relacional não necessariamente nos referimos a defeitos do modelo, mas sim na maior parte das vezes da sua má aplicação. Seria tolice após mais de 40 anos da publicação do artigo de Edgar F. Codd em que o modelo relacional é apresentado pela primeira vez rotulá-lo como uma solução ruim, muito pelo contrário: desde que foi lançada a primeira implementação comercial bem sucedida em 1979 pela Oracle de um SGBDR, este se tornou o padrão da indústria no que diz respeito à armazenagem e obtenção de dados. Tamanho sucesso não seria possível apenas com marketing, mas sim pelo simples fato de ser uma solução que por todos estes anos atendeu e bem as necessidades do mercado.

Entretanto, conforme o tamanho e a complexidade na modelagem dos bancos de dados foi aumentando, o mercado sentiu de forma sensível as limitações decorrentes da nossa obsessão por representar qualquer informação sob a forma de linhas e colunas. A modelagem de dados se mostrava cada vez mais difícil de ser feita, e não raro nos víamos na necessidade de executarmos o exato oposto do que nos fora ensinado até então: desnormalizar os dados a fim de aumentar a performance de nossas consultas e com isto tentar minimizar os graves problemas de escalabilidade que não batiam a nossa porta, mas sim arrombavam-na. Tornava-se claro algo que até então a maior parte de nós negava: o fato de a maior parte das informações presentes no mundo não ser fortemente estruturada, mas sim o contrário. E neste momento histórico vemos a emergência de popularidade das soluções não relacionais, isto é, os hoje tão falados bancos de dados NoSQL.

Entendendo o modelo relacional e sua principal limitação na modelagem de dados

Uma consequência interessante da ubiquidade do modelo relacional é o fato de nos vermos raramente pensando a seu respeito. Raríssimas vezes nos questionamos sobre a sua unidade básica que é o registro e quando este pode ser aplicado. É interessante que antes de tratarmos dos bancos de dados relacionais façamos uma breve discussão a respeito desta estrutura de dados para, assim, compreendermos algumas de suas limitações básicas no que diz respeito à modelagem de dados, que tem como consequência direta os problemas de escalabilidade mencionados na introdução deste artigo.

Qual a essência de um registro? Em um banco de dados relacional é uma estrutura de dados bidimensional e homogênea. Por homogêneo entenda algo que mantém suas propriedades em toda a sua extensão, ou seja, é uniforme. Um conjunto de números inteiro é internamente homogêneo, pois todos os seus elementos compartilham exatamente das mesmas propriedades. Já a característica bidimensional do registro se deve ao modo como este é representado: verticalmente por suas linhas e horizontalmente por seus atributos ou colunas. É importante tratarmos da questão da homogeneidade, por não se tratar de uma característica auto evidente para muitos de nós que encaram pela primeira vez os modelos não relacionais.

A homogeneidade horizontal diz respeito aos campos que compõem um registro. De forma ideal, em uma tabela todos os registros que a compõem representam uma mesma entidade ou seus subtipos. Sendo assim, é natural que todos possuam o mesmo conjunto de atributos: conjunto este de tamanho fixo composto por campos que, em sua forma mais básica são formados por três atributos: nome, tipo e tamanho. Claro, um campo pode possuir mais atributos de acordo com o fornecedor do seu SGBDR, como por exemplo descrição, regras de validação, etc. Horizontalmente, podemos dizer portanto que temos uma estrutura de dados fortemente estruturada e rígida no sentido de que, uma vez em produção, a inclusão, remoção ou edição de campos é um procedimento caro tanto do ponto de vista computacional e financeiro dada a sua dificuldade de manutenção.

Verticalmente a homogeneidade se manifesta sob a forma da tabela que possui o papel de agregar lógica e fisicamente todos os registros que pertençam a um determinado tipo. O tipo agrupado pela tabela normalmente é evidenciado pelo nome que damos a esta, como por exemplo funcionário, imóvel, empresa, etc. Cada campo manifesta sua homogeneidade verticalmente quando sempre possui o mesmo significado entre os registros que compõem uma tabela.

Um registro é aplicado com sucesso quando há homogeneidade em suas duas dimensões e tenhamos uma estrutura normalizada, ou seja, quando não há a ocorrência de campos repetidos ou desnecessários. Fica nítida a primeira limitação do modelo relacional: o contexto no qual registros devem ser aplicados como estrutura de dados para representar as entidades de nosso sistema.