Bancos de Dados NoSQL

Daniel Carneiro, DBA na Bluesoft, fez um estudo no Bluesoft Labs sobre Bancos de Dados NoSQL, leia seu artigo, veja sua apresentação e assista à sua palestra.

Há algum tempo tenho observado uma certa movimentação na web referente à NoSql Databases ou bancos de dados não-SQL. Mas o que é isso?

NoSQL Database foi um termo criado por Eric Evans (o mesmo cara do Domain Driven Design) para descrever bases de dados que não usam SQL em suas consultas. Muitas dessas bases apresentam características muito interessantes como alta performance, escalabilidade, replicação, suporte à dados estruturados e sub colunas.

Atualmente, com a web 2.0 há uma demanda cada vez maior por armazenamento de dados e alta disponibilidade, sendo que em alguns casos máquinas simples, como por exemplo de plataforma Intel, não são suficientes para dar conta do recado. Disso nasceu a necessidade de se desenvolver bases de dados que suportem esse tipo de demanda, e que ao mesmo tempo evitassem o SPOF (single point of failure), ou seja, que os acessos se concentrassem em uma única máquina, evitando a parada do sistema em caso de falha, além de promover o particionamento horizontal, distribuindo os dados em várias máquinas.

Para se conseguir esse nível de escalabilidade alguns paradigmas dos bancos de dados relacionais tiveram que ser quebrados; primeiramente, o que dá o nome aos RDBMS, os relacionamentos. Bancos NoSQL não possuem, por exemplo, junções de tabelas (joins), além de não suportarem demarcação de transações, e especificamente, em relação às transações, alguns modelos de bancos distribuídos conceberam um modelo chamado Eventualmente Consistente onde operações realizadas em um dos nós de um cluster de banco de dados podem não estar disponíveis imeatamente nos outros nós.
Podemos classificar estes bancos de dados em 4 tipos básicos:

  • Key/Value Store
  • O mais simples dos bancos de dados no-sql. Podem ser considerados como um HashTable gigante (ou mapa ou dicionário, dependendo da linguagem) que possui somente uma chave de acesso e um valor associado, permitindo buscas somente pela chave. Esse modelo é o que permite a maior escalabilidade entre todos. Alguns projetos desse tipo são:

  • Document Store
  • Provêem o armazenamento de documentos complexos, como árvores em XML ou JSON, os quais podem ser buscados pela sua chave ou por qualquer um dos valores contidos dentro de seu documento, como por exemplo buscas utilizando XPath ou métodos “query by example”. Exemplos desses mecanismos de persistência são:

  • Graph Store
  • Direferente dos bancos de dados anteriores, os dados não estão dispostos em listas e sim, em objetos que são relacionados uns com os outros, onde a busca pela informação se dá pela navegação entre estes dados. Alguns projetos que utilizam este modelo são:

  • Column Oriented Store
  • Esse na verdade, é um tipo diferente banco de dados relacional, com características próximas a dos modelos citados acima, como escalabilidade e grande capacidade de armazenamento de dados, onde o armazenamento é feito por colunas e não por linhas, como normalmente acontece nos SGDBs, melhorando assim principalmente a performance em aplicações de Datawarehouse. Entram nesta categoria os bancos:

Técnicas de Bancos NoSQL

Além dos sistemas de persistencia citados acima, há algumas técnicas que podem ajudar a melhorar a escalabilidade de bancos de dados, as quais normalmente são requisitos para a utilização de alguns sistemas citados acima: Sharing e MapReduce.

Sharding

Sharding é um termo relacionado à Shared Nothing, que consiste em dividir os dados dados horizontalmente, ou seja, quebrar as tabelas, diminuindo o seu número de linhas e separando-as em ambientes diferentes (em outros servidores, por exemplo). Neste ponto todos os dados de uma partição não devem conter referências aos dados de outras partições, sendo que os dados em comum, deverão ser replicados entre as bases.

MapReduce

MapReduce é um algoritmo patenteado pelo Google para o processamento de dados de forma distribuída. Ele ocorre em duas fases:

  1. Map: O nó principal recebe os dados, divide e partes menores e as envia aos outros nós para serem processados. Ao final do processamento estes nós devolvem o resultado ao nó principal.
  2. Reduce: O nó principal combina as respostas obtidas pelos outros nós gerando o resultado final do processamento.

Conclusão

Após um rápido estudo que realizei sobre os sistemas e as técnicas que envolvem a persistência NoSql, pude tirar algumas conclusões:

  • Podemos tirar proveito desse novo paradigma de persisência, porém devemos tomar muito cuidado com a sua adoção, pois ela requer que pensemos em novas formas de modelagem de dados;
  • Devemos escolher criteriosamente qual sistema a ser utilizado, pois não há um consenso ou padronização entre eles, tornando muito difícil uma eventual troca de sistema de persistência;
  • Esses sistemas em quase sua totalidade ainda estão em sua fase inicial de desenvolvimento, podendo ainda evoluir muito em relação aos benefícios e ferramentas de gerenciamento.

COMENTÁRIOS (6)

É isso aí Daniel,

Ficou bem legal o artigo. Parabéns!

Responder

Muito bom artigo. Simples e claro. Parabéns!

Responder

Visão madura, imparcial, técnica e profissional. Parabéns. Estava em busca de um artigo menos “rebelde” e mais técnico. rs

Deixe uma resposta