NoSQL

De GEATI - Grupo de Estudos Avançados em TI
Ir para: navegação, pesquisa

Durante décadas, foram utilizadas bases de dados relacionais para armazenar dados estruturados, organizados em grupos denominados de tabelas. Nessas tabelas, os dados são agrupados por linhas e colunas. Porém, com o avanço da Internet, tem-se lidado com quantidades de dados nunca antes trabalhadas (Big Data), além destes estarem cada vez menos estruturados. São exemplos, os dados contidos em sites como Facebook, Google e Amazon. Desta forma, estes sites tiveram que desenvolver meios eficientes e baratos para processar seus dados. Uma solução encontrada foi a escalabilidade horizontal, que significa aumentar o número de máquinas, ao invés de aumentar o poder de processamento e armazenamento de uma só máquina (escalabilidade vertical). Os bancos de dados NoSQL chegaram como outra solução para este problema, já que permitem o gerenciamento em larga escala de dados distribuídos. Entre suas características, destacam-se: não-relacional, distribuído, de código aberto, escalável horizontalmente, ausência de esquema ou esquema flexível, suporte à replicação nativo e acesso via APIs simples(NoSQL) [1]


Conceito

O termo NoSQL só surgiu em 2009, baseado em artigos já escritos antes sobre essa tecnologia, porém o nome nunca havia sido utilizado. Houve uma grande confusão em torno do nome, já que sua filosofia vinha de fugir da ideia relacional, inicialmente o termo era compreendido como Não Relacional, porém esse termo não ajuda a definir o que estes bancos de dados são de fato. Além da falta de precisão no nome, outro motivo que gerou grande confusão foi de que a linguagem SQL não é sinônimo de relacional, tampouco representa as limitações deste, desde então 'NoSQL' passou a ser entendido como uma, abreviação de 'Not Only SQL'.

Ausência de esquema ou esquema flexível

O esquema flexível define a estrutura dos dados modelados ou a ausência deste, facilita a escalabilidade, além de aumentar a disponibilidade. Porém, não há garantia da integridade dos dados (LÓSCIO, RODRIGUES e PONTES, 2011) [2].

Suporte nativo à replicação

O suporte nativo à replicação diminui o tempo gasto para recuperar informações, além da replicação ser um dos meios de prover escalabilidade. Existem duas abordagens principais para replicação: Master-Slave (Mestre-Escravo) e Multi-Master

Velocidade e Escalabilidade horizontal

A escalabilidade horizontal tende a ser a opção mais viável para o problema da escalabilidade. Porém, requer que diversos processos de uma única tarefa sejam criados e distribuídos. Isto torna inviável a utilização de um banco de dados relacional, uma vez que todos estes processos conectados geram grande concorrência, aumentando consequentemente o tempo de acesso às tabelas desejadas. A escalabilidade horizontal somente é permitida nos BDs NoSQL por causa da ausência de bloqueios. Uma alternativa muito usada para alcançar esta escalabilidade é o Sharding, que consiste em dividir os dados em várias tabelas, que são armazenadas ao longo de múltiplos nós de uma rede. A aplicação desta técnica traz o grande problema de “quebrar” a lógica de relacionamentos, que é o grande forte dos bancos relacionais. Neste caso, as aplicações têm que resolver a complexidade gerada pela partição de informações, como, por exemplo, a execução de joins e outros comandos (LÓSCIO, RODRIGUES e PONTES, 2011) [2]

Consistência eventual

O teorema CAP (Consistency, Availability e Partition tolerence) diz que, em determinado momento, apenas são garantidas duas das três propriedades: Consistência, Disponibilidade ou Tolerância à partição. No contexto da Web, por exemplo, geralmente são privilegiadas a disponibilidade e a tolerância à partição (LÓSCIO, RODRIGUES e PONTES, 2011) [2]. Portanto, a consistência dos dados nem sempre é mantida entre os diversos pontos de uma distribuição.

Propriedades ACID

Um ponto chave dos bancos de dados ao analisar-se a performance e consistência dos dados, é como estes lidam com transações. Durante bastante tempo, os BDRs garantiam estas quatro propriedades ACID(Atomicidade, Consistência, Isolamento e Durabilidade), que supriam as necessidades da época, porém como ja apresentado, no contexto da web 2.0 e a grande quantidade de dados gerados, houve a necessidade na mudança deste paradigma de transações, a partir do que aparecem as propriedades BASE.

Atomicidade

Consistência ACID

Isolamento

Durabilidade

Teorema CAP

Eric Brewer no ano 2000 formulou o seguinte teorema, ditando o funcionamento de sistemas distribuídos, pelo qual diz que existe um compromisso fundamental entre consistência, disponibilidade e tolerância a partição(CAP – Consistency, Availability and Partition tolerance) .

Consistência CAP

Disponibilidade (Availability)

Tolerância a Partição(Partition tolerance)

Exemplo explicativo do Teorema CAP

Propriedades BASE

O termo BASE foi criado pelos seguidores de Eric Brewer, na sequência da apresentação do teorema CAP (Tiwari, 2011) [3]. A palavra BASE, vem para salientar que estas propriedades são filosoficamente opostas às propriedades ACID, sendo a maior diferença entre estas duas o espectro de consistencia que os sistemas podem oferecer.

