SGBD NoSQL

Débora Souza – in940

dsls@cin.ufpe.br
  Introdução
 Motivação
 O que é NoSQL?
 Modelos de dados NoSQL
 Chave-valor
 Colunas
 Documentos
Roteiro  Grafos
 Quem usa que modelo de dados?
 Como escolher um modelo?
 Teorema CAP
 Persistência Poliglota
 Alguns SGBDs NoSQL
 Desafios de Pesquisa
  Banco de Dados Relacionais tem sido o amplamente adotados
desde a década de 70.
 Bem sucedidos!

Introdução
 Contudo, devemos nos fazer algumas perguntas:
 Que tipos de aplicações tínhamos na década de 70?
 Volume de dados produzido?
  E hoje, com as novas gerações de aplicações?
 Cloud Computing
 Web 2.0
 Redes Sociais
 Business Intelligence
Introdução
Introdução
(exemplo)

Retirado de: http://www.bbc.com/portuguese/noticias/2015/08/150828_facebook_recorde_lab. Visto em: 19/05/2016.

  Várias das novas gerações de aplicações requerem o
armazenamento e processamento de um grande montante de
dados (tera/peta bytes).
Motivação
 O processamento e armazenamento de dados tem-se tornado
cada vez mais complexo:
 Big Data
  Por que BDs Relacionais não são adequado para armazenamento
de dados de qualquer tipo de aplicação?
 Baseados em estruturas que permite relacionar informações de
diferentes tabelas.
Motivação 
 Esquema estático.
Usa linguagem de consulta padrão.
 Trabalha com dados estruturados.
 Não trabalha bem com escalamento horizontal.
 ACID (Atomicidade, Consistência, Isolamento e Durabilidade)
  NoSQL “Not only SQL”.

 Uma nova variedade de bancos de dados que não seguem o

Modelo Relacional.

O que é
 O termo NoSQL foi primeiramente usado informalmente em
NoSQL? Strozzi em 1998.

 Apresenta:
 Flexibilidade
 Ausência de esquema
  NoSQL não diz respeito a um modelo de dados específico.
 Agrupamento de alguns modelos de dados que se distanciam da
O que é abordagem relacional.

NoSQL?
 Tais modelos podem ser código-aberto, distribuídos,
horizontalmente escaláveis.
  Desenvolvidos para solucionar problemas tais como:
 manipulação de dados como o gerenciamento de grandes bases de
dados
O que é  demandas por alta disponibilidade
 possibilidade de escalar para proporções maiores
NoSQL?
 Fornece sistema BASE (Basically Available, Soft State, Eventual
consistent)
 Chave-valor

Modelos de Colunas
Modelos Documentos
de dados
dados NoSQL

Grafos
  Dentre os sistemas de bancos de dados conhecidos como NoSQL,
o Chave-valor é o que apresenta o modelo mais simples.

Chave-valor
 Sua estrutura é composta por uma chave e um valor.
 Esse modelo pode ser comparado com a estrutura de dados Tabela
Hash.
  Além dos tipos básicos de dados como numerais e cadeias de
caracteres, algumas soluções desse modelo de banco de dados
permitem listas e conjuntos de valores dos tipos básicos.

Chave-valor  Não costuma permitir que consultas sejam realizadas sobre os

seus dados, apenas sobre as chaves.

 O que o modelo chave valor não grupa dados por entidades

(tabelas), tão pouco por diferentes tipos (coluna).
  Exemplo:

Chave-valor
  Algumas características:
 Não é possível a definição de um esquema.
 Formado por uma única tabela composta por duas colunas: uma
correspondente à chave e a outra ao valor associado.
Chave-valor  A chave precisa ser única.
 O valor da chave é definida pelo usuário.
 Não são agrupados por tipos de dados.
 Os dados estão armazenados em uma única coluna de uma mesma
tabela.
  Algumas características (cont.):
 Não existe a possibilidade ou mesmo necessidade de uso de junções.
 Não existe referência de chaves.
 Não dá suporte a relacionamentos entre os itens de dados.
 Não se tem uma linguagem de consulta padrão.
Chave-valor
 Por que usar esse modelo de dados?
 Menor tempo de resposta permitindo que a capacidade de
armazenamento de suas bases de dados seja uma das maiores dos
sistemas enquadrados no conceito NoSQL.
  Organizado em linhas e colunas.

 Essa abordagem é projetada para tratar os dados de maneira não

Colunas normalizada.

 Normalmente não privilegia a consistência das informações.

  Comparando com o modelo relacional o modelo em colunas faz
uma inversão na organização de seus dados.
 Os atributos que compõem uma instância são organizados em
colunas e as linhas passam a conter as ocorrências de determinado
Colunas atributo para cada instância de dados.
 As linhas não mais armazenam uma tupla, mas sim um conjunto de
atributos de mesmo tipo, enquanto que o conjunto de atributos de
uma coluna contém a informação de uma instância por completo.
  Exemplo:
