Banco de Dados

NoSQL e Big Data

Professor Marcio Victorino – mcvictorino@uol.com.br
Bibliografia
 NoSQL Essencial – Martin Fowler.
 http://nosql-database.org/
 http://hadoop.apache.org/
 http://bigdatauniversity.com/
 http://bigdataprojects.org/
 ACM.
 IEEE.

Professor Marcio Victorino 2

NoSQL
 Sofisticação crescente dos serviços disponibilizados
na web:
 Facebook, uma rede social com mais de 1 bilhão de
usuários;
 Google, um serviço de busca com mais de 190 milhões
de visitantes únicos por mês;
 Amazon, uma loja de varejo on-line com picos que
chegam a mais de 1 milhão de transações por segundo.
 O grande desafio: armazenar, recuperar e
processar, de forma eficaz, a grande quantidade de
dados estruturados e não-estruturados disponíveis.

Professor Marcio Victorino 3

NoSQL
 Necessidades:
 processar o volume crescente de dados;
 esquemas flexíveis;
 maior distribuição do processamento;
 flexibilização das estruturas de armazenamento desses
dados;
 escalabilidade horizontal;
 minimizar a incompatibilidade de impedância;
 lidar com documentos XML e JSON (JavaScript Object
Notation).

Professor Marcio Victorino 4

NoSQL

Para atender a essas novas demandas surgiu uma

nova geração de bancos de dados sem esquemas
rígidos baseados em modelos não-relacionais,
chamados bancos de dados NoSQL.

Professor Marcio Victorino 5

NoSQL
 O termo "NoSQL" foi utilizado pela primeira vez em 1990 por
Carlo Strozzi para designer um BD relacional de código
aberto que armazenava suas tabelas sob a forma de
arquivos ASCII, e cada tupla era representada por uma linha
com os campos separados por tabulação.
 O nome vem do fato de que o BD não utilizava SQL como
linguagem de consulta. Em vez disso, ele era manipulado
por shell scripts.
 Apenas em 2011 esse termo passou a representar uma
família de bancos de dados que podem ser categorizados
nos seguintes modelos: grafos, documentos, família de
colunas e par chave/valor.

Professor Marcio Victorino 6

NoSQL
 O uso do termo “NoSQL” como conhecemos hoje é resultado
de uma reunião realizada no dia 11 de julho de 2009, em
São Francisco, organizada por Johan Oskarsson.

 Surgiu como um hashtag para o Twitter: curto, fácil de

lembrar e sem muitos semelhantes no Google.

 O autor não esperava que se tornasse o nome da tendência

tecnológica, pois o nome não descreve verdadeiramente
esses sistemas.

Professor Marcio Victorino 7

NoSQL
 Características dos SGBDs:
 Não utilizam o SQL (possuem linguagens semelhantes).
 Geralmente são projetos de código aberto.
 A maioria dos BDs é orientada pela necessidade de
execução em clusters.
 Oferecem uma gama de opções para consistência e
distribuição.
 Não possuem esquemas rígidos.

Obs: Alguns autores alegam que “NoSQL” significa “Not Only SQL”. No
entanto Fowler alega que, nesse caso, a escrita correta seria “NOSQL” .
Além disso, essa definição causaria uma grande confusão, pois o Oracle
e o Postgres se enquadrariam nela.
Professor Marcio Victorino 8
NoSQL
 Modelo de Dados Agregados:
 É um conjunto de objetos relacionados que desejamos
tratar como uma unidade. É uma unidade de
manipulação de dados e gerenciamento de consistência.
 Possuem uma estrutura mais complexa que um conjunto
de tuplas.
 Auxilia a execução em um cluster.
 Não possuem transações ACID que se espalham por
múltiplos agregados.
 Suportam manipulação atômica em um único agregado
por vez.
 Exemplos: modelo de dados chave/valor, de documentos
e família de colunas.
Professor Marcio Victorino 9
NoSQL
 Esquemas:
 Esses SGBDs não utilizam esquemas.
 O armazenamento torna-se muito mais informal.
 Facilidade de lidar com dados não uniformes.
 Cada registro contém apenas o necessário.
 Transfere o esquema para o código do aplicativo.

Professor Marcio Victorino 10

NoSQL
 Visão Materializada:
 Esse SGBDs não possuem visões tal como os bancos
relacionais. No entanto, eles podem ter consultas pré-
computadas, postas em cache, reutilizando o termo
“visão materializada” para descrevê-las.
 Uteis quando se pretende consolidar dados existentes em
vários agregados.
 Existem duas abordagens: antecipada e em intervalos
regulares.

Professor Marcio Victorino 11

NoSQL
 Modelos de Distribuição:
 Replicação: obtém os mesmos dados e os copias em
múltiplos nodos (mestre escravo e p2p).
 Fragmentação: coloca dados diferente em nodos
