Embora presentes na esmagadora maioria das aplicações de software corporativas, há situações em que os bancos relacionais podem não representar a solução mais adequada para o armazenamento de dados. A modelagem relacional pode se revelar como limitada em cenários nos quais um mesmo tipo de informação apresenta um formato variável, fato este que resultaria na criação de inúmeras tabelas para atender a requisitos aparentemente simples em termos funcionais.
Além disso, há ainda questões sobre como garantir uma alta disponibilidade e aumentar o poder de processamento para atender a níveis de uso crescente (escalabilidade). Muitas vezes, os investimentos em infraestrutura requeridos para isto serão pesados, podendo mesmo se revelar como inviáveis do ponto de vista financeiro.
Uma opção interessante para atender a estas diferentes necessidades seriam os bancos de dados NoSQL. Este último termo é interpretado por muitos como uma sigla de “Not only SQL”, englobando alternativas com capacidades que vão além das características típicas dos sistemas gerenciadores relacionais.
O objetivo deste artigo é descrever, em termos gerais, os principais tipos de bancos de dados NoSQL. Isto acontecerá nas próximas seções, em que também serão mencionadas implementações para cada uma das classificações apresentadas.
Bancos de dados orientados a documento
Documentos representam a unidade básica neste tipo de tecnologia, sendo possível comparar os mesmos aos registros das tabelas convencionais.
Embora exista um paralelo com as linhas do modelo relacional, um documento possui uma estrutura flexível e que não está presa à existência de colunas pré-definidas. Do ponto de vista prático, isto significa que inúmeros documentos vinculados a uma mesma coleção podem contar com formatos variáveis.
Muitas das soluções orientadas a documento fazem uso do padrão JSON (JavaScript Object Notation) para o armazenamento de dados. A figura a seguir traz um exemplo de como seria um documento neste formato:
Dentre os diversos bancos orientados a documento, é possível citar como exemplos o MongoDB, o DynamoDB (alternativa oferecida na nuvem pela Amazon) e o DocumentDB (este último um serviço que integra o Microsoft Azure).
Bancos de dados do tipo chave-valor
Como o próprio nome sugere, os bancos que se encaixam nesta classificação são formados por conjuntos de chaves e seus respectivos valores. Cada um destes conjuntos, por sua vez, conta ainda com uma chave que funciona como um identificador único:
Assim como acontece no modelo orientado a documentos, a estrutura de um banco do tipo chave-valor é bastante flexível. Chaves podem, ou não, se repetir ao longo de vários agrupamentos de dados.
Constituem exemplos deste tipo de banco o Redis (solução open source bastante utilizada para cache de dados) e o DynamoDB.
Bancos de dados orientados a colunas
Este tipo difere bastante do modelo relacional, em que uma linha representa um conjunto de dados relacionados (com cada um destes últimos correspondendo a colunas):
- Em termos práticos, a organização dos dados ocorre com base em colunas;
- Dados de colunas distintas representando um mesmo agrupamento ocupam as mesmas posições no banco.
Na próxima imagem é possível observar uma representação esquemática deste tipo de solução NoSQL, em que “col” representa as colunas e “r” os agrupamentos/linhas associados):
São exemplos de bancos orientados a coluna o HBase e o Cassandra, com ambos constituindo iniciativas mantidas atualmente pela Apache Foundation.
Bancos de dados orientados a grafos
Bancos deste tipo empregam conceitos da teoria de grafos para a representação de relacionamentos entre diferentes conjuntos de dados. Uma das soluções mais conhecidas baseadas neste modelo é o Neo4j.
Na imagem a seguir está um exemplo de grafo que poderia ser armazenado num banco de dados deste tipo:
Conclusão
A intenção com este artigo foi apresentar uma visão geral do modelo NoSQL, enfatizando as características de cada tipo de banco de dados que implementa este paradigma.
Muito embora as soluções NoSQL estejam em alta, o padrão relacional ainda seguirá com seu papel preponderante dentro da área de software. Caberá, então, aos desenvolvedores avaliar as exigências de cada cenário, definindo qual alternativa melhor se adequa às demandas de um projeto (ou mesmo adotando uma abordagem híbrida, que combine as duas vertentes).
Espero que este conteúdo possa ter sido útil.
Até uma próxima oportunidade!
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?