Introdução aos bancos de dados NoSQL

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (22)  (0)

Veja neste artigo o que é o conceito NoSQL, porque ele é geralmente associado ao Big data e quais são as várias opções de banco de dados NoSQL existentes atualmente.

Neste artigo, veremos o que é o conceito NoSQL, porque ele é geralmente associado ao Big data e quais são algumas das várias opções de banco de dados NoSQL existentes atualmente.

Bancos de dados NoSQL
Figura 1: Bancos de dados NoSQL

O que é NoSQL?

Vamos começar sobre o NoSQL, o que vem a ser esse conceito ?

Pesquisando pela net, encontramos muitas definições, algumas bem confusas que passam a ideia de um conceito que tenta acabar com o padrão SQL, bem como encontramos também definições mais realistas, que passam a ideia de um padrão de armazenamento de dados alternativo ao SQL, oferecendo uma robustez e escalabilidade melhores.

Para sabermos mais claramente o que é o NoSQL, e qual seu uso, é interessante saber algumas coisas antes.

O termo NoSQL foi primeiramente utilizado em 1998 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 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 (arquivos de log, web-sites, arquivos multimídia, etc...).

Podemos listar algumas dessas características abaixo:

Utilização do processamento paralelo para processamento das informações: para se atingir uma performance razoável no processamento de grandes volumes de dados, é mais eficiente dividir a tarefa em várias outras menores e que podem assim, serem executadas ao mesmo tempo, distribuindo essas tarefas pelos vários processadores disponíveis, para isso, os sistemas precisam atingir um alto grau de maturidade no processamento paralelo.

O uso de muitos processadores baratos, não só oferece melhor performance, mas se torna também uma solução economicamente interessante, pois dessa forma é possível escalar o sistema horizontalmente apenas adicionando hardware e não limita a empresa a poucos fornecedores de hardware mais poderoso.

Distribuição em escala global: para atender seus usuários de forma eficiente, algumas empresas utilizam vários data centers, localizados em diversas partes do pais ou do mundo.

Com isso, uma série de questões sobre disponibilidade e performance são levantadas ao construir os sistemas.

A distribuição deles combinada com o hardware barato, impõe ao sistema a necessidade de ser robusto o suficiente para tolerar falhas constantes e imprevisíveis, seja de hardware, seja da infraestrutura do lugar onde o data center se encontra.

Pensando nessas questões, bem como nas necessidades internas ou dos clientes, foi surgindo uma grande quantidade de bancos de dados não relacionais de trabalham de diferentes maneiras, e as principais estão listadas abaixo.

Banco de dados que trabalham no esquema 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 otimizar 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 aprocessamento 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 ideia 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 importante 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 a 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. Veremos no próximo artigo porque ele tem sido considerado fundamental para o BigData, e como podemos tirar partido de seu potencial.

Até o próximo artigo!

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ficou com alguma dúvida?