diferentes.
 São duas técnicas ortogonais: pode-se utilizar cada uma
ou ambas.

Professor Marcio Victorino 12

NoSQL
 Replicação Mestre escravo:
 Replica os dados em múltiplos nodos.
 Um nodo é designado como o mestre, ou primário, o qual é a fonte
oficial dos dados e, geralmente, fica responsável por processar
quaisquer atualizações nesses dados.
 Os demais nodos são escravos, ou secundários.
 Um processo de replicação sincroniza os escravos com o mestre.
 É mais útil para a escalabilidade quando há um conjunto de dados
com muitas leituras.
 Caso o mestre falhe, os escravos ainda podem lidar com as
solicitações de leitura (resiliência de leitura).
 Os mestres podem ser designados manual ou automaticamente.
 Pode causar inconsistência de leitura, caso todos os escravos não
estejam sincronizados.
 Ajuda com a escalabilidade de leitura, mas não com a de gravação.
Professor Marcio Victorino 13
NoSQL
 Replicação ponto a ponto (p2p):
 Não possui um mestre.
 Todas as réplicas têm o mesmo peso.
 Todas as réplicas podem receber gravações.
 A perda de algumas réplicas não impede o acesso ao
armazenamento de dados.
 Pode adicionar facilmente novos nodos para melhorar o
seu desempenho.
 Pode gerar gravações inconsistentes.
 Um bom ponto de partida para a replicação p2p é ter
uma replicação de fator 3 (três cópias de cada
fragmanto).
Professor Marcio Victorino 14
NoSQL
 Transações:
 Normalmente os SGBDs NoSQL orientados a agregados não
suportam transações ACID.
 Os SGBDs NoSQL orientados a agregados suportam transações
atômicas, mas apenas dentro de um único agregado.
 Uma alteração que afete múltiplos agregados deixa aberto um
período de tempo no qual os clientes poderiam executar uma leitura
inconsistente (janela de inconsistência, no SimpleDB da Amazon <
1seg).
 SGBDs orientado a grafos suportam transações ACID.
 Abordagens pessimistas bloqueiam os registros para evitar conflitos.
 Abordagens otimistas detectam conflitos e os resolvem.

Professor Marcio Victorino 15

NoSQL
 Teorema CAP:
 Dadas três propriedades, Consistência, Disponibilidade (Availability) e
de Particionamento, somente é possível obter duas delas.
 Servidor único: possui Consistência e Disponibilidade, mas não
possui Particionamento.
 Embora o teorema CAP seja, muitas vezes, declarado como “só pode
ter dois dos três”, na prática ele diz que, em um sistema que possa
sofrer partições, como os sistemas distribuídos, você tem que
balancear a consistência com disponibilidade. Nesse caso, o sistema
resultante não seria nem perfeitamente consistente nem
perfeitamente disponível, mas teria uma combinação razoável para
suas necessidades específicas.

Professor Marcio Victorino 16

NoSQL
 ACID x BASE:
 BASE - Basically Available, Soft state, Eventual
consistency.
 SGBDs NoSQL seguem as propriedades BASE.
 Não definição consensual para “basicamente disponível”
nem para “estado soft”.
 Consistência eventual significa que, em algum momento,
todos os nodos em um sistema NoSQL podem ter
inconsistências de replicação, mas, se não houver mais
atualizações, todos os nodos acabarão atualizados com o
mesmo valor.

Professor Marcio Victorino 17

NoSQL
 Relaxamento da Durabilidade em SGBDs NoSQL:
 Há casos em que se deseja trocar um pouco de
durabilidade por desempenho melhor.
 O estado de seção de usuários podem ser não duráveis
em troca de uma maior responsividade do web site.

Professor Marcio Victorino 18

 Banco de Dados de
Chave-Valor

Professor Marcio Victorino 19

BD Chave-Valor
 Um depósito chave-valor é uma tabela hash
simples, utilizada principalmente quando todo o
acesso ao BD é feito por meio da chave primária.
 Equivale a uma tabela em um SGBDR tradicional
com duas colunas, ID e Nome, sendo a coluna ID a
chave e a coluna Nome, Armazenando o Valor.
 Se um ID já existir, o Valor atual é sobrescrito, caso
contrário, cria-se um novo registro.

Professor Marcio Victorino 20

BD Chave-Valor
 São os depósitos de dados No SQL mais simples de
utilizar da perspectiva de uma API.
 O valor é um dado que o depósito apenas
armazena, sem se preocupar ou saber seu
conteúdo. É responsabilidade do aplicativo entender
o que foi armazenado. O valor pode ser blob, texto,
JSON, XML, etc.
 O acesso sempre é feito pela chave e, por isso,
