Hoje em dia cada vez mais as bases de dados estão a ocupar um lugar de destaque no nosso mundo tecnológico.

Queremos guardar os nossos dados, ter acesso aos mesmos o mais rápido possível e processá-los para termos respostas rápidas. Antigamente os dados guardados eram específicos, em “tabelas contentores”. Hoje, principalmente com Big Data, o nosso próprio telefone guarda tudo o que fazemos e praticamente tudo o que pensamos fazer. E perder “sessenta segundos” por uma resposta que queremos já se torna cada vez mais impensável.

Por este motivo nesta edição decidimos recordar uma discussão antiga… SQL vs NoSQL…

Para os leitores que ainda não estão familiarizados com este tema, vamos por partes… A sigla SQL significa Structured Query Language, ou seja, linguagem de consulta estruturada. Criada no início dos anos 70 na IBM, esta linguagem tem uma forte inspiração na famosa álgebra relacional e devido à sua facilidade de aprendizagem e simplicidade, é sem qualquer dúvida ainda a linguagem padrão mais utilizada quando falamos em bases de dados.

As bases de dados SQL respeitam o modelo relacional, pois baseiam-se no facto de todos os dados serem guardados em tabelas. Temos como principais exemplos de bases de dados SQL, o SQL Server, o MySQL, Sybase, Oracle ou IBM DB2.

Sem querer particularizar muito, podemos afirmar que no SQL temos “três grandes comandos” base… INSERT, UPDATE e DELETE. Com estes três facilmente temos acesso a qualquer registo de uma determinada tabela da base de dados uma vez que a base de dados é relacional e verticalmente escalonável. Tendo em conta que temos ao dispor chaves primárias e/ou estrangeiras, uma vantagem particular do SQL é sua cláusula JOIN simples, que nos permite facilmente recuperar dados relacionados armazenados em várias tabelas .

Ainda nesta temática, com o SQL, sendo a base de dados relacional temos sempre as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). E são estas quatro propriedades que descrevem as principais características de uma transação em SQL ou seja:

Atomicidade

Uma transação deve ter todas as suas operações executadas com sucesso, isto é, em caso de falha de alguma operação, é necessário proceder ao rollback.

Consistência

Uma transação deve respeitar a integridade dos dados.

Isolamento

Deve garantir-se o isolamento de uma operação para que não seja possível que dois utilizadores gravem alterações no mesmo registo ao mesmo tempo.

Durabilidade

As transações com sucesso devem persistir na base de dados mesmo que haja alguma anomalia externa à mesma, ou seja, devemos sempre registar as mesmas em memória não-volátil.

Agora passemos ao NoSQL… NoSQL significa Not Only SQL. Estas base de dados têm características bem diferentes. São bases de dados não relacionais, e as propriedades que acabamos de referir (ACID) deixam de estar obrigatoriamente presentes. A designação NoSQL foi inicialmente utilizada no final dos anos 90 e voltou a ser reintroduzida no início do ano de 2009.

Este tipo de bases de dados foi criado pois o modelo relacional apresenta algumas limitações quando o volume de dados é elevado e as cargas de trabalho são grandes. Assim ao contrário das anteriores, são escalonáveis horizontalmente e geralmente não suportam instruções e operações de junção.

Como vantagens no uso do NoSQL podemos apontar:

• Como a base de dados não é relacional significa que as mesmas têm maior flexibilidade, sendo mais simples de gerir.
• Escalabilidade mais simples através do suporte para MapReduce – por norma as bases de dados são projectadas para funcionar eficazmente mesmo com hardware de baixo custo.
• A maior parte deste tipo de base de dados é open-source – temos como principais bases de dados NoSQL – MongoDB, MarkLogic, Couchbase, CloudDB e Dynamo DB da Amazon.
• Não é necessário desenvolver um modelo de dados tão detalhado como no paradigma relacional – o que nos permite poupar mais tempo no seu desenvolvimento.

Contudo, temos que apontar também algumas das desvantagens do seu uso:

• Não tem uma comunidade ainda bem definida apesar de estar a crescer.
• Faltam ferramentas de relatório para análises e testes de desempenho.
• Falta de padronização – ainda não existe uma linguagem padrão como o SQL sendo que caso seja necessário migrar ou unificar um sistema podem existir problemas que ainda não estão documentados.

Posto isto e sem querer entrar em grandes repetições…

O NoSQL foi criado para ter uma performance melhor e uma escalabilidade mais horizontal para dar resposta às necessidades onde as bases de dados relacionais não são tão eficazes. Regra geral, podemos afirmar que temos 4 tipos de bancos de dados NoSQL:

Documento

Os dados são armazenados como documentos. Os documentos podem ser descritos como dados no formato de chave-valor, como por exemplo, o padrão JSON. (um exemplo deste tipo é o MongoDB).

Colunas

Os dados são armazenados em linhas particulares de uma tabela no disco, podendo suportar várias linhas e colunas. (Um exemplo deste tipo é a base de dados Cassandra.)

Grafos

Os dados são armazenados na forma de grafos (sim… grafos… com vértices e arestas) (Como por exemplo, a base de dados Neo4j.)

Chave-valor

Este é o tipo NoSQL que aguenta maior volume de dados, pois o conceito é que um determinado valor seja acessível através de uma chave identificadora única. (Um exemplo é a base de dados Riak.)

Desta forma, os dados não estruturados (como artigos, fotos, dados de redes sociais, vídeos ou conteúdo dentro de um post de um blog) podem ser armazenados num único documento que pode ser facilmente encontrado, mas não é necessariamente categorizado em campos como numa base de dados relacional.

Em suma, no conceito de modelo relacional (SQL) baseamo-nos em que todos os dados são guardados em tabelas. No modelo não-relacional (NoSQL) não se aplica o conceito de schema: uma chave de valor é utilizada para recuperar valores, conjunto de colunas ou documentos.

Na minha opinião, a principal diferença nos bancos de dados NoSQL é que toda a informação é agrupada e guardada no mesmo registro. Já no SQL precisávamos de ter uma relação entre as várias tabelas para ter acesso toda a informação. Lá está… a diferença prática entre verticalmente escalável ou horizontalmente escalável.

É importante referir que o NoSQL não veio para substituir o SQL, mas sim para oferecer uma alternativa mais flexível ao suporte de dados. Podemos sempre usar ambas as soluções para diferentes casos de uso. Por isso, o mais comum em soluções escalares de sucesso é a utilização de uma arquitetura híbrida, aproveitando o melhor dos dois modelos.