Quando utilizar NoSQL / SQL

Obs.: Antes de mais nada, gostaria de esclarecer que tudo que coloco nesse artigo é baseado em experiências profissionais em projetos que tive a honra de participar que me proporcionaram este nível de conhecimento. Desde já me coloco à disposição para contato e discussão sobre o assunto.

Quebrando paradigmas:

É fato que NoSQL chegou para quebrar uma série de paradigmas e resolver uma série de problemas que eram entendidos como fato e/ou rotina. Quando uma tecnologia tão disruptiva assim chega no mercado certamente ela atende algo que já era uma necessidade.

Os bancos de dados NoSQL chegaram oferecendo uma alternativa mais flexível, escalável e menos dispendiosa se comparada ao que o banco de dados relacional oferece. Todos deveriam fazer as seguintes perguntas antes de iniciar qualquer projeto:

• Até que ponto NoSQL pode de fato substituir os bancos de dados relacionais?
• Quais problemas podemos ter com esse tipo de estrutura?
• Quais alternativas tenho no uso de cada uma?

A má decisão dessa arquitetura pode impactar em uma das maiores coisas mais importantes que uma empresa pode ter, seus dados e informações.

SQL (Structured Query Language):

SQL é a linguagem padrão para gerenciamento de bancos de dados relacionais e manipulação de seus dados. Até a chegada do NoSQL qualquer banco de dados exigia a definição de uma estrutura de dados, previamente desenhada, padronizada e que possibilitasse o armazenamento de dados vinculando tabelas por meio do relacionamento das chaves primárias com chaves estrangeiras e o SQL era o meio de se comunicar e definir essas informações.

Grandes empresas surgiram a partir dessa demanda, elas se propunham contemplar a necessidade e a importância do armazenamento de dados de maneira segura e eficiente. A princípio se pagava caro por isso, mas com o passar dos anos surgiram soluções gratuitas que batiam de frente de maneira muito competitiva.

Um banco de dados SQL, se definido de maneira correta, impossibilita a duplicidade das informações por meio da sua estrutura. Essa é uma característica muito importante pois garante a integridade dos dados e sua identidade individual.

NoSQL:

O termo NoSQL foi primeiramente utilizado em 1998 como o nome de um banco de dados não relacional de código aberto. Mas só a partir 2009 o termo foi utilizado para se falar sobre bancos de dados não relacionais em geral. O termo só pegou depois que Eric Evans (funcionário da Rackspace) decidiu utilizá-lo em um evento que discutia sobre bancos de dados open source distribuídos.

Ao contrário do banco de dados relacional, um banco NoSQL é horizontalmente escalável, permitindo muito mais tráfego por sharding (particionamento de dados).

Existem quatro pontos principais que diferenciam os bancos de dados NoSQL dos relacionais:

• Modelos de dados: Um banco de dados NoSQL permite criar um aplicativo sem precisar definir o esquema primeiro, diferentemente dos bancos de dados relacionais, que fazem com que você defina seu esquema antes de poder adicionar dados ao sistema. Contudo, é bem comum a duplicidade de informações dependendo da estrutura do desenvolvimento ou da velocidade de atualização de dados.
• Estrutura de dados: Os bancos de dados relacionais foram construídos em uma era em que os dados eram razoavelmente estruturados e claramente definidos por seus relacionamentos. Os bancos de dados NoSQL são projetados para manipular dados não estruturados (por exemplo, textos, postagens de mídia social, vídeo, e-mail), que compõem grande parte dos dados que existem hoje.
• Dimensionamento: É muito mais barato dimensionar um banco de dados NoSQL do que um banco de dados relacional, pois é possível aumentar a capacidade dimensionando servidores de commodities baratos. Bancos de dados relacionais, por outro lado, requerem um único servidor para hospedar seu banco de dados inteiro. Para escalar, você precisa comprar um servidor maior e mais caro.
• Modelo de desenvolvimento: Os bancos de dados NoSQL são de código aberto, enquanto os bancos de dados relacionais geralmente são de código fechado, com taxas de licenciamento embutidas no uso de seu software. Com o NoSQL, pode-se começar um projeto sem investimentos pesados ​​em taxas de software antecipadamente.

Incompatibilidade de impedância:

Outro ponto extremamente importante que pode afetar na decisão de qual modelo (SQL / NoSQL) utilizar, é a incompatibilidade de impedância. Uma incompatibilidade de impedância pode ocorrer ao acessar um banco de dados relacional em uma linguagem de programação orientada a objeto (OO). Problemas podem surgir porque linguagens de programação OO, como Java, C++ ou Python, têm abordagens muito diferentes para acessar dados. A questão é que os bancos de dados relacionais funcionam de maneira fundamentalmente diferente do código do aplicativo. Um banco de dados relacional se preocupa com duas coisas: registros e relações entre registros, como denotado por restrições de chave estrangeira. O código de aplicativo funciona com todos os tipos de estruturas e técnicas de dados mais complicadas: hierarquias, iteração, percurso de gráfico. Portanto, quando você cria um segundo modelo de dados paralelo que funciona para o código do aplicativo, não é tão fácil traduzi-lo no modelo de dados existente expresso pelo esquema do banco de dados.

Algumas dessas diferenças incluem:

• Linguagens orientadas a objetos fazem uso intenso de atributos por referência, enquanto isso é tipicamente proibido em bancos de dados relacionais. Os tipos escalares também diferem frequentemente entre o banco de dados e os idiomas OO.
• Em linguagens OO, os objetos podem ser compostos de outros objetos, enquanto isso é impossível em integridade nas linguagens de banco de dados relacionais.
• Os bancos de dados relacionais têm operações primitivas bem definidas para manipular e consultar dados, enquanto as linguagens OO têm operações de nível inferior.
• Bancos de dados relacionais têm abordagens mais robustas para transações para preservar a atomicidade e consistência. A única maneira de garantir isso por meio de uma linguagem OO é no nível dos campos de tipos primitivos.

Os métodos para mitigar a incompatibilidade de impedância incluem o uso de bancos de dados NoSQL e o design de bancos de dados relacionais com linguagens de programação orientada a objeto, além de prestar atenção às diferenças entre os idiomas OO e os bancos de dados relacionais ao codificar um projeto.

Mas qual é a melhor escolha???

Depende! É isso mesmo, depende! Parece uma resposta vaga, mas é fundamental levantar quais serão as características do seu projeto antes dessa definição. Trarei aqui o aprendizado adquirido com um grande líder que passou pela minha carreira, que dizia: “Tire o melhor de cada ferramenta”, e para mim esse é o segredo.

Se não haverá um esquema definido e se o IO for baixo, não pense duas vezes em escolher NoSQL.

Se seu negócio não necessita de definição clara de esquema de banco de dados ou não necessitará de um armazenamento com várias linhas sua opção claramente deve ser o NoSQL, pois você terá uma estrutura econômica e que não necessita de muita burocracia. Além disso, você se beneficiará da velocidade incrível que essa estrutura te dará.

Mas, se você necessita dos benefícios que um banco relacional te dá e também possua informações extremamente custosas para consulta ou armazenamento, ou necessita que alguma parte dos dados tenha atributos que podem ser variados, sugiro o uso misto dessas estruturas.

Mantenha os dados mutáveis em banco relacional e armazene o fixo no NoSQL.

Para ilustrar essa informação, vou trazer um exemplo comum no Brasil que é o armazenamento de uma nota fiscal eletrônica. Por diversos momentos me deparei com armazenamento do arquivo XML em banco de dados relacionais. E, em todos os casos, esse armazenamento era responsável pela maior fatia do tamanho consumido do banco de dados. O que pode facilmente ser resolvido com o vínculo dessa informação, armazenando apenas informações necessárias no banco relacional e o XML propriamente dito em NoSQL.

Pegando o caso da NFe como exemplo, poderíamos ter apenas a chave da nota e o vínculo com a tabela de pedidos dentro de um banco relacional e um registro em um NoSQL onde o index é exatamente a chave da nota e o conteúdo o XML propriamente dito.

Para grandes consultas SQL, faça um resumo NoSQL

Esse tipo de situação é bem comum em vários cenários. O mais comum é o famoso BigData onde você tem um resumo com todas as informações necessárias em uma tabela. Para isso, use o NoSQL! Essa escolha te poupará de diversas dores de cabeça.

Na prática:

Vamos trazer um exemplo prático onde você tem um negócio que armazene as vendas da sua empresa. Imagine que você tem uma tela em um sistema qualquer que necessita trazer todas as informações de um cliente, incluindo pedidos, produtos, notas, tracking de pedidos, dados de pagamento, assinaturas de serviços, detalhes das assinaturas, etc…

Pensou? Agora pensa na consulta que a API fará em seu banco de dados para trazer todas essas informações enquanto chegam mais dados inseridos nas tabelas relacionadas. O resultado definitivamente não será agradável se você tiver apenas utilizando banco de dados relacionais. Para isso, penso que a melhor solução é avaliar qual é o período ideal para atualização de dados, armazenar todas essas informações de maneira resumida em um NoSQL indexado, no caso, com um ID do cliente.

Quando falo de maneira resumida, é resumida mesmo! Ou seja, não é uma réplica de dados, mas sim um resumo com as informações necessárias para um ou mais requisitantes.

Concluindo:

A escolha depende de vários fatores, por exemplo, o tipo de dados que se está analisando, quantos dados tem e com que rapidez você precisa. Por exemplo, para aplicativos como análise de comportamento do usuário, o banco de dados relacional é o melhor, por outro lado, para aplicativos com mídias sociais, textos ou dados geográficos que requeiram grande quantidade de mineração de texto ou processamento de imagem, bancos de dados do tipo NoSQL funciona melhor.

Então, podemos afirmar que, tanto o SQL quanto no NoSQL tem suas vantagens e desvantagens e para definir o melhor modelo (que pode ser SQL, NoSQL ou ambos) depende da aplicação, da forma de desenvolvimento e da estrutura prevista para o ambiente.

Espero ter ajudado de alguma forma, agora o desafio está em suas mãos. Cabe a você chegar a sua própria conclusão!