esses BDs geralmente apresentam um ótimo
desempenho e escalabilidade.
Professor Marcio Victorino 21
BD Chave-Valor
 Riak.
 Redis.
 MemcachedDB.
 HamsterDB.
 AmazonDynamoDB.

Professor Marcio Victorino 22

BD Chave-Valor
 Todos os armazenamentos de chave-valor só
podem ser consultados pela chave.
 Muito utilizados para armazenar:
 dados de sessão;
 dados de carrinhos de compras;
 perfis de usuário.

 Não deve ser utilizado:

 Quando houver relacionamentos entre os dados;
 Transações com várias chaves de uma vez;
 Consulta por dados.
Professor Marcio Victorino 23
 Banco de Dados de
Documentos

Professor Marcio Victorino 24

BD de Documentos
 Os documentos armazenados podem ser JSON,
BSON, XML, entre outros.
 Os documentos armazenados são semelhantes
entre si, mas não têm de ser exatamente os
mesmos.
 Armazenam documentos na parte do valor do
armazenamento de chave-valor, ou seja, a parte
valor pode ser consultada.
 A chave pode ser atribuída pelo usuário, desde que
seja única.
Professor Marcio Victorino 25
BD de Documentos
 MomgoDB.
 CouchDB.
 RavenDB.

Professor Marcio Victorino 26

BD de Documentos
 Muito utilizados para armazenar:
 Registro de eventos (log);
 Sistemas gerenciadores de conteúdo;
 Blog;
 Análises web em tempo real;
 Comércio eletrônico.

 Não deve ser utilizado:

 Transações com vários documentos de uma vez;
 Consulta em estruturas agregadas variáves.

Professor Marcio Victorino 27

 Banco de Dados de
Família de Colunas

Professor Marcio Victorino 28

BD Família de Colunas
 Permitem o armazenamento de dados com chaves
mapeadas para valores, e os valores são agrupados em
múltiplas famílias de colunas, cada uma dessas famílias de
colunas funcionando como um mapa de dados.
 Famílias de colunas são grupos de dados relacionados que,
frequentemente, são acessados juntos.

Professor Marcio Victorino 29

BD Família de Colunas
 Cada família de counas pode ser comparada a um contêiner
de linhas em uma tabela de SGBDR, onde a chave identifica
a linha, que é constituída de múltiplas colunas.
 Linhas diferentes não precisam possuir as mesmas colunas,
e novas colunas podem ser adicionadas a qualquer linha, a
qualquer momento, sem a obrigatoriedade de ter de
adicioná-las às outras linhas também.
 Famílias de colunas são eficazes para manter dados
relacionados agrupados.

Professor Marcio Victorino 30

BD Família de Colunas
 Cassandra.
 Hbase.
 Hypertable.
 Amazon SimpleDB.

Professor Marcio Victorino 31

BD Família de Colunas
 Muito utilizados para armazenar:
 Registro de eventos (log);
 Sistemas gerenciadores de conteúdo;
 Blog;
 Contadores (visitante de paginas);
 Uso expirado (banners).

 Não deve ser utilizado:

 Transações ACID;
 Consulta em estruturas agregadas variáves.

Professor Marcio Victorino 32

 Banco de Dados de
Grafos

Professor Marcio Victorino 33

BD de Grafos
 Armazenam entidades e relacionamento entre essas
entidades.
 Entidades são nós que possuem propriedades.
 Relacionamento são arestas que podem possuir várias
propriedades.
 As arestas possuem significado direcional.
 Uma consulta é conhecida como travessia do grafo.
 Não há limites para o número e tipos de relacionamento que
um nodo pode ter.
 Não são orientados a agregados.

Professor Marcio Victorino 34

BD de Grafos

Professor Marcio Victorino 35

BD de Grafos
 Operam em nodos conectados, então, a maioria dos BDs,
geralmente, não suporta a distribuição de nodos em
servidores diferentes.
 Há algumas soluções que suportam a distribuição de nodos
em um cluster de servidores.
 Podem ser compatíveis com as propriedades ACID (Neo4J).
 Por serem orientados a relacionamentos, sua fragmentação
é difícil.

Professor Marcio Victorino 36

BD de Grafos
 Neo4J.
 Infinite Graph.

Professor Marcio Victorino 37

BD de Grafos
 Muito utilizados para armazenar:
 Redes sociais;
 Roteamento, envio e serviços baseados em localização;
 Mecanismos de recomendação;

 Não deve ser utilizado:

 Quando é comum se alterar propriedades em todas as
entidades do domínio modeloado.

Professor Marcio Victorino 38

 Big Data

Professor Marcio Victorino 39

Big Data
 Estima-se que, do início da civilização até 2003, a
humanidade tenha criado cinco exabytes (10 bytes
elevados a 18ª potência) de dados.
 Atualmente cria-se esse mesmo volume a cada dois
dias.
 Um estudo da International Data Corporation (IDC)
