Muito tem se falado em bancos de dados não relacionais, também conhecidos como NoSQL. Eles se tornaram muito populares e grandes players do mercado, como Twitter, Facebook e Google, para citar alguns, não teriam tantos recursos e escalabilidade em seus serviços se não fossem os bancos não relacionais.

Mas bancos não-relacionais não resolvem todos os problemas e não vão substituir os tradicionais bancos relacionais. Os NoSQLs nasceram com um objetivo específico: preencher algumas lacunas deixadas pelo modelo relacional, sendo uma alternativa de persistência e que podem ser mais adequados para alguns tipos de projetos, mas não para todos.

Dizer que NoSQL vai substituir um banco de dados tradicional é inválido e incoerente, porque estamos falando de arquitetura de dados, de entender como determinada aplicação lê e grava seus dados e, assim, utilizar o modelo mais adequado para que essa leitura e escrita sejam eficientes, sem gerar gargalos.

Além disso, é muito comum utilizar mais de um banco na mesma aplicação – nesse ponto é que surge o termo persistência poliglota –, aproveitando-se o melhor de cada banco. Antes de entrar nesse assunto, é importante lembrar que existem vários tipos de bancos não-relacionais.

Como a persistência poliglota pode ser útil na vida real

O primeiro passo é entender bem cada um dos paradigmas e para que servem. Existem muito mais modelos e tecnologias do que as citadas neste artigo – apenas as principais foram mencionadas aqui –, mas podemos pegar um exemplo da vida real para ilustrar um caso no qual persistência poliglota funcionaria como uma luva: um e-commerce. Pegaremos esse exemplo e simularemos uma arquitetura usando persistência poliglota.

1. Analisando a arquitetura: Um e-commerce precisa ter catálogo de produtos, carrinho de compras, controle de usuários, sistema de recomendações, comentários de usuários e gateway de pagamentos.

Sabemos que a grande maioria das pessoas navega bastante pelo catálogo de produtos e z comparações antes de finalizar a compra. Se você procura um smartphone novo, vai certamente comparar diversos modelos para comprar o seu. Ou seja, a navegação se concentra muito no catálogo de produtos, que nada mais é que documentos compostos de chave/valor com as características de cada produto. E elas mudam dependendo da categoria de produto.

Por exemplo: um smartphone possui algumas características, como câmera, se possui ou não 4G, capacidade de armazenamento, se possui expansão de memória, entre outras, enquanto um refrigerador possui características como 110 volts ou 220 volts, cor prata ou branca, se possui freezer ou não etc. Fazer isso no relacional é custoso, pois é difícil prever todas as características de diferentes produtos. No NoSQL, é bem simples. Se usar um banco como MongoDB, é possível que a estrutura de documento do smartphone seja completamente diferente do refrigerador – isso no mesmo banco e na mesma coleção (tabela).

Sabemos também que o catálogo de produtos é bastante acessado em épocas como Black Friday, Natal e Dia dos Namorados. Se usar MongoDB, pode facilmente ser escalado com sharding, réplicas e assim fazer uma estrutura bastante elástica para evitar que o site fique fora do ar por acessos simultâneos.

Além do catálogo de produtos, temos sistema de recomendação, algo do tipo “quem comprou esse produto também comprou esses outros”. Fazer essa análise é um pouco complicado, pois é necessário cruzar diversos comportamentos e fatores. Fazer isso em grafos é bastante simples, então adotar um banco como o Neo4J para essa etapa é uma saída de mestre, pois um grafo pode fazer essa seleção facilmente.

O carrinho de compras é uma informação temporária, que dura enquanto o usuário está navegando pelo site e morre depois que ele conclui a compra. Não há necessidade de gravar em disco uma informação que vai durar tão pouco tempo. Para isso, pode-se usar a memória RAM, que é barata e rápida. Um banco como o Redis pode muito bem fazer o papel de carrinho de compras.

O pagamento é algo mais delicado, e empresas antifraude homologam bancos relacionais. Também é interessante que seja transacional, então, nessa etapa, um banco SQL (como PostgreSQL) cairia como uma luva.

Por último, controle de usuários. Também é uma informação com jeito de documento, haverá chaves e valores, senha e demais informações pessoais do usuário, como seu histórico de compra (que pode ser um documento embarcado). Mais uma vez, o MongoDB pode fazer muito bem esse papel.

2. Criando um barramento: Nessa suposta aplicação de e-commerce, temos quatro diferentes tecnologias em uso: MongoDB, Redis, Neo4J e PostgreSQL. Como manter a consistência dos dados? A melhor resposta para isso é construir um barramento, uma camada de aplicação que apenas converse com os diferentes bancos. Essa camada libera algumas APIs (REST ou de alguma outra forma que achar melhor) para que seja o elo com a camada frontend. A grande vantagem de trabalhar com um barramento é que toda inteligência fica em um único lugar, e o frontend apenas consome essas APIs. Isso facilita muito o desenvolvimento de soluções mobile e a inclusão de novas funcionalidades, pois será necessário apenas adicionar novos métodos ao barramento e depois programar no frontend, evitando paradas e migrações de sistema.
3. Escalabilidade: Conhecendo bem as características do projeto, é possível escalonar no lugar certo. Nem todo mundo que navega em um e-commerce finaliza a compra, então escalonar o catálogo de produtos é muito mais fácil – será necessário apenas aumentar estrutura de MongoDB quando houver um número elevado de acessos. Não é preciso mexer em todo o sistema para escalar, basta plugar novas instâncias MongoDB, que continuará transparente para o barramento. Facilita muito o trabalho!

Conclusão

Persistência poliglota pode ser um grande aliado, se for trabalhada de forma adequada. Pode parecer que envolve custos e exige competências distintas, mas se o objetivo é manter um serviço no ar em situações que envolvem muitos acessos, é uma alternativa a ser pensada. Grandes players utilizam mais de um banco em suas aplicações, e a experiência mostra que isso é bastante viável.

 

Tipos de bancos não relacionais

Tipo	Descrição	Tecnologias
Orientação a documento	Cada “registro” no banco é chamado de documento, pode ser feito de vários formatos, sendo o mais comum salvar uma espécie de JSON nas “tabelas”, que são chamadas de coleções.	O mais popular é o MongoDB, mas existem outros como CouchDB e Redis.
Orientação a grafos	Trabalha com estrutura de grafos e consultas semânticas com vértices e arestas.	O mais popular é o Neo4J, mas existem outros que também suportam grafos, como ArangoDB e OrientDB.
Orientação a colunas	Possui uma ou múltiplas chaves e valores intercalados, simulando uma coluna.	Hbase e Cassandra são os mais populares.
Multi-model	São bancos que atendem a dois ou mais paradigmas, como documentos e grafos.	ArangoDB e OrientDB são os mais populares, ambos suportam tanto orientação a documento como grafos.

 

***

Texto publicado originalmente na Revista iMasters.