Nome
Telefone
CPF

Colunas
CPF Nome Telefone
  Os atributos de uma mesma categoria são priorizados.

Colunas  Essa priorização permite que consultas que façam análises em

subconjuntos de dados possam ser mais eficientes.
 A obtenção de itens inteiros passa a ser mais custosa.
  Instâncias de uma entidade fazem parte da mesma família de
colunas.

 Família de coluna:
 Permite a existência de atributos não atômicos
 Podem apresentar quantidades de atributos diferentes
Colunas  Não sendo necessário reservar espaços de armazenamento para
valores nulos.

 Não permite consultas com a junção de famílias de colunas.

 Não da suporte ao uso de chaves estrangeiras.

  Faz uso de associações entre pares chaves e valores.

 Os dados não são dispostos em uma única estrutura de dados

Documentos (diferente do Chave-valor).

 Os dados de uma entidade são agrupados em documentos que

podem seguir a codificação XML ou JSON, por exemplo.
  Um documento é uma coleção de chaves e valores que está
relacionado a uma instância de dados.

 Documentos de um mesmo domínio são armazenados em uma

Documentos coleção.

 Modelo é flexível:
 Documentos de uma mesma coleção podem apresentar campos
distintos.
  Exemplo:

Documentos
  Permite que consultas mais complexas envolvendo documentos
de coleções distintas ocorram.
 É necessário que um documento possua um DBRef (Database
Documentos References) do documento relacionado.
 DBRef é uma estrutura que armazena as informações da coleção de
documentos e ObjectId do documento referenciado.
  Exemplo:

Documentos
  DBRef não garantem integridade referencial.

 Consultas com DBRef podem ser muito custosas em termos de

desempenho.
Documentos
 Como alternativa pode-se optar por aninhar mais dados por
documento.
 Dados relacionados são persistidos dentro do mesmo documento.
  Exemplo:

Documentos
  Chave-valor, colunas e documentos têm seu foco no
armazenamento dos dados.

Grafos  No modelo em grafo o foco é no relacionamentos que ocorrem

entre as entidades de sua base.

 Abordagem estar baseada na teoria dos grafos.

  Exemplo:

Grafos
  Esse modelo possui três tipos de informações: os nós, arestas e
propriedades.
 Nós: instâncias de dados.
Grafos  Arestas: relacionamentos mantidos entre instâncias.
 Propriedades: valores de dados contidos nas instâncias. Podendo
assumir valores como: booleanos, inteiros, caracteres e conjunto de
valores.
  Os nós e arestas podem conter rótulos.
 Nós: podem ser usados para diferenciarem instâncias como
Grafos funcionário e cliente, por exemplo.
 Arestas: determinar o tipo de relacionamento que está ocorrendo
como, por exemplo, a venda ou o aluguel de um veículo.
  Arestas também podem conter propriedades que as descrevem
que assim como os nós.

 Exemplo:
Grafos
  Garante a integridade referencial.
 O nó de entrada sempre fará referência ao nó de saída.

 As chaves de acesso aos nós são definidas automaticamente pelo

Grafos sistema de banco de dados.

 Excelentes para aplicações com dados muito relacionados

 Ex. serviços baseados em localização, sistemas de recomendação.
  Consultas complexas menos custosas do que o relacional
 Uso de algoritmos bem definidos para percorrer grafos

Grafos  Pode tornar consultas rápidas:

 Utilização de propriedades de grafos
 Algoritmos de menor caminho
Quem usa que
modelo de
dados?
  Depende dos requisitos da aplicação
Como escolher 

Tamanho dos Dados
Complexidade
um modelo?  Teorema CAP
 Formato de Dados
  Os modelos NoSQL não objetivam substituir os bancos de dados
baseados no modelo Relacional.
 Visa solucionar uma nova e diferente demanda de necessidades de
manipulação de dados.
Teorema CAP
 No ano 2000, o Profº Eric Brewer apresentou o teorema CAP
(Consistency, Availability and PartitionTolerance).
  A ideia central do teorema CAP diz que um sistema distribuído
não pode oferecer a consistência, disponibilidade e tolerância a
Teorema CAP falhas ao mesmo tempo em um dado momento.
 Apenas é possível a garantia de duas das propriedades por vez.
  Ferramentas pertencentes a modelos de dados semelhantes
podem oferecer princípios diferentes.

Teorema CAP

Colunas
Chave-valor
  Os BD classificados como NoSQL podem conviver com outros
modelos bancos de dados?
 Persistência poliglota

Persistência  Aplicações com persistência poliglota são aquelas que precisam

que seus dados sejam representados e armazenados segundo
Poliglota múltiplos modelos de bancos de dados.
 Aplicações que utilizam mais de um SGBD para armazenamento de
dados.
 SGBD multi modelos.
  Exemplo:

