Banco de Dados não relacionais II

Prévia do material em texto

Banco de Dados 
Não-Convencionais
Material Teórico
Responsável pelo Conteúdo:
Prof.ª Me. Jessica Barbara da Silva Ribas
Revisão Textual:
Prof. Esp. Luciano Vieira Francisco
NoSQL
• NoSQL;
• Relacional Versus NoSQL;
• Tipos de Armazenamento NoSQL;
• Considerações Finais.
 · Diferenciar entre NoSQL e banco de dados relacional.
 · Identificar quando utilizar NoSQL pode ser uma opção vantajosa.
OBJETIVO DE APRENDIZADO
NoSQL
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE NoSQL
NoSQL
O termo NoSQL surgiu no final da década de 1990 como o nome de um banco 
de dados relacional de código fonte aberto que não utilizava a linguagem SQL 
como padrão e realmente significava não SQL – No SQL.
Foi em 2009 que o termo NoSQL foi associado aos Sistemas de Gerenciamento 
de Banco de Dados (SGBD) não relacionais e passou a ter a conotação de Not 
Only SQL – não somente SQL – pela sua comunidade de utilização.
NoSQL “[...] refere-se a um conjunto mal definido de banco de dados, na sua 
maioria em código aberto, desenvolvido no século XXI e não utilizando SQL” 
(SADAGE; FOWLER, 2013, p. 37); ou seja, pode ser entendido como um movi-
mento que agrega uma classe de SGBD, em que cada elemento possui a sua singu-
laridade, mas com algumas características básicas iguais, a saber:
• Cada SGBD tem a sua própria linguagem de manipulação dos dados, sendo 
que alguns dos quais construíram a sua linguagem parecida com SQL, mudando 
apenas as partes necessárias – como o CQL utilizado no Cassandra;
• A maioria dos NoSQL atende às necessidades de execução em cluster, ou seja, 
trabalhar em um modelo onde os dados estão distribuídos em nós e podem ser 
manipulados corretamente, permitindo, assim, a escalabilidade horizontal; em 
outras palavras, é a inclusão de nós ou máquinas na rede com a finalidade de 
aumentar o poder computacional;
• Não possuem estruturas fixas ou um esquema rígido, permitindo flexibilidade 
na alteração de campos dos registros. Apresentam vantagens ao lidar com 
dados não uniformes e campos personalizados;
• Permitir a persistência poliglota – refere-se a utilizar armazenamento de dados 
distintos em diferentes situações.
O uso desse padrão de Banco de Dados (BD) vêm crescendo nos últimos anos 
devido à necessidade de se trabalhar com tipos de dados distintos em grande volu-
me, principalmente com o curto tempo de resposta. Seu foco é ter alta disponibili-
dade dos dados e rápido desempenho no processamento dos mesmos.
Relacional Versus NoSQL
Antes de compararmos as duas tecnologias, faz-se necessário relembrar os 
conceitos importantes de bancos de dados tradicionais. São compostos por tabelas 
e os relacionamentos entre as quais. As tabelas são formadas por campos – colunas 
– e registros – linhas. Como requisito básico, toda tabela deve conter uma chave 
primária, ou seja, um campo em que os valores não podem se repetir, chamado 
também de atributo único, geralmente nomeado como código ou identificador.
8
9
O relacionamento entre as tabelas é feito por meio da chave estrangeira, que 
nada mais é que a chave primária da tabela A, que é um campo na tabela B com 
o objetivo de fazer referência a determinado registro de A. Para haver consistência 
nos dados, faz-se uma verificação se o valor a ser incluso em B realmente existe na 
tabela A.
Os relacionamentos podem ser: um para um – um cliente tem um endereço de 
cobrança –; um para muitos – um cliente tem vários endereços de entrega –; e de 
muitos para muitos – n produtos podem ter n cores –, conforme o exemplo da 
Figura 1. O relacionamento de n para n geralmente é realizado por meio de uma 
tabela auxiliar, esta que contém nada mais que duas ou mais chaves estrangeiras 
– por exemplo, as tabelas produto e cores têm uma tabela auxiliar denominada 
produto_Cor.
Figura 1 – Exemplo do cadastro de clientes usando um banco de dados relacional
Fonte: Acervo do Conteudista
Os bancos de dados tradicionais devem suportar o acesso de muitos usuários e 
múltiplas requisições ao mesmo tempo, por isso utilizam o conceito de transações, 
com o intuito de organizar de forma lógica as operações de acesso aos dados – 
inclusão, alteração, exclusão. Para garantir a integridade das transações são em-
pregadas quatro propriedades, Atomicidade, Consistência, Isolamento e Durabili-
dade (Acid), vejamos:
• Atomicidade indica que uma transação é um atributo único e todos os coman-
dos ali contidos devem ser realizados com sucesso; mas caso ocorra erro em 
alguma das linhas de comando, todos os comandos já executados são desfeitos 
e a transação é abortada;
• Consistência garante que o banco de dados deverá ter consistência após pas-
sar por cada transação, por exemplo, a inclusão de um novo registro na ta-
bela cliente requer o preenchimento da chave estrangeira estado – caso seja 
preenchida incorretamente, a inclusão do novo cadastro não será efetivada, 
indicando um erro;
9
UNIDADE NoSQL
• Isolamento entre as transações, em outras palavras, uma transação não deve 
interferir na outra, nem visualizar o seu resultado parcial;
• Durabilidade é a garantia de que os resultados das transações realizadas não 
serão perdidos, garantindo-se, assim, que o novo estado do BD seja o mesmo 
para a transação seguinte.
Devido a essas propriedades, não é possível dois ou mais usuários editarem si-
multaneamente o mesmo registro. Seu foco é armazenar os dados de uma maneira 
que não se danifiquem. Contudo, o uso das transações se torna custoso à medida 
que a base de dados aumenta, afinal, algumas vezes realizar todas as verificações 
padrões em uma imensa quantidade de dados requer um certo tempo.
Assim, torna-se necessário o investimento na aquisição de novos hardwares – 
escalabilidade vertical –, com o objetivo de melhorar o processamento do SGBD. 
Mas, dependendo da complexidade do BD, quantidade de usuários, transações 
solicitadas, ou do SGBD utilizado, a atualização de hardware terá um efeito de 
curto prazo, sendo rapidamente necessária a realização de outra.
Para os SGBD NoSQL atingirem o objetivo de desempenho e a disponibilidade 
dos dados, não pode ser utilizado o conceito de transações Acid. Neste caso, as 
propriedades nomeadas de Basically Available, Soft state,Eventual consistency 
(Base) são cruciais, principalmente quando o banco de dados se encontra distribuído. 
Basic Available refere-se aos dados da base de dados estar disponível na maior 
parte do tempo; Soft state indica que os dados armazenados não necessitam 
ter consistência imediata entre o nó principal e suas réplicas; assim, a Eventual 
consistency prevê que haverá consistência em algum momento entre esses nós, 
mesmo com certo atraso.
Para garantir que propriedades Base ocorram sem maiores problemas, faz-se 
necessário utilizar algumas técnicas, tais como map/reduce, consistent hashing, 
multiversion concurrency control, vector clocks.
Map/reduce é o uso das técnicas map e reduce em conjunto. Conforme exibido 
na Figura 2, a primeira tarefa realizada é map, a qual consiste no nó principal 
receber os dados e os organizar, dividindo-os em partes menores para serem 
processados pelos outros nós da rede, de modo que o resultado do processamento 
retorna ao nó principal, dando início ao reduce. Na segunda parte, o nó principal 
combina as respostas obtidas, gerando, assim, a resposta final; enquanto consistent 
hashing suporta os mecanismos de armazenamento e recuperação em banco de 
dados distribuído.
Multiversion concurrency control gerencia as transações em paralelo no banco 
de dados, permitindo que as operações de escrita e leituras sejam realizadas simul-
taneamente, diferentemente do gerenciamento de transações tradicionais. Já o 
vector clocks determina qual versão de um dado distribuído é a mais atual.
10
11
Conforme pode-se perceber no decor-
rer desta seção, a principal diferença entre 
os paradigmas relacionais e NoSQL está 
no seu objetivo: enquanto o primeiro foca 
no armazenamento em si dos dados, em 
como organizá-los de maneira consisten-
te e duradoura – neste caso, o tempo de 
resposta não é tão relevante –; o segundo 
deseja disponibilidade de acesso aos da-
dos em um curto espaço de tempo, não se 
importando em como esses dados estão 
organizados entre si, desde que estejam 
consistentes em algum momento.
Figura 2 – Esquema simplifi cado do map/reduce
Fonte: Acervo do Conteudista
Mesmo com todas as mudanças que vêm ocorrendo devido ao Big Data, SGBD 
relacionais não deixarão a sua condição de usuais, pois muitas aplicações necessitam 
da segurança e confiabilidade dos dados que esse modelo proporciona. É comum 
que uma empresa tenha as suas bases de dados relacionais executando em seus 
softwares de tarefas cotidianas como, por exemplo, faturar pedidos. Esses mesmos 
dados também são enviados às aplicações de análises complexas.
É igualmente possível o uso de SGBD NoSQL em softwares do cotidiano, mas 
deve-se tomar um cuidado extra na modelagem de sua base de dados, pois ainda 
não há padronização dessa fase. Ademais, torna-se ainda necessário considerar um 
modelo de armazenamento NoSQL que favoreça a resolução do problema.
Saiba mais sobre a relação entre bancos de dados relacionais e NoSQL, entendendo qual 
escolher conforme a circunstância: https://goo.gl/3EzioDEx
pl
or
Tipos de Armazenamento NoSQL
A característica de esquema flexível é relacionada em como os dados são agru-
pados entre si; neste caso, há quatro modelos de armazenamento que os SGBD 
costumam utilizar, vejamos:
1. Chave/valor – é o mais simples entre os NoSQL, afi nal, imagine que os 
dados estão armazenados dentro de um vetor e que, para acessá-los, você 
precisará indicar o “nome” ou chave do vetor.
Não há preocupação no que o valor representa na armazenagem, uma 
vez que a aplicação é responsável por fazer o tratamento e entendimento 
11
UNIDADE NoSQL
do conteúdo do valor; como exemplificado na Figura 3, a chave seria o 
“nickname”, ou nome de usuário, e no valor estariam todos os demais 
dados do cadastro, a fim de que o valor seja salvo de uma maneira que 
facilite o entendimento dos dados pela aplicação – no caso, você, quem o lê.
Figura 3 – Exemplo de armazenagem de dados em um NoSQL chave/valor
Fonte: Acervo do Conteudista
A chave é o atributo único pelo qual todas as pesquisas são realizadas, pois 
nessa modalidade não é possível executar busca dentro do valor, dado que 
tal característica torna esse tipo de armazenamento escalar com relação a 
input e output na base de dados, podendo trabalhar uma boa quantidade de 
dados em memória, o que também é a sua principal limitação.
Seu uso é indicado no armazenamento de informação em sessão, em perfis 
de usuário e preferências, além de dados no carrinho de compras. Contudo, 
não é recomendado para relacionamento entre os dados, transações com 
múltiplas operações, consultas por dados, atributos e operações em conjunto.
Pode-se citar como exemplos de softwares o DynamoDB – da Amazon –, 
Redis e Project Voldemort;
2. Colunas – o termo coluna é o nome usual deste padrão de armazenamento, 
mas o uso de tal expressão pode gerar algumas dúvidas: pense que os 
dados são agrupados como uma unidade celular por meio da key rown 
(chave) e seus dados. As colunas são dinâmicas, assim, caso o campo não 
seja preenchido, não será gerada uma coluna em branco na base de dados, 
como mostra a Figura 4.
De todos os bancos NoSQL, esse padrão é o mais próximo do banco de 
dados relacional, pois é eficaz em manter dados relacionados agrupados; 
contudo, as colunas são lidas todas de uma vez, gerando, assim, certo custo 
de acesso aos dados.
Pode ser utilizado, por exemplo, em registro de eventos (log) e Sistemas de 
Gerenciamento de Conteúdo (CMS). Ademais, não é indicado quando os 
sistemas requerem Acid para leituras e gravações.
Nesta categoria pode-se citar o Apache Cassandra, Apache HBase, Bigtable 
– da Google – e SimpleDb – da Amazon.
12
13
Tabela 1 – Exemplo de dados salvos em NoSQL de colunas
Chave Colunas
ibsribas
name email adress state
Jessica jb@email.com onde judas perdeu as botas CA
kvkvane
name email adress state
Ana Maria kyka@email.com.br terra do nunca SO
vaminkes
name email
Yasmin ykesler@email.com
Fonte: Acervo do Conteudista
3. Documento – nesta modalidade são armazenados dados semiestruturados 
em documentos JavaScript Object Notation (Json) – notação de objetos 
JavaScript – ou Extensible Markup Language (XML). Os desenvolvedores 
de aplicação web têm certa preferência por essa modalidade, pois a troca 
de dados utilizando o padrão Json é nativa nesse tipo de aplicação. Na 
Figura 5 há um exemplo de documento Json com dados sobre usuário em 
um contexto de um site de relacionamentos, no qual todas as informações 
e desejos do cliente estão no mesmo documento.
Entre as suas características, destaca-se o fácil acesso aos atributos internos 
do documento, mas consultas complexas que demandem dados de outros 
itens se tornam um pouco difíceis, pois todos os documentos envolvidos 
devem estar na mesma coleção – por isso o seu uso não é indicado em tais 
circunstâncias.
Seus exemplos de utilização são diversos, mas pode-se citar log; CMS; 
análises web ou tempo real (analytics) e aplicação de comércio eletrônico. 
Os SGBD mais usuais nesta categoria são MongoDB e CouchDB.
Figura 4 – Exemplo de arquivo NoSQL do tipo documento
Fonte: Acervo do Conteudista
13
UNIDADE NoSQL
4. Grafo – é baseado na teoria, na qual os vértices ou nós possuem os dados 
e as arestas são os relacionamentos que ligam os nós – tal como mostrado 
na Figura 6. Os vértices são usuários de uma rede social, enquanto que os 
relacionamentos são as interações entre os quais.
Uma consulta na base de dados é realizada quando percorre o grafo. O cus-
to de incluir novos relacionamentos é baixo, diferentemente de um banco 
relacional. O seu principal foco é encontrar padrões entre os dados.
Sua utilização é indicada quando os dados estão conectados em, por exem-
plo, roteamento e serviços baseados em localização, ou sistemas de reco-
mendação. Mas o seu uso não é indicado quando as atualizações ocorrerem 
em lote. O banco de dados mais conhecido é o Neo4J.
Figura 5 – Exemplo de armazenagem em NoSQL do tipo grafo
Fonte: Acervo do ConteudistaNote que cada estratégia de armazenamento NoSQL apresenta vantagens e 
desvantagens, de modo que ao escolher um SGBD para o seu sistema, você deve 
considerar, na natureza do problema, cada estratégia a fim de escolher a ferramenta 
que lhe trará maior benefício.
Veja a definição de grafo em: https://youtu.be/gJvSmrxekDo
Ex
pl
or
14
15
Considerações Finais
Por muitos anos, ao se projetar softwares na fase de definição da base de dados, 
já era inerente ao processo pensar nas tabelas e em suas relações. A única escolha 
a ser feita era qual SGBD poderia se adequar melhor – veja bem, o foco era 
escolher o software, pois o modelo já se sabia que era relacional.
Mas isso mudou nos últimos anos devido à alteração de padrão de consumo e 
geração de dados atuais, fazendo surgir o conceito NoSQL. Esse tipo de SGBD 
tornou-se essencial a problemas relacionados a Big Data, mas a sua utilização não 
precisa se restringir somente a essa área, aumentando, assim, a diversidade de 
recursos disponíveis na área de banco de dados.
Atualmente, na fase de especificação do BD para o software, deve-se conside-
rar, na característica do problema, quais requisitos são essenciais a serem sanados 
na taxa de crescimento dos dados para, assim, definir a melhor estratégia de arma-
zenamento a ser aplicada.
15
UNIDADE NoSQL
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Leitura
6 motivos para usar bancos de dados NoSQL
ALVES, G. F. de O. 6 motivos para usar banco de dados NoSQL. Dicas de Progra-
mação, 10 jun. 2015.
https://goo.gl/DgEUty 
Banco de dados NoSQL: Um novo paradigma - Revista SQL Magazine 102
BANCO de dados NoSQL: um novo paradigma. SQL Magazine, n. 102, [20--].
https://goo.gl/onuWUf
Bancos de dados NoSQL: uma visão geral
GROFFE, R. Banco de dados NoSQL: uma visão geral. iMasters, 30 set. 2016.
https://goo.gl/oSw9gB
Considerações sobre o Banco de Dados Apache Cassandra
PERERA, S. Considerações sobre o banco de dados Apache Cassandra. IBM 
DeveloperWorks, 20 jul. 2012.
https://goo.gl/xAMuP1
GraphDB Series: o que é um banco de dados de grafos
SATO, P. M. GraphDB Series: o que é um banco de dados de grafos. iMasters, 
9 jan. 2014.
https://goo.gl/4gTBTm
Escolhendo a ferramenta certa para o banco de dados NoSQL
VARDANYAN, M. Escolhendo a ferramenta certa para o banco de dados NoSQL. 
iMasters, 16 ago. 2011.
https://goo.gl/WwqBLx
16
17
Referências
AMAZON DynamoDB. [20--]. Disponível em: <https://aws.amazon.co https://
aws.amazon.com/pt/dynamodb/m/pt/dynamodb>. Acesso em: 23 jan. 2018. 
APACHE Cassandra. [20--]. <http://cassandra.apache.org>. Acesso em: 23 jan. 2018.
APACHE CouchDB. [20--]. <http://couchdb.apache.org>. Acesso em: 23 jan. 2018.
CLOUD Bigtable. [20--]. <https://cloud.google.com/bigtable/?hl=pt-br>. Acesso 
em: 23 jan. 2018.
DECANDIA, G. et al. Dynamo: Amazon’s highly available key-value store. ACM 
Sigops Operating Systems Review, v. 41, n. 6, p. 205-220, 2007.
ELMASRI, R.; NAVATHE, S. B.; DE OLIVEIRA MORAIS, R. Sistemas de banco 
de dados. [S.l.: s.n.], 2010.
HAN, J. et al. Survey on NoSQL database. In: PERVASIVE COMPUTING AND 
APPLICATIONS (ICPCA); INTERNATIONAL CONFERENCE ON (IEEE), 6., 
2011. Annales… 2011. p. 363-366.
MONGODB. [20--]. Disponível em: <https://www.mongodb.com>. Acesso em: 
23 jan. 2018.
NEO4J. [20--]. Disponível em: <https://neo4j.com>. Acesso em: 23 jan. 2018.
PINTO, A. P. et al. Testes de performance utilizando o DB4O e MongoDB. e-RAC, 
v. 3, n. 1, 2013.
ROBINSON, I.; WEBBER, J.; EIFREM, E. Graph databases: new opportunities 
for connected data. [S.l.]: O’Reilly Media, 2015.
SADALAGE, P. J.; FOWLER, M. NoSQL essencial: um guia conciso para o 
mundo emergente da persistência poliglota. [S.l.]: Novatec, 2013.
VIEIRA, M. R. et al. Bancos de dados NoSQL: conceitos, ferramentas, linguagens 
e estudos de casos no contexto de Big Data. In: SIMPÓSIO BRASILEIRO DE 
BANCOS DE DADOS, 2012.
17