As propriedades BASE estão intrinsecamente associadas aos sistemas NoSQL, porque o principal objetivo destas propriedades é garantir que novos dados chegam a cada momento e que os mesmos necessitam de armazenamento imediato, mesmo que isso implique o risco de o sistema ficar dessincronizado por um breve período de tempo (McCreary e Kelly, 2014) [4]. Estes sistemas para poder executar todas as queries "relaxam" as regras a fim de que todas as queries sejam executadas, mesmo que nem todos os dados do banco de dados estejam sincronizados.

Basically Available

Soft state

Eventual consistency

Paradigmas de Bancos de dados NoSQL

Diferentes modelagens de dados foram criadas para suprir diferentes necessidades, sendo as principais:

Orientado a documentos (BDOD)

Armazém Chave-Valor (key-value)

Orientado a colunas

Orientado a grafos

Modelos de dados NoSQL

Um modelo é o modo pelo qual percebemos e manipulamos nossos dados(NoSQL Essencial)[5]. Em outro nível, o do usuário, o modelo seria como este interage com os dados. Modelo de dados, informalmentne é designado para o modelo de dados de um certo aplicativo, porem aqui, modelo sera tratado como a forma que o SGBD relaciona e organiza seus dados, mais formalmente chamado de metamodelo. Nesta seção serão descritos alguns desses modelos.

O modelo de dados que dominou desde que os BDs começaram a ser usados, é o modelo de dados relacional, onde este funciona basicamente como um conjunto de tabelas relacionadas por colunas em comum, cada tabela possui linhas e colunas, sendo cada linha uma entidade de interesses e as colunas, os atributos desta entidade. Sendo a menor unidade de informação armazenada a tupla(registro).

Imaginemos como funcionaria o modelo relacional de dados de uma Nota fiscal, onde teríamos um cliente que gerou a nota fiscal com a compra de vários itens de diferente valor, quantidade sendo cada um destes um produto do estabelecimento.

NotaRELACIONAL.png

Orientado a agregados

Exemplos de implementação de uma aplicação usando NoSQL

Acesso ao código fonte: aqui

"Este exemplo prático possibilita melhor entendimento de como funcionam os BDs NoSQL, já que apenas com os conteúdos teóricos a percepção fica abstrata". Logo, nesta seção são descritos como foram implementadas duas aplicações de loja de compras com carrinho iguais, diferindo apenas nos BDs utilizados, para uma MySQL e para outra MongoDB, com a finalidade de atingir resultados comparáveis e experimentais sobre a utilização de um BD orientado a Documentos.

A estrutura do lado do cliente para as duas aplicações é exatamente a mesma, já que apenas depende de como a resposta do servidor será estruturada, o que difere entre as duas é o lado do servidor. Para conseguir isto, foi utilizada a tecnologia AJAX, Asynchronous JavaScript and XML. Basicamente,o lado cliente fica totalmente separado do lado servidor e desde que esta responda uma requisição do cliente no formato esperado, indifere como tenha tratado os dados antes. O uso desta tecnologia foi um ponto chave para atingir um grau de comparabilidade maior, pois as diferenças entre os dois BDs seriam testadas na mesma aplicação.

A aplicação consiste em um sistema de login e cadastro, onde o usuário necessita estar logado para acessar a loja. Ao acessar a loja,o id do cliente fica salvo na sessão. Os itens disponíveis para venda aparecerão e ele poderá adicionar algum item ao carrinho, que ficaria salvo na sessão, visualizar e remover os itens do carrinho, e finalizar a compra, onde os dados do carrinho ordenados em sequencia, informações do cliente, data e id da nota serão salvos no BD e mostrados ao usuario.

Login.pngAlterar-senha.png
Loja-comprar.png Exibir-carrinho.png Exibir-nf.png

Respectivamente estão sendo mostradas capturas da tela de login, alterar senha, menu inicial da loja, vizualização do carrinho e vizualização da nota fiscal após o fim da compra. A aplicação não se resume somente a estas telas.

Client Side

Server Side Modelo Relacional

Server Side MongoDB

Referências

  1. NOSQL (2010). NOSQL Databases. http://nosql-database.org/.
  2. 2,0 2,1 2,2 LÓSCIO, B. F.; OLIVEIRA, H. R. de; PONTES, J. C. de S. NoSQL no desenvolvimento de aplicações web colaborativas. In: Simpósio Brasileiro de Sistemas Colaborativos – SBSC, 8., 2011, Paraty (RJ). Anais... Paraty: SBC, 2011.
  3. TIWARI, S. 2011. Professional NoSQL: 1ª Edição. Indianapolis, Indiana, Estados Unidos da América, John Wiley & Sons. ISBN: 978-0-470-94224-6
  4. MCCREARY, D. & KELLY, A. 2014. Making Sense of NoSQL: A Guide for Managers and the Rest of Us: 1ª Edição. Shelter Island, Nova York, Estados Unidos da América, Manning Publications. ISBN:9781617291074
  5. SALADAGE, P. J; FOWLER, M. NOSQL Essencial: Um guia conciso para o mundo emergente de persistência poliglota. Pearson Education. 2013. 220 p;