indica que, de 2012 até 2020, o volume de dado
armazenado na internet deverá dobrar a cada dois
anos.

Professor Marcio Victorino 40

Big Data
 Baseado nesses domínios de aplicação em que há
um volume massivo de dados, nos mais variados
formatos e que precisam ser processados em uma
determinada velocidade, a International Business
Machines (IBM) criou o termo “Big Data”. Esse
termo faz menção aos 3Vs:
 enorme volume de dados;
 enorme variedade de dados;
 velocidade necessária para o seu processamento.

Obs: já existem autores citando mais dois V’s: veracidade e

valor.
Professor Marcio Victorino 41
Big Data

Obs: Já existem autores citando mais dois V’s: veracidade e

valor.
Professor Marcio Victorino 42
Big Data
 Para fazer frente a esses novos desafios uma nova
geração de arquiteturas tem sido proposta, como
por exemplo, o conceito de MapReduce
apresentado pelo Google.
 Essa abordagem busca dividir os problemas
complexos do Big Data em pequenas unidades de
trabalho e processa-las em paralelo.

Professor Marcio Victorino 43

Big Data
 O Map-Reduce pode ser dividido em dois estágios:
 Passo de mapeamento: o nó mestre divide os dados em
vários subconjuntos menores, um nó trabalhador
processa um subconjunto de dados menor sob o controle
de um rastreador de trabalho e armazena o resultado no
sistema de arquivos local, onde um redutor será capaz de
acessá-lo.
 Passo de redução: esta etapa analisa e reúne os dados
de entrada a partir das etapas de mapeamento. Podem
haver múltiplas tarefas de redução para paralelizar a
agregação, e essas tarefas são executadas nos nós
trabalhadores sob o controle do rastreador de trabalho.

Professor Marcio Victorino 44

Map-Reduce

A função map lê registros do banco de dados e emite pares de chave-valor.

A função reduce recebe diversos pares de chave-valor com a mesma chave

e os agrega em um.
Professor Marcio Victorino 45
Map-Reduce

Particionar permite que funções reduce sejam executadas em paralelo

sobre diferentes chaves.

Professor Marcio Victorino 46

Big Data

Professor Marcio Victorino 47

 Criado por Doug Cutting, o Hadoop foi inspirado no
BigTable, que é o sistema de armazenamento de
dados do Google, no Google File System e no
MapReduce. O Hadoop é um framework baseado
em Java e uma plataforma heterogênea com
licença open source.

Professor Marcio Victorino 48

 Embora os subprojetos do Hadoop mais conhecidos
sejam o MapReduce e seu sistema de arquivos
distribuídos, Hadoop Distributed File System
(HDFS), outros subprojetos oferecem uma série de
serviços complementares ou adicionam abstrações
de maior nível, ou seja, facilitando o
desenvolvimento. Entre os demais subprojetos, vale
destacar:
 Avro: um sistema de serialização de dados que fornece
RPCs (Remote Procedure Calls) eficientes e
independentes de linguagem, armazenamento persistente
de dados, estruturas de dados ricas, entre outros
recursos;
Professor Marcio Victorino 49
  Pig: uma plataforma para grandes conjuntos de dados
que possui uma linguagem de programação de alto nível
para realizar a análise desses dados. Além disso, possui a
infraestrutura necessária para avaliar os programas
criados, como um compilador especial que transforma as
aplicações desenvolvidas nessa linguagem em uma
sequência de programas MapReduce;

 HBase: uma base de dados distribuída, criada para

armazenar tabelas muito grandes (milhões de colunas x
bilhões de linhas). Trata-se de um modelo de
armazenamento orientado a colunas, muito fácil de
utilizar com a API Java;
Professor Marcio Victorino 50
  ZooKeeper: um serviço centralizado para coordenação de
aplicações distribuídas. Mantém informações de
configuração das aplicações distribuídas, além de
fornecer a sincronização das mesmas. Esse tipo de
serviço é comumente utilizado em aplicações distribuídas,
o ZooKeeper fornece uma interface simples para auxiliar
o desenvolvedor;

 Hive: uma espécie de Data Warehouse distribuído, facilita

a utilização de grandes conjuntos de dados (datasets) em
ambientes de armazenamento paralelo. Provê uma
linguagem baseada em SQL, chamada HiveQL, que serve
para facilitar a estruturação dos e pesquisa nos dados.
Professor Marcio Victorino 51
Big Data Analytics
 Big Data Analytics pode ser interpretado como
procedimentos complexos que são executados em
larga escala sobre grandes repositórios de dados,
cujo principal objetivo é o de extração de
conhecimento útil mantido em tais repositórios. Em
outras palavras é a aplicação de técnicas analíticas
avançadas a conjuntos de dados muito grandes.

Professor Marcio Victorino 52

 Fim

Professor Marcio Victorino 53