Neste artigo, veremos o conceito NoSQL, e suas opções de banco de dados existentes no mercado atualmente.

O termo NoSQL foi primeiramente utilizado em 1998 (há 10 anos) como o nome de um banco de dados não relacional de código aberto.

Seu autor, Carlo Strozzi, alega que o movimento NoSQL “é completamente distinto do modelo relacional e portanto deveria ser mais apropriadamente chamado “NoREL” ou algo que produzisse o mesmo efeito”.

Com a crescente popularização da internet, diversos novos dados foram surgindo e tratá-los foi se tornando gradualmente mais complexo e sua manutenção cada vez mais cara.

Em 2006, o artigo: BigTable: A Distributed Storage System for Structured Data, publicado pelo Google em 2006, traz novamente à tona o conceito NoSQL.

No inicio de 2009, o termo NoSQL é reintroduzido por um funcionário do Rackspace, Eric Evans, quando Johan Oskarson da Last.fm queria organizar um evento para discutir bancos de dados open source distribuídos.

O nome era uma tentativa de descrever o surgimento de um número crescente de bancos de dados não relacionais e fazia uma referência ao esquema de atribuição de nomes dos bancos de dados relacionais mais populares do mercado como MySQL, MS SQL, PostgreSQL, etc.

A partir de então, os bancos de dados não relacionais passaram a ser conhecidos como NoSQL, e com crescente popularização das redes sociais, a geração de conteúdo por dispositivos móveis bem como o número cada vez maior de pessoas e dispositivos conectados, faz com que o trabalho de armazenamento de dados com o objetivo de utilizá-los em ferramentas analíticas, comece a esbarrar nas questões de escalabilidade e custos de manutenção desses dados.

Bancos de dados relacionais escalam, mas quanto maior o tamanho, mais custoso (R$) se torna essa escalabilidade, seja pelo custo de novas máquinas, seja pelo aumento de especialistas nos bancos de dados utilizados.

Já os não relacionais, permitem uma escalabilidade mais barata e menos trabalhosa, pois não exigem máquinas extremamente poderosas e sua facilidade de manutenção permite que um número menor de profissionais seja necessário.

Assim, os bancos de dados NoSQL, vão ficando mais populares entre as grandes empresas pois reúnem as características de poder trabalhar com dados semi-estruturados ou crus vindos de diversas origens como arquivos de log´s, websites, arquivos multimídia, etc.

Você já pensou na dificuldade de criar uma tabela de cadastro de produtos em um banco relacional de um e-commerce? E que trabalha com vários produtos diferentes como a Americanas, Amazom e etc.

Teria que criar uma tabela gigante com várias colunas e algumas terá que armazenar dados nulos. Pois os atributos de um livro são bem diferentes de uma geladeira ou de uma bicicleta.

Para suprir essa necessidade foi surgindo uma grande quantidade de bancos de dados não relacionais que trabalham de diferentes maneiras, e entre as principais estão:

Banco de dados chave/valor (Key/Value): sistemas distribuídos nessa categoria, também conhecidos como tabelas de hash distribuídas, armazenam objetos indexados por chaves, e possibilitam a busca por esses objetos a partir de suas chaves.

Alguns bancos que utilizam esse padrão são: DynamoDb, Couchbase, Riak, Azure Table Storage, Redis, Tokyo Cabinet, Berkeley DB, etc.

Bancos de dados orientados a documentos: os documentos dos bancos dessa categoria são coleções de atributos e valores, onde um atributo pode ser multi-valorado.

Em geral, os bancos de dados orientados a documento não possuem esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum.

Essa característica faz deles boas opções para o armazenamento de dados semi estruturados.

Alguns bancos que utilizam esse padrão são: MongoDb, CouchDB, RavenDb, etc.

Bancos de dados de famílias de colunas: Bancos relacionais normalmente guardam os registros das tabelas contiguamente no disco.

Por exemplo, caso se queira guardar id, nome e endereço de usuários em um sistema de cadastro, os registros seriam:

Id1,Nome1,Endereço1;
Id2, Nome2, Endereço2.

Essa estrutura torna a escrita muito rápida, pois todos os dados de um registro são colocados no disco com uma única escrita no banco.

Essa estrutura também é eficiente caso se queira ler registros inteiros.

Mas para situações onde se quer ler algumas poucas colunas de muitos registros, essa estrutura é pouco eficiente, pois muitos blocos do disco terão de ser lidos.

Para esses casos onde se quer aperfeiçoar a leitura de dados estruturados, bancos de dados de famílias de colunas são mais interessantes, pois eles guardam os dados contiguamente por coluna.

O exemplo anterior em um banco de dados dessa categoria ficaria:

Id1, Id2;

Nome1, Nome2;

Endereço1, Endereço2.

Por esse exemplo é possível perceber a desvantagem de um banco de dados de famílias de colunas: a escrita de um novo registro é bem mais custosa do que em um banco de dados tradicional.

Assim, num primeiro momento, os bancos tradicionais são mais adequados processamento de transações online (OLTP) enquanto os bancos de dados de famílias de colunas são mais interessantes para processamento analítico online (OLAP).

O Bigtable é uma implementação da Google dessa categoria de bancos de dados.

Outros bancos de dados que são orientados a coluna: Hadoop, Cassanda, Hypertable, Amazon SimpleDB, etc.

Bancos de dados de grafos: diferentemente de outros tipos de bancos de dados NoSQL, esse está diretamente relacionado a um modelo de dados estabelecido, o modelo de grafos. A idéia desse modelo é representar os dados e / ou o esquema dos dados como grafos dirigidos, ou como estruturas que generalizem a noção de grafos.

O modelo de grafos é mais interessante que outros quando “informações sobre a inter-conectividade ou a topologia dos dados são mais importantes, ou tão importantes quantos os dados propriamente ditos.

O modelo orientado a grafos possui três componentes básicos: os nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos.

Neste caso, o banco de dados pode ser visto como um multigrafo rotulado e direcionado, onde cada par de nós pode ser conectado por mais de uma aresta.

Um exemplo pode ser: “Quais cidades foram visitadas anteriormente (seja residindo ou viajando) por pessoas que viajaram para o Rio de Janeiro?”

No modelo relacional esta consulta poderia ser muito complexa devido à necessidade de múltiplas junções, o que poderia acarretar uma diminuição no desempenho da aplicação.

Porém, por meio dos relacionamentos inerentes aos grafos, estas consultas tornam-se mais simples e diretas.

Alguns bancos que utilizam esse padrão são: Neo4J, Infinite Graph, InforGrid, HyperGraphDB, etc.

Como podem ver os bancos de dados que se utilizam do conceito NoSQL, abrangem uma ampla gama de possibilidades de armazenamento da informação.

Lembrando que existe sempre algumas características para se adotar um banco de dados não relacional a sua aplicação então seja menas, não saia por ai querendo usar banco de dados NoSQL em todo tipo de aplicação pois os bancos relacionais funcionam á várias décadas de forma perfeita para vários tipos de aplicações.

Espero que eu tenha ajudado a você que leu até aqui a entender um pouco sobre os bancos de dados NoSQL.

Referências:

Introdução aos bancos de dados NoSQL, Brasil, 2015, Disponível em: http://www.devmedia.com.br/introducao-aos-bancos-de-dados-nosql/26044

BOAGLIO, Fernando – Mongodb: Construa Novas Aplicações Com Novas Tecnologias, 1ed. – São Paulo, Editora Casa do Código, 2015.