Persistência
Poliglota
  ArangoDB:
 Modelo orientado a documento, chave-valor e grafo.
 ArangoDB query language (AQL).
 Permite o uso de joins.

 MongoDB:
Alguns SGBDs  Modelo orientado a documento.
NoSQL  A chave de uma instância, neste caso o documento, é chamada de
oid (ObjectId).
 Pode ser definida no momento da persistência do documento, ou pode
ter seu valor gerado aleatoriamente pelo próprio banco.
 Alta velocidade no acesso a dados.
 Suporta complexos tipos de dados.
 Oferece alto desempenho e alta disponibilidade.
  Cassandra:
 Modelo orientado a coluna.
 Open-source
 Originalmente criado pelo Facebook.
Alguns SGBDs  Projetado para oferecer alta escalabilidade, sem pontos de falhas e
com customizável nível de consistência.
NoSQL  Rendimento de gravação muito alto e bom rendimento de leitura
 Linguagem de consulta semelhante a SQL (desde 0.8 - Cassandra
Query Language) e suporte para procura por índices secundários
 Consistência ajustável e suporte para replicação
 Esquema flexível.
  Modelagem de Dados NoSQL
Desafios de  Migração de Banco de Dados Relacional para NoSQL
Pesquisa  Migração de Banco de Dados NoSQL na Nuvem
  Modelagem de Dados NoSQL:
 Como modelar os dados de modo a não aumentar a complexidade
Desafios de das consultas?
 Alguns trabalhos tem sido propostos para modelagem de NoSQL.
Pesquisa  Entretanto, eles consideram apenas qual o modelo mais viável para o BD
NoSQL.
 Não tratam de como modelar o NoSQL para uma aplicação.
  Modelagem de Dados NoSQL (cont.):
 Outros trabalhos propõe abordagens para a modelagem orientada a
Desafios de consulta.
 Desenvolvedor deve considerar quais consultas ele utilizará quando
Pesquisa estiver modelando o BD.
 Entretanto, mudanças nos requisitos de negócio/aplicação podem
tornar o modelo obsoleto.
  Migração de Banco de Dados Relacional para NoSQL
Desafios de  Mudanças:
 Demanda no gerenciamento de dados
Pesquisa  Requisitos das aplicações
 Popularização da computação em nuvem.
  Migração de Banco de Dados Relacional para NoSQL
 Algumas empresas que adotam DBs Relacionais se deparam com a
necessidade de novas abordagens para persistência:
 Devido a ampliação de seus serviços
Desafios de  Caso da Netflix:

Pesquisa  Em 2012 possuía 288 servidores distribuídos e operava com o

MySQL
 Passou a utilizar o Cassandra
 É interessante desenvolver abordagens que realizem essa migração
automática.
  Migração de Banco de Dados NoSQL na Nuvem:
 Tem provido Database-as-a-Service aos usuários.
 Diferentes modelos de dados têm inserido heterogeneidade nos
Desafios de serviços da nuvem.
 Provedores desenvolvem suas soluções de BDs NoSQL para
Pesquisa gerenciar seus dados
 Falta de portabilidade e interoperabilidade entre elas é um desafio:
 Quando o cliente está insatisfeito com o serviço e muda de provedor
 Devido a mudanças nos requisitos de negócio.
  Migração de Banco de Dados NoSQL na Nuvem:
 Migração automática de dados entre diferentes modelos de Banco
de Dados NoSQL é um tópico em aberto
 Em geral duas abordagens para migração tem sido adotadas:
Desafios de  Migração Direta
 Migração Intermediária
Pesquisa  Soluções tem sido propostas na literatura:
 Em geral, trabalham apenas com um subconjunto de tipos de BD
NoSQL
 Abordagem que engloba todos os tipos é necessária.
  FREITAS, Myller Claudino; SOUZA, DamiresYluska; SALGADO,
Ana Carolina Brandão. Mapeamentos conceituais entre os
modelos relacional e NoSQL: Uma abordagem comparativa.
Revista Principia - Divulgação Científica e Tecnológica do IFPB,
[S.l.], n. 28, p. 37-50, dez. 2015. ISSN 2447-9187.
 F. M. Schmidt, C. Geyer, A. Schaeffer-Filho, S. DeBloch andY. Hu,
"Change data capture in NoSQL databases: A functional and
performance comparison," 2015 IEEE Symposium on Computers
Referências and Communication (ISCC), Larnaca, 2015, pp. 562-567.
 Jing Han, Haihong E, Guan Le and Jian Du, "Survey on NoSQL
database," Pervasive Computing and Applications (ICPCA), 2011
6th International Conference on, Port Elizabeth, 2011, pp. 363-366.
 Vieira, M. R., Figueiredo, J. M., Liberatti, G. and Viebrantz, A. F. M.
(2012) “Bancos de Dados NoSQL: Conceitos, Ferramentas,
Linguagens e Estudos de Casos no Contexto de Big Data”.
Minicurso SBBD 2012, São Paulo, 2012.