10 min.
NoSQL. Qual é a deles?
NoSQL é um termo que causa uma certa estranheza. É um termo não muito bem definido. Não há um padrão, ou entidade que o regule. E as definições que existem por aí não são muito consistentes. Sem falar que o termo envolve um conjunto de ferramentas que não são as mais populares por aí.
Mas então, o que eles trazem para o jogo? Por que utilizá-los? E qual parece ser a posição deles hoje no mercado? Bem, entender estes pontos é o objetivo desse artigo.
Nos últimos meses, venho estudando um pouco sobre essas ferramentas, tanto do ponto de vista teórico quanto prático. E apesar de ainda não ter concluído este último ponto, a lógica por trás dessas ferramentas é algo intuitivo de entender, e traz pontos relevantes a se pensar no planejamento de um projeto. Mesmo que você não planeje utilizar essas ferramentas um dia, o exercício mental de entendê-las vale a pena :).
O que é NoSQL?
Da maneira mais simples possível, o NoSQL define todo o conjunto de ferramentas de Banco de Dados que não seguem o modelo relacional bem estruturado e conhecido de bancos de dados SQL, como o MySQL e o PostgreSQL. O NoSQL vai além de tabelas rígidas, definidas em colunas armazenando um único valor de tipo fixo, e expande para diversos cenários que requerem estruturas mais complexas, como listas, estruturas aninhadas e até grafos, trazendo uma forma de armazenar e acessar estes dados mais performática e escalável do que o que é possível fazer com as soluções mais tradicionais.
Porque (e para quem) o NoSQL surgiu?
O NoSQL foi criado como resposta a duas problemáticas principais existentes na época de sua criação, mas que continuam pertinentes até hoje:
- Os desenvolvedores de aplicativos enfrentavam o desafio de armazenar estruturas de dados cada vez mais complexas e específicas, que não eram naturalmente suportadas pelos bancos de dados relacionais, o que geralmente necessitava de um trabalho extra na modelagem dos dados em mais tabelas e consequentemente em estruturas mais complexas. Esse problema ficou conhecido como descasamento de impedâncias.
- O desafio de armazenar mais e mais dados levou à necessidade de escalar e aumentar os servidores e recursos que sustentavam às aplicações. Nesse cenário, a clusterização, que consiste na prática de usar vários servidores em conjunto para sustentar uma aplicação ao invés de uma única máquina, ganhou grande popularidade. Porém, os bancos de dados relacionais simplesmente não suportavam essa funcionalidade.
O restante desse texto, analisa as principais características dos sistemas NoSQL que atacam essas problemáticas.
Estruturas de Dados Mais Complexas
O primeiro problema é solucionado de maneira óbvia pelo suporte de estruturas mais complexas e variadas para modelagem e armazenamento dos dados. E aqui, o mundo é um pouco vasto, e cada ferramenta NoSQL possui suas próprias características e destaques. Desde bancos que armazenam documentos que lembram estruturas de um JSON, passando por estruturas colunares mais complexas até bancos que mapeiam relações entre entidades através de grafos, ferramentas para os mais diversos cenários e problemas podem ser encontrados.
E para tornar tudo isso ainda mais complexo, o NoSQL ainda permite uma liberdade para tudo isso: A liberdade de Schemas.
Livre de Schemas (ou mais ou menos isso)
A liberdade de Schemas significa que os dados contidos em um determinado conjunto não precisam necessariamente seguir um padrão rígido de organização de seus campos assim como acontece em bancos de dados relacionais, onde cada tabela define um conjunto específico de colunas, com tipos definidos, que devem ser estritamente obedecidos por todo registro que for adicionado a elas.
No NoSQL isso não é algo estritamente necessário, ou seja, dentro de um mesmo conjunto de dados, podem existir registros com mais ou menos atributos do que outros, ou até mesmo registros totalmente diferentes uns dos outros. O banco de dados por si só trata todos eles como registros válidos.
Dados de um mesmo conjunto, mas em diferentes formatos.
Mas fica a questão: Qual a real utilidade disso? Do ponto de vista de uma aplicação, não faz muito sentido armazenar dados em um mesmo conjunto sem um padrão. Tomando como exemplo uma tabela que armazena dados de usuários, não é muito útil armazenar um registro com um campo chamado “username” e outro com o mesmo campo chamado de “login”, ou mesmo armazenar um usuário com e-mail e outro sem. Toda interação da aplicação com um banco de dados, espera de certo modo um padrão. Ao exibir o nome do usuário na página de boas-vindas, a aplicação espera encontrar e obter essa informação do banco de dados no campo “nome” do conjunto de usuários, por exemplo. Se um registro possui esse campo com outro nome, ou nem possui esse campo, bem, teremos um problema.
Então apesar de não ser estritamente necessário na teoria, na prática manter um padrão de organização dos dados ainda é necessário no NoSQL. A diferença aqui é que como o próprio banco de dados não liga muito para isso, é a própria aplicação que deve gerenciar e garantir que todos os dados inseridos no conjunto sigam o padrão que ela espera encontrar.
Mas a pergunta ainda continua (e agora ainda mais reforçada): Então, se ainda precisamos de um padrão, qual a real utilidade de não haver restrição de schemas? A vantagem está na possibilidade de evoluir o schema facilmente quando necessário.
Voltando ao exemplo de usuários, imagine que temos um conjunto de dados contendo suas principais informações e surge uma demanda para que seja adicionado um novo campo indicando se o usuário pertence ou não a um grupo VIP de clientes da plataforma. Fazer isso em um banco de dados relacional envolveria realizar uma operação de alteração na tabela para que a coluna fosse adicionada, de forma que todas as linhas passariam a ter a nova coluna, sem um valor preenchido. A partir disso, o novo valor poderia ser inserido ou alterado pela aplicação. Em NoSQL, adicionar o novo campo simplesmente envolve em adicioná-lo nos registros da base, sejam novos ou antigos e nada mais precisa ser feito. Simples assim.
E em tempos de Metodologias Ágeis, alterar o projeto com facilidade durante o seu desenvolvimento é uma excelente vantagem.
As duas características exploradas até agora resolvem (e facilitam) o problema de Descasamento de Impedâncias. Mas e quanto ao problema da Clusterização? Bem, a resposta está no conceito de Agregados.
A noção de Agregados (através de um exemplo que custou caro)
Imagine que você quer montar seu próprio computador e para aprender mais sobre isso comprou um livro sobre Arquitetura de Computadores. O livro custou um certo valor, e como você comprou pela internet, precisou pagar um frete, e esperar alguns dias até que ele chegasse na sua residência.
Só que ao chegar, você percebeu um problema: O livro na verdade era uma introdução de uma coletânea de livros, de forma que as informações sobre cada parte do computador, como processador, memória e placa mãe, estavam escritas em partes diferentes. Ou seja, o primeiro livro que você comprou, não entregava toda a informação que você precisava, de forma que você precisa comprar outros livros e juntar partes de todos (ou pelo menos da maioria) deles para de fato aprender como montar seu computador. E obviamente, isso deixa as coisas um pouco mais caras, com mais livros, mais fretes e mais tempo esperando as entregas até cumprir o seu objetivo.
Uma estranha coleção de livros.
O motivo pelo qual bancos de dados relacionais não suportam o funcionamento em clusters se deve ao fato de que os seus dados geralmente são organizados como a coletânea de livros: as informações estão espalhadas em diversas tabelas, cada uma especializada em um determinado conceito ou unidade de negócio. E se armazenarmos todas essas informações conectadas em um cluster, suas tabelas ficarão espalhadas dentre diversas máquinas, assim como nas diferentes partes da coletânea de livros. E da mesma forma, ao realizar uma consulta que envolvesse informações de diversas tabelas, precisaríamos consultar dados em diversas máquinas para obter toda a informação necessária.
Dados sendo buscados em um Cluster.
E no caso de uma consulta a um banco de dados, não basta simplesmente consultar as diversas tabelas. Precisamos juntar todas as informações necessárias e devolvê-las ao usuário que as requisitou. E em um cenário de cluster, isso envolveria consultar várias tabelas localizadas em diferentes servidores, identificar as informações necessárias e transferí-las para um lugar central, onde elas devem ser agregadas em um único resultado que deve ser devolvido ao usuário. Só que assim como obter um novo livro requer o custo de um frete para transportá-lo até sua casa, a transferência de dados entre servidores também tem o seu custo, só que o “frete” aqui é feito pela internet. Logo, consultas de grandes volumes de dados, envolvendo várias tabelas facilmente gerariam um custo enorme.
Bem, o NoSQL resolve isso de uma maneira que você talvez tenha questionado lá no início do não tão criativo exemplo da coletânea de livros que criei: Por que raios todos os livros da coletânea simplesmente não são vendidos em um único volume? Essa é a ideia do conceito de Agregado, que consiste numa unidade de dado onde todas as informações necessárias, relacionadas a um mesmo conceito ou tópico, estão contidas.
Visitando uma última vez o exemplo de dados de usuários, em um banco de dados relacional provavelmente teríamos uma tabela central de usuários contendo suas informações básicas rodeada por algumas outras, contendo informações mais específicas como endereços, formas de pagamento, permissões no sistema, entre outros. Em um agregado, por sua vez, basicamente tudo isso estaria junto em um único conjunto de dados (com provavelmente o auxílio de estruturas de dados aninhadas) e ao acessar o registro de um determinado usuário, todas as suas informações já estariam disponíveis, sem a necessidade de consultar outras tabelas.
Um modelo de banco de dados relacional vs um Agregado.
E isso não se resume a apenas uma questão de praticidade na leitura dos dados, mas também é um ataque direto ao problema de armazenar dados em clusters. Agora, como todas as informações de um determinado registro estão contidas em um mesmo lugar, não existe mais o problema de consultar dados espalhados em vários servidores e transferir informações pela rede. Consultar um determinado registro vira simplesmente uma tarefa de descobrir em que servidor ele se encontra e carregá-lo para obter todas as suas informações. Nada mais de comprar várias edições de livros, tudo já é vendido em um único pacote.
Com os agregados, ler dados de um cluster fica bem mais fácil (e mais barato).
Conclusões
Bem, tudo isso é só um pouco sobre tecnologias NoSQL, ainda mais considerando que estamos falando de uma maneira genérica. A quantidade de bancos de dados é vasta, cada um com suas especialidades e peculiaridades.
Mas apesar de todas as suas vantagens, o NoSQL não é a solução mais popular de banco de dados e os bancos relacionais ainda continuam dominando o mercado, de longe. O SQL tornou-se um padrão muito sólido no desenvolvimento de aplicações e desbancá-lo parece quase impossível nos dias de hoje. Dessa forma, a tendência que parece mais frutífera para os bancos de dados não relacionais não é a de substituir bancos tradicionais, mas a de ser utilizado lado a lado com eles, armazenando dados em situações que requerem modelagem de dados específicas e mais complexas que podem ser implementadas de maneira bem mais eficiente nestas ferramentas. Mas em situações comuns, acho que ainda veremos o SQL e Bancos Relacionais dominarem diversas arquiteturas por alguns anos pela frente.
Referências
NoSQL Essencial: Um Guia Conciso para o Mundo Emergente da Persistência Poliglota por Pramod J. Sadalage e Martin Fowler
