Banco de dados NoSQL - SBBD2012

Prévia do material em texto

Bancos de Dados NoSQL
Conceitos, Ferramentas, Linguagens e 
Estudos de Casos no Contexto de Big Data
Marcos R. Vieira 
IBM Research Lab. – Brazil
Josiel M. de Figueiredo
Gustavo Liberatti
Alvaro F. M. Viebrantz
Instituto de Computação - UFMT
Outubro – 2012 IC - UFMT
2
Sumário
3
Sumário
• Introdução 
• Conceitos
• Produtos NoSQL
• Estudos de Casos
• Considerações Finais
4
Histórico dos Dados
Evolução
• nos tipos de dados
– multimídia, complexos, semiestruturados 
• na produção dos dados
– grande quantidade gerada em curto espaço de tempo 
• na transmissão dos dados
– redes de alta velocidade 
• no armazenamento dos dados 
– dispositivos com grande capacidade, na ordem de 
Terabytes
5Histórico dos Dados: solução dos 
SGBD Tradicionais
● Evolução nos tipos de dados
– adicionar novos tipos de dados nativos
– permitir tipos definidos pelo usuário (UDT)
● Evolução na produção dos dados
– uso de MemCache 
● Evolução na transmissão dos dados
– redes de alta velocidade 
● Evolução no armazenamento dos dados
– dispositivos SSD, alta velocidade 
6
SGBDR Tradicionais
Desafios atuais
1. dados na ordem de dezenas ou centenas de TB
– abordagem de cluster é cara
2. poder de crescimento elástico horizontal
– controle de transação ACID torna inviável a elasticidade
3. fácil distribuição dos dados e/ou processamento
– SGBD paralelos são caros
4. tipos de dados variados, complexos e/ou semiestruturados
– modelo de dados objeto-relacional não resolve todos os requisitos
7
SGBDR Tradicionais
● SGBDR: padrão de aplicação
● Aplicação baseadas na Web causam 
“picos” de uso:
– especialmente para sites de E-
Commerce
● Desenvolvedores começaram a integrar 
SGBDR com MemCache
8
Escalar Vertical (Scale Up)
• Diversos problemas em escalonamento vertical quando o banco de dados 
é muito grande 
– Melhor modo de fornecer ACID e um modelo rico é ter os dados em uma única 
máquina 
• SGBDR não foi inicialmente desenvolvido para ser distribuído 
• Existem soluções de banco de dados utilizando multi-node 
– Também conhecidos por “scaling out” ou “escalonamento horizontal” 
– Mais barato e mais viável utilizar “escalonamento horizontal” adicionando 
servidores menores e baratos do que investir em um u ńico servidor caro 
• Diferentes abordagens incluem:
– Master-Slave
– Sharding
9
Escalando SGBDR
Master-Slave
• Todos as escritas são feitas no master
• Todos as leituras são feitas nas replicas slave do 
banco de dados
• Leituras críticas podem estar incorretas
– escritas podem não terem sido propagadas
• Grande banco de dados podem trazer problemas
– master tem que propagar atualizações para os slaves 
10
Escalando SGBDR
● Particionamento ou Sharding
– Escala bem para ambas leituras e escritas
– Não transparente: aplicações tem que estar 
ciente do particionamento
– Não pode ter relacionamentos/junções entre 
as partições
– Perda de referência de integridade entre os 
shards 
11
Big Data, O que significa?
12
Big Data, O que significa?
1. Grande volume de dados na ordem de dezenas/centenas de TB
– e.g., projeto Square Kilometre Array (SKA) envolve a construção do maior radio 
telescópio que irá gerar até 1500 PBytes diariamente
– requer alto poder computacional para processamento, manipulação e armazenamento de dados 
2. tipos de dados variados, complexos e/ou semiestruturados
– Modelo flexível para armazenamento de dados complexos
3. armazenados em clusters de processadores de baixo custo
– e.g., Facebook tem 2700 nós em seu cluster com 60PB de armazenamento
4. poder de crescimento elástico horizontal
– Alocação/desalocação de recursos de hardware/software sob demanda da aplicação
13
Big Data, O que significa?
● crescimento do volume de dados que se torna difícil 
capturar, armazenar, gerenciar, compartilhar, 
analisar e visualizar com ferramentas tradicionais 
de SGBDR
● para alguns, Big Data significa usar sistemas NoSQL 
ou SGBDR paralelo para manipulação de grande 
quantidade de dados
14
Big Data
• Contextos que influenciaram o surgimento
– difusão dos dispositivos captação de dados 
– dispositivo com armazenamento na ordem de Terabytes 
– aumento de velocidade de transmissão nas redes
• Definição informal
– o processamento analítico e veloz de grande volumes de 
dados complexos produzidos por várias aplicações
● Volume：GBytes, TBytes, PBytes …
● Variedade: não estruturado, texto, imagens…
● Velocidade: dinâmico e, às vezes, variando no tempo
15
Big Data
• Exemplos de aplicações 
– científicas
– dados médicos e biológicos
– de engenharias
– redes sociais
– redes de sensores
– dados de Logs
16
Big Data e Computação em nuvem
1. Ambiente em Nuvem
– escalabilidade, elasticidade, tolerância a falhas, 
auto gerenciamento e a possibilidade de 
funcionar em commodity hardware
– primeiros SGBDR foram desenvolvidos para 
execução em ambientes corporativos
– suporte a alta carga de atualizações e processos 
de análises de dados
17
Big Data e Computação em nuvem
2. Ambiente de Gerenciamento de Dados Escalável:
– Single Tenant: uma aplicação complexa com um SGBD 
gerenciando uma grande quantidade de dados.
– Multitenant: grande número de aplicações com dados 
possivelmente não muito volumosos e até usando o 
mesmo esquema.
18Big Data: Por que o interesse 
agora?
● Crescente e diverso número de fontes de dados que geram 
uma quantidade grande de dados:
– Sensores (e.g, GPS, RFID)
– Web 2.0 (e.g., Twitter, Facebook, Wikis)
– Web clicks, Logs
● Dados muitos valiosos para serem apagados
● Drástica diminuição no custo do hardware (em especial) de 
armazenamento
● Crescimento de soluções baseadas de núvem
– Amazon S3
19
20
Solução para Big Data
Duas abordagens principais:
● SGBDR Paralelos
Duas abordagens principais:
● SGBDR Paralelos
● Ferramentas NoSQL
21
NoSQL
“Not Only SQL ”
• Classe de sistemas de armazenamento e 
consulta de dados não-relacional
• Não requerem um esquema fixo, ou 
• Não usam junções
• Relaxam uma ou mais das propriedades ACID
• teorema CAP 
22
NoSQL
Precursores do movimento NoSQL
• BigTable (Google)
• Dynamo (Amazon)
• Gossip protocol (descoberta e deteção de erro)
• Armazenamento distribuído de dados key/value
• Consistência eventual
• Teorema CAP
23
Sumário
• Introdução 
• Conceitos
• Produtos NoSQL
• Estudos de Casos
• Considerações Finais
24
Teorema CAP
• 3 propriedades de um sistema: 
– consistência, 
– disponibilidade e 
– particionamento
25
Teorema CAP
• Para um sistema de dados compartilhados
– até 2 dessas propriedades 
• “Particionar para escalar”
– escolha de consistência ou disponibilidade
– mais disponibilidade e menos consistência 
• Aplicações Web: A ou C
• SGBD tradicionais: C a A ou P
26
Teorema CAP
• Consistência Eventual
• BASE
– Basically Available
– Soft state
– Eventually consistent
• Eventual propagação de atualizações
• A não garantia de consistência nas leituras
27
Teorema CAP
Consistência Eventual
• Quando atualizações não ocorrem por um 
período de tempo longo, eventualmente todas as 
atualizações são propagadas no sistema e todos 
os nós estarão consistentes 
• Para uma certa atualização aceita e um dado nó, 
eventualmente a atualização alcança o nó ou o 
nó é removido do serviço 
28
Escalabilidade
• Tipos:
– Vertical → aumentar armazenamento e 
memória
– horizontal → aumentar hardware
• técnica de Particionamento dos Dados
– tabela hash distribuída
– sharding 
29
Paradigma MapReduce
• simplificar o processamento grande volume de 
dados de forma distribuída
• transparente os detalhes da distribuiçãodos 
dados
• duas etapas do processamento:
– Map: distribui e processa os dados entre os 
nós e gera resultado no formato <key, 
value>
– Reduce: processa os pares <key, value>
30
Paradigma MapReduce
31
Hadoop
● Sinônimo com o movimento de Big Data
• É um framework de computação distribuída com 
dois componentes:
– Hadoop Distributed File system (HDFS)
– Implementação Map-Reduce
32
Hadoop
1. Hadoop Distributed File system (HDFS)
– manipulação de dados no Hadoop,
– fornece uma camada transparente de um 
sistema de arquivo único,
– sistema de arquivo distribuído 
● arquivo em blocos de 64 ou 128MB 
● cada block é replicado várias vezes
33
Hadoop
2. Implementação Map-Reduce:
– Fornece um meio simples de quebrar 
a análise de grande volume de dados 
nos pequenos chunks
– O processamento dos chunks pode 
ser feito em paralelo
34
Hadoop vs. SGBDR
● SGBDR Tradicionais: Move os dados para computar
– Ao passo que processa mais dados, voce quer 
respostas interativas
– Tipicamente necessita hardware mais caros
– Falhas nos pontos de discos e redes podem ser um 
problema (por causa da ACID)
● Pode ser solucionado com hardware mais caro
– Difícil fazer distribuição
35
Hadoop vs. SGBDR
● Hadoop: Move a computação aos dados
– Segue o framework Map-Reduce
– Inicialmente pela Google: Map-Reduce e Google File System
– Comunidade desenvolve algoritmos Map-Reduce robustos
– HDFS para auto-replicar dados em múltiplos nós
– Executa uma tarefa MP única em todos/vários nós disponíveis no HDFS
– Usa commodity hardware
– Não necessita hardware especializado e caro
– Não ACID, mas BASE
36
Hadoop vs. SGBDR
SGBDR Tradicional Map-Reduce
Tamanha dos Dados Gbytes (Tbytes) Pbytes (Hbytes)
Acesso Interativo e Batch Batch
Atualização Leitura/Escrita 
várias vezes
Escrita única, 
Leitura várias vezes
Estrutura Schema estático Schema dinâmico
Integridade Alta (ACID) Baixa
Escalar Nao-Linear Linear
DBA Ratio 1:40 1:3000
37
Hadoop 
38
Sumário
• Introdução 
• Conceitos
• Produtos NoSQL
• Estudos de Casos
• Considerações Finais
39
NoSQL: categorias
Soluções NoSQL podem serem classificados em dois tipos:
• Key/Value ou “Big Hash Table”
– Amazon S3 (Dynamo)
– Voldemort
– Scalaris
• Sem Schema 
– Cassandra (column-based)
– CouchDB (document-based)
– Neo4J (graph-based)
– HBase (column-based)
40
NoSQL: Key/Value
Key/Value
• Vantagens:
– muito rápido
– altamente escalonável
– modelo simples
– possível de distribuição horizontal 
• Desvantagens:
– várias estruturas de dados (objects) não podem 
ser facilmente como pares de key/value 
41
NoSQL: sem esquema
Sem Schema
• Vantages: 
– modelo de dados sem esquema é mais rico que pares 
key/value
– consistência eventual
– vários são distribuídos
– provê excelente desempenho e escalabilidade 
• Desvantagens:
– tipicamente não suporta transações ACID ou junções 
42
NoSQL e CAP
43
Tipos de Soluções NoSQL
Vantagens Comuns
• barato (open source), fácil de implementar 
• dados são replicados para múltiplos nós idênticos
– tolerante a falhas
• Fácil substituição dos nós down
– sem ponto simples de falha
• fácil de distribuir
• não requer esquema fixo
• pode escalar up/down
• relaxa a necessidade de consistência (CAP) 
44
NoSQL
O que eu irei perder?
• junções
• group by 
• order by 
• transações ACID
45
Sumário
• Introdução 
• Conceitos Relacionados
• Produtos NoSQL
• Considerações Finais
46
Categorias de NoSQL
Key/value
stores
234
1
{wiki: 
abc}
432
4
{test 
asdf}
423
4
{url: 
com}
527
3
{url: 
123}
745
6
{qa: 
dfsdfd}
642
1
{234: 
2342}
524
8
{id: 
5248}
234
2
{e: as, 
r:eq}
Document
database
A
Column
family
Graph
database
1
1 2
1
9
3
1
1
8
6
1 9
3
2
2 8
1
1
47
Key-Value Stores
• "Dynamo: Amazon's Highly Available Key-
Value Store"[2007]
• Modelo de Dados:
– mapeamento global key-value
– altamente tolerante a falha
– Armazenamento de dados distribuído
● Altamente disponível
• Produtos:
– Riak, Redis, Voldemort, Dynamo, Berkeley DB, 
MemcacheDB, … 
Key/value
stores
234
1
{wiki: 
abc}
432
4
{test 
asdf}
423
4
{url: 
com}
527
3
{url: 
123}
745
6
{qa: 
dfsdfd}
642
1
{234: 
2342}
524
8
{id: 
5248}
234
2
{e: as, 
r:eq}
48
Column Family (BigTable)
• Google's "Bigtable: A Distributed Storage 
System for Structured Data"[2006]
• Data Model:
– grande tabela, com familia de colunas
– map-reduce para consultas e processamento
– modelo compacto e flexível
• Produtos:
– HBase, HyperTable, Cassandra, SimpleDB, 
Cloudata, Cloudera, SciDB, …
Column
family
1
1
1
1 1
1
1
1
1
1
49
Document Databases
• Modelo de Dados:
– Coleção de Documentos
– Um documento é uma coleção de 
key-value
– Centrado a índice, vários map-
reduce
• Produtos:
– MongoDB, CouchDB, RavenDB, …
Document
database
A
50
Graph Databases
• Modelo de Dados
– Nós com propriedades
– Relacionamentos com propriedades
– Hipergrafos
• Produtos
– Neo4, SonesGraphDB, OrientDB, Sones, 
HyperGraphDB, Virtuoso, VertexDB, …
Graph
database
51
NoSQL: Classificação
NoSQL 
Produtos
Modelo de 
Dados
API Consulta
Riak Key-value 
store
get/put
Voldemort Key-value 
store
get/put
CouchDB Document 
Store
Map/Reduce 
View
MongoDB Document 
Store
Cursor
Neo4J Graph DB Graph
Redis Collection Collection
Cassandra Column Family Thrift
HBase Column Family Thrift, REST
SciDB Column Family Array
52
NoSQL: Classificação
Desemp. Escalabil. Flexibil. Complex. Funcionalidade
Key-value 
stores
Alta Alta Alta Nenhuma Variável
Column 
stores
Alta Alta Moderada Baixa Mínima
Document 
stores
Alta Variável 
(alta)
Alta Baixa Variável
Graph DB Variável Variável Alta Alta Teoria de grafos
SGBDR Variável Variável Baixa Moderada Algebra 
relacional
53
Hadoop
Estudo de Caso
54
Hadoop
• HDFS (Hadoop Distributed File System) 
– sistema de arquivos voltado para o processamento de 
grande volume dados, na ordem de Petabytes.
– controle de falhas.
– acesso paralelo em vários nós.
– acesso sequencial em cada nó.
– armazenamento com replicação e particionamento 
automático, ocorrendo de forma transparente.
• MapReduce Framework 
– facilita o desenvolvimento de aplicações para o 
processamento de grande volume de dados de forma 
distribuída, paralela e com tolerância a falhas.
55
Hadoop
• Como funciona o MapReduce no Hadoop
– a ideia principal é criar uma tarefa (Job)
● particionamento dos dados para as funções de Map.
● as saídas das funções de Map são ordenadas e enviadas 
para as funções de Reduce.
● de forma paralela e distribuída dentro do nós do cluster.
● as saidas e entradas são armazenadas no HDFS.
– o Hadoop também pode gerenciar as tarefas passadas 
para execução.
● ordem de execução.
● monitoramento.
● Re-execução em caso de falha.
56
Hadoop
• Arquitetura básica
– Name Node
– Job Tracker
– Task Tracker
– Data Node
57
58
Hadoop: IBM Biginsights
• Utilizamos uma distribuição fornecida pela 
IBM
• Plataforma para processamento de grande 
volume de dados.
• Utiliza o Apache Hadoop.
• Configuração e instalação automatizada
– Standalone
– Cluster
59
Hadoop: IBM Biginsights
• Componentes instalados
60
Estudo de Caso: patentes
• Proteção da propriedade intelectual.
– Empresas buscando inovação.
– Buscas por novas tecnologias.
– Economia de tempo e recursos.
• Patentes
– Possuem informações técnicasinéditas.
– Fonte de inspiração para novas tecnologias.
– Pouco utilizado ainda pelas empresas 
brasileiras.
61
Estudo de Caso: patentes
• Segundo trabalhos elaborados pela Organização 
Mundial da Proriedade Intelectual, dois terços de 
toda publicação técnica são apresentadas 
somente através do sistema de patentes.
– Mas são dados difíceis de se trabalhar.
– Poucas empresas possuem especialistas nessa 
área.
– Empresas novas acabam ficando timidas para 
se envolver com esse tipo de pesquisa.
62
Estudo de Caso: patentes
• Convênio Instituto Nacional de 
Propriedade Industrial (INPI) e UFMT
– desenvolvimento de um software 
que auxilie no processo de uso de 
informações de patentes
– software livre
– Versão 1.0 → SGBD Relacional
– Versão 2.0 → NoSQL
63
Estudo de Caso: patentes
• base de patentes do USPTO 
disponibilizados no Google Patentes
– patentes do período de 2005 a 2012 
– arquivos de 500MB cada → 200GB total
– formato XML 
64
Estudo de Caso: patentes
• principais informações
• Classificação internacional, 
• título, 
• resumo, 
• números, 
• datas de publicação e depósito, 
• informações adicionais dos depositantes e 
inventores
65
Ambiente de Programação
Ferramentas
• JDK 1.6
• Maven 3.0.4
– Para build funcional e envio das bibliotecas
– Bibliotecas utilizadas
● Hadoop 0.20
● XStream da Codehaus
● XMLInputFormat do projeto Apache Mahout
• IDE Eclipse
– M2e - Plugin Maven
• IBM Big insights para executar e visualizar os jobs
66
Ambiente de Programação
67
Hadoop Map Reduce Framework
• Exemplo de Uso: Contagem de palavras
• Os passos deste exemplo:
– a implementação de três classes:Map, 
Reduce e GooglePatentWordCount. Esta 
ultima realiza a preparação dos dados e faz a 
chamada das outras duas classes
– gerar um arquivo .jar, que empacota todo o 
código construído, e implantá-lo no ambiente 
Hadoop
68
Hadoop Map Reduce Framework
Contagem de Palavras: 
69
Hadoop Hive
• Utiliza a estrutura do Hadoop.
• Adiciona a funcionalidade de data warehouse ao 
Hadoop.
• Facilita consulta em grande quantidade de dados
– Hive Query Language : Transforma ‘SQL’ em 
MapReduce para fazer buscas.
– Map - Selecão de dados.
– Reduce - Agregação dos dados.
• Pode ser acessado via JDBC.
70
Hadoop Hive
• Estruturas fornecidas para uso
– Databases
– Tables
– Partitions
– Bucket
71
Hadoop: como ETL
• Problema 
– Como armazenar os dados de patentes ?
– Como fazer buscas eficientes nesses dados ?
• Solução 
– Job Hadoop para transformar os dados.
– Apache Hive carrega os dados e fornece Hive QL para consultas.
• Adequar os dados para o Hive
– O formato mais simples é 
– Cada registro se encontra em uma linha do arquivo;
– Os campos estão delimitados por algum caractere especial;
– Isso lembra o formato CSV !!!
• Utilizar a estrutura do Hadoop para processar o grande volume de 
dados de forma paralela.
72
Hadoop: como ETL
• Função Map 
– Transforma o XML para um objeto java.
– Seleciona os dados de interesse.
– Emite todas as representações da patente no formato CSV.
● tabela única com todas as combinações de classificações vs. 
Depositantes.
• Função Reduce
– Não temos agregação.
– Apenas iteramos pelos dados e enviamos para a saída do Job.
• Carregando os dados no Hive
– LOAD DATA INPATH ‘saida_job’ INTO TABLE Patents
73
Hadoop: como ETL
• Conclusão
– Transformação dos dados teve uma 
performance muito boa.
– Utiliza muito bem os recursos do 
cluster.
– Latência das buscas alta pois passa 
por todos os dados.
– Bom para geração de relatórios em 
grande volume de dados.
74
CouchDB e BigCouch
• Características 
– implementado em Erlang 
– modelo de dados baseado em documentos no padrão JSON
● suporte a anexos 
– linguagem Javascript para programação do MapReduce 
– acesso por chamadas Restful. 
– Multi Version Concurrency Control ( MVCC)
– Eventualmente consistente / Basicamente disponível. 
– Baixa latência nas views.
– Consultas e transformações feitas usando Javascript.
– Views desenvolvidas utilizando o paradigma MapReduce.
– Views estáveis e indexadas após cada mudança.
● Utiliza árvores B.
75
CouchDB e BigCouch
• CouchApp
– Web apps rodando diretamente no banco de 
dados.
– Aplicação e banco de dados no mesmo local.
• Integração muito boa com o Apache Lucene.
– Buscas full-text nos documentos.
• Comunidade em alta.
– Discussões.
– Bibliotecas.
76
CouchDB e BigCouch
• Cloudante BigCouch
– Extensão para o CouchDB.
– Permite a configuração do CouchDB em 
forma de cluster.
– Sharding .
– Tolerância a falhas.
– Alta disponibilidade.
– Escalabilidade horizontal
– Abstrai o cluster todo como uma 
instância de CouchDB.
77
CouchDB e BigCouch
Exemplo de uso com patentes: Passos:
• converter os dados para JSON
• inserção dos dados no CouchDB
• construção de consulta
– uso de agregações faz a contagem de patentes e
– as organiza na hierarquia definida pelo padrão da classificação 
internacional de patentes
Ferramentas utilizadas:
– NodeJS para implementação
● biblioteca Cradle para transformação
● biblioteca Node-BufferedReader para carregamento dos arquivos
● biblioteca Node-xml2js
78
CouchDB e BigCouch
Configuração utilizada e funcionamento.
79
CouchDB e BigCouch
● Para armazenar os documentos de 
patentes
– Transformar os XML para JSON.
– Arquivos XML muito grandes.
– Trabalhar com Stream de leitura.
– Armazenar todos os dados.
● Desenvolver um script que popule o 
banco de dados.
80
CouchDB e BigCouch
● Para este exemplo foi usado NodeJS
– Javascript fora do navegador.
● Server-side inclusive.
– “Write less, do more”.
– Trabalhar com XML e JSON é mais ‘natural’.
● Comunidade bastante ativa.
– Encontramos libs para converter XML - JSON.
● Teste comparativo com o Hadoop.
81
CouchDB: workflow do exemplo
82
CouchDB e BigCouch
● Selecionando os dados no 
CouchDB
– Objetivo da consulta
● Classificação internacional.
– Estatística bem interessante por mostrar as áreas 
que estão sendo mais estudadas.
– Criar uma view no CouchDB
● Armazenado em um design document
● Funções de Map e Reduce em javascript.
83
CouchDB: Map()
84
CouchDB: Reduce()
85
CouchDB: agrupamento
86
CouchDB: agrupamento
87
CouchDB: agrupamento
88
CouchDB
● Conclusões
– Transformação dos dados não teve um 
perfomance tão boa.
● Hadoop é melhor para leitura de quantidade 
grande de dados.
– View estáveis, indexadas e de rápido acesso.
– Latência baixa após indexação das views.
– Foi armazenado todo o documento de patente.
89
scidb
Estudo de Caso
90
SciDB
Características
• modelo de dados de Vetor Multidimensional (Array) 
• não utiliza o paradigma MapReduce fornece duas 
interfaces de acesso: 
– AQL (Array Query Language) 
– AFL (Array Functional Language) 
• exemplo de vetor 
– CREATEARRAY clima < dataColeta : datetime, evaporacao : 
float,insolacao : float,precipitacao : float,tempmax : 
float,tempmin : float, umidader el : float, velocidadev ent : 
float > [x = 0 :
100000, 365, 0] 
91
SciDB
● Transações ACID + Versionamento (Append Only)
● Cada instrução AQL ou AFL representa apenas uma 
transação
● Lock em nível de array
● Particionamento baseado em chunking
● Armazenamento local
● Catalogo centralizado
● Shared-nothingarchitecture
● Conector Python, iquery
92
SciDB
● Atributo vs Dimensão
– Facilitar o acesso a um subconjunto de 
dados
– Possibilitar operações algébricas
– Escolha
● Atributos temporais
● Atributos espaciais
93
SciDB: estudo de caso
● Dados ambientais 
– micrometeorologia– estudos desenvolvidos no Programa de Pós-
Graduação em Física Ambiental da UFMT
● www.pgfa.ufmt.br
– torres espalhadas no Estado de MT 
transmitem as informações obtidas por 
sensores
● em tempo real
94
SciDB:estudo de caso
Exemplo de uso com dados ambientais
• Descrição:
– média diária das variáveis → evaporação, insolação, 
precipitação, temperatura máxima, temperatura mínima, 
umidade relativa do ar e velocidade do vento
– captadas em 4 locais diferentes no Estado de MT entre 
os anos de 1985 a 2010. 
• Passos: 
– converter os dados para csv e converter com csv2scidb 
– inserção em dos dados no SciDB 
– construção de um cubo
95
SciDB: arquitetura
Cliente
Postgres
Coordenador
Worker
Worker
Scidb in cluster
Worker
Requisição
Escolhe-se 
um nó worker
Escolhe-se 
um nó worker
Mantem o cluster Este nó irá 
coordenar requisição
Este nó irá 
coordenar requisição
96
SciDB: conceitos
● Banco de dados versional
● Indexação dimensional 
● Armazenamento baseado em array
● Distribuição através de chunks
97
SciDB: carga de dados
Cliente node-1
Envia arquivo
CSV
NFSnode-2 node-3
DATA, PRECIPITACAO
1984-12-01 1.5
1984-12-02 1.1
1984-12-03 1.7
1984-12-04 0.9
98
SciDB: carga de dados
Cliente node-1
Envia arquivo
CSV
Transforma em 
chuncks
NFSnode-2 node-3
Requisita carga
chunk0
chunk1DATA, PRECIPITACAO
1984-12-01 1.5
1984-12-02 1.1
1984-12-03 1.7
1984-12-04 0.9
{0}[
(1984-12-01 1.5),
(1984-12-02 1.1)
]
{1}[
(1984-12-03 1.7)
(1984-12-04 0.9)
]
99
SciDB: agrupamento
Relacional
Scidb
100
SciDB: estudo de caso
● Característica dos dados
– diferença estrutural entre sensores
– organização do conjunto de dados
– falhas de captura
● Volume de dados
101
SciDB: estudo de caso
● Implementação do agrupamento
102
SciDB: operadores
● Operadores matemáticos
● Operadores estruturais
● Operadores manipuladores
103
SciDB: AQL vs AFL
SELECT avg ( S.umidade )
 FROM precipitacao S
 WHERE S.cidade = 'CUIABA'
 GROUP BY S.umidade;
aggregate(
 filter ( precipitacao,
 cidade = 'CUIABA'),
 I,
 avg ( precipitacao.umidade )
);
104
SciDB: estudo de caso
● Precipitação
● EVAPORAÇÃO DO PICHE (mm)
● INSOLACAO (Hs)
● PRECIPITAÇÃO (mm)
● TEMPERATURA MAXIMA (°C)
● TEMPERATURA MINIMA (°C)
● UMIDADE RELATIVA DO AR (%)
● VENTO. VELOCIDADE (m/s)
● Pressão
● PRESSÃO ATMOSFERICA MÉDIA DIÁRIA(hPa)
● TEMPERATURA DO AR - BULBO SECO(°C)
● TEMPERATURA DO AR - BULBO ÚMIDO (°C)
● Vento
● VENTO
● DIREÇÃO (código)
● VENTO, DIREÇÃO (código)
● VENTO, DIREÇÃO (código)
● Cuiabá
● Cáceres
● São Vicente
Região
1984 - 2010
Período
Variáveis
105
SciDB: estudo de caso
(Conjunto de dados)
Valores Classificação Valor
Acima de 30% Aceitável ACEITÁVEL
Entre 20 e 30% Estado de Atenção ATENÇÂO
Entre 12 e 20% Estado de Alerta ALERTA
Abaixo de 12% Estado de emergência EMERGÊNCIA
EVAP. DO 
PICHE
INSOL. PRECIP. TEMP. 
MAXIMA
TEMP. 
MINIMA
UMIDADE 
RELATIVA
VENTO VELOC. (m/s)
1984-12-01 1,5 1,9 5 30,4 23,9 86 0,8
1984-12-02 1,1 0,9 0,4 30,8 22,8 84 1,1
1984-12-03 1,3 1,5 1 28,4 22,6 88 0
Tabela de classificação por umidade relativa
Tabela contendo uma amostra do conjunto de precipitação
106
SciDB: estudo de caso
(Mapeamento temporário)
CREATE ARRAY precipitacao_cuiaba 
< 
data_coleta:datetime
,evap_piche:float
,isolacao:float
,precipitacao:float
,temp_max:float
,temp_min:float
,umidade_rel:float
,velocidade_vent:float
>[x=0:100000,365,0]; 
CREATE ARRAY precipitacao_caceres 
< data_coleta:datetime
,evap_piche:float
,isolacao:float
,precipitacao:float
,temp_max:float
,temp_min:float
,umidade_rel:float
,velocidade_vent:float
>[x=0:100000,365,0]; 
CREATE ARRAY precipitacao_sao_vicente 
< data_coleta:datetime
,evap_piche:float
,isolacao:float
,precipitacao:float
,temp_max:float
,temp_min:float
,umidade_rel:float
,velocidade_vent:float
>[x=0:100000,365,0]; 
Palavra reservada
Atributos
Dimensão
107
SciDB: estudo de caso
(Cubo de precipitação)
CREATE EMPTY ARRAY precipitacao 
<evap_piche:float
,isolacao:float
,precipitacao:float
,temp_max:float
,temp_min:float
,umidade_rel:float
,velocidade_vent:float
>
[ classe_umidade=0:300002,365,0, 
cidade(string)=1000,2,0, 
data_coleta(datetime)=*,100000,0
]; 
108
SciDB: estudo de caso
(Load)
load(precipitacao_caceres, '/home/scidb/carga/precipitacao_caceres.scidb');
REDIMENSION_STORE(
 APPLY(precipitacao_caceres,
 cidade,'CACERES',
 classe_umidade,Iif(umidade_rel > 30,
'ACEITAVEL', Iif(umidade_rel > 20 ,
'ATENCAO',Iif(umidade_rel > 12 ,
'ALERTA',
'EMERGENCIA'
)
)
)
)
,precipitacao
);
109
SGBD: ecossistema atual
110
Sumário
• Introdução 
• Conceitos Relacionados
• Produtos NoSQL
• Considerações Finais
111
Big Data
● Big Data não é a única ferramenta
– É a resposta para tudo?
– Apenas uma grande base de 
dados?
– Rápido para subconjuntos de 
dados?
– Substitutivo para o relacional?
NÃO
112
Big Data
● Volume: além do que o ambiente 
pode manipular
● Velocidade: necessita rápidas 
decisões 
● Variedade: vários formatos
● Variabilidade: múltiplas 
interpretações
113
Big Data
Análise
Dados
Agilidade de Workload
Latência de análise e dados
(real-time, quase real-time)
Complexidade Analítica
Capacidade de Uso Analítica
(predição, estatística avançada, 
mineração de texto/dados)
Complexidade de Workload
Consulta mistas, aquisição e análise 
dos dados concerrente
Volume
Taxa de Acumulação
Volatilidade
Taxa de geração e 
atualização
Variedade
Estruturado, 
Multi-estruturado
Validação
Nível de qualidade
114
Considerações Finais
Onde eu poderia usar um NoSQL database? 
• Você tem um grande conjunto não controlado, não 
estruturado de dados que voce está tentando 
ajustar em um SGBDR? 
– Análise de Logs 
– Feeds de redes sociais 
– Dados que não são facilmente analisados em SGBDR, 
tal como dados em tempo real 
– Grande quantidade de feeds que necessitam ser 
“massageados” antes de serem inseridos no SGBDR 
115
Considerações Finais
• Consistência e os Produtos 
116
Considerações Finais
• Ecossistema SGBD 
117
Considerações Finais
• Ambiente Poliglota
– várias linguagens de programação
– vários produtos de armazenamento
– vários modelos de dados
118
Considerações Finais
• Vantagens NoSQL
– esquema flexível 
– crescimento elástico 
● commodity hardware
– suporte a dados complexos
– diversos modelos de dados
– diversos produtos disponíveis
119
Considerações Finais
• Desvantagens NoSQL
– early adoption vs modismo
– sem padronização
– quebra independência de dados
– programador & DBA
– sem junções
– sem controle de restrições referenciais
– diversos produtos disponíveis * 
120
Considerações Finais
• Tendências
– quem quer o seu?
– incorporação nas plataformas 
tradicionais de SGBD
121
Referências (1)
• SQL vs. NoSQL databases 
– One Size Fits All: An Idea whose Time has Come and Gone. Michael 
Stonebraker and Ugŭr Çetintemel 
http://www.cs.brown.edu/~ugur/fits_all.pdf 
– What Should I do? – Choosing SQL, NoSQL or Both for Scalable Web Apps. 
Todd Hoff: http://voltdb.com/webcast-choosing-sql-nosql-or-both-scalable-
web-apps
– SQL Databases Don’t Scale. Adam Wiggins 
http://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/
– 6 Reasons Why Relational Database Will Be Superseded. Robin Bloor: 
http://www.havemacwillblog.com/2008/11/6-reasons-why-relational-
database-will-be-superseded/
122
Referências (2)
• Introdução e Visão Geral– Scalability, Availability & Stability Patterns. Jonas Bonér: 
http://www.slideshare.net/jboner/scalability-availability-stability-
patterns
– Architecting for the Cloud – Horizontal Scalability via Transient, 
Shardable, Share-Nothing Resources. Adam Wiggins:
– http://www.infoq.com/presentations/Horizontal-Scalability
– Cluster-based scalable network services. Armando Fox, Steven D. 
Gribble, Yatin Chawathe, Eric A. Brewer and Paul Gauthier:
– http://www.cs.berkeley.edu/~brewer/cs262b/TACC.pdf
– NoSQL: Distributed and Scalable Non-Relational Database Systems. 
Jeremy Zawodny: http://www.linux-mag.com/id/7579 
123
Referências (3)
• Teorema CAP, BASE e Consistência Eventual
– Brewer’s CAP Theorem. Julian Browne: 
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 
– Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-
Tolerant Web Services. Seth Gilbert and Nancy Lynch: 
http://www.cs.utsa.edu/~shxu/CS6393-Fall2007/presentation/paper-18.pdf 
– Errors in Database Systems, Eventual Consistency, and the CAP Theorem. 
Michael Stonebraker: http://dx.doi.org/10.1145/1831407.1831411
– BASE: An Acid Alternative. Dan Prichett: http://queue.acm.org/detail.cfm?
id=1394128 
– I love eventual consistency but… James Hamilton: 
http://perspectives.mvdirona.com/2010/02/24/ILoveEventualConsistencyBut
.aspx 
124
Referências (4)
• MapReduce
– A Comparison of Approaches to Large-
Scale Data Analysis. Michael 
Stonebraker, et al.:
– http://database.cs.brown.edu/sigmod09/
benchmarks-sigmod09.pdf 
– MapReduce: A major step backwards. 
David DeWitt: 
http://databasecolumn.vertica.com/data
base-innovation/mapreduce-a-major-
step-backwards 
125
Referências (5)
• Key-Value Stores
– Amazon Dynamo: The Next Generation Of Virtual Distributed 
Storage. Alex Iskold: 
http://www.readwriteweb.com/archives/amazon_dynamo.php 
– Erlang eXchange 2008: Building a Transactional Data Store 
(Scalaris). Alexander Reinefeld: 
http://video.google.com/videoplay?
docid=6981137233069932108 
– Why you won’t be building your killer app on a distributed 
hash table. Jonathan Ellis: 
http://spyced.blogspot.com/2009/05/why-you-wont-be-
building-your-killer.html 
• Document Databases 
– Introducing MongoDB. Eliot Horrowitz: http://www.linux-
mag.com/id/7530 
126
Referências (6)
• Column Stores 
– Distinguishing Two Major Types of Column-Stores. Daniel Abadi: 
http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-
major-types-of_29.html 
– Cassandra – Structured Storage System over a P2P Network. 
Avinash Lakshman, Prashant Malik and Karthik Ranganathan: 
http://www.slideshare.net/jhammerb/data-presentations-
cassandra-sigmod 
– 4 Months with Cassandra, a love story. Cloudkick: 
https://www.cloudkick.com/blog/2010/mar/02/4_months_with_cass
andra 
– Saying Yes To NoSQL; Going Steady With Cassandra At Digg. John 
Quinn: http://about.digg.com/node/564 
– Cassandra: Fact vs fiction. Jonathan Ellis: 
http://spyced.blogspot.com/2010/04/cassandra-fact-vs-
fiction.html 
127
Referências (7)
• Graph Databases 
– Neo4j - A Graph Database That Kicks Buttox. Todd Hoff: 
http://highscalability.com/blog/2009/6/13/neo4j-a-graph-
database-that-kicks-buttox.html 
– Presentation: Graphs & Neo4j => the awesome! Alex 
Popescu: 
http://nosql.mypopescu.com/post/342947902/presentation
-graphs-neo4j-teh-awesome 
– Product: HyperGraphDB – A Graph Database. Todd Hoff: 
http://highscalability.com/blog/2010/1/26/product-
hypergraphdb-a-graph-database.html 
128
Referências (8)
• Desempenho e Comparação de Produtos NoSQL Databases 
– NoSQL Ecosystem. Jonathan Ellis: http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem 
– NoSQL: If only it was that easy. BJ Clark: http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy 
– The end of SQL and relational databases? David Intersimone: 
http://blogs.computerworld.com/15510/the_end_of_sql_and_relational_databases_part_1_of_3
– Performance comparison: key/value stores for language model counts. Brendan O’Connor: 
http://anyall.org/blog/2009/04/performance-comparison-keyvalue-stores-for-language-model-counts 
– MySQL-Memcached or NOSQL Tokyo Tyrant by Matt Yonkovit: 
http://www.mysqlperformanceblog.com/2009/10/15/mysql-memcached-or-nosql-tokyo-tyrant-part- 1/ 
– Redis vs MySQL vs Tokyo Tyrant (on EC2) by Colin Howe: http://colinhowe.wordpress.com/2009/04/27/redis-
vs-mysql/ 
129
Mais Perguntas?
142
Contatos:
Marcos R. Vieira – mvieira@br.ibm.com
Josiel M. de Figueiredo – josiel@ic.ufmt.br
Gustavo Liberatti – liberatti.gustavo@gmail.com
Alvaro F. M. Viebrantz – alvarowolfx@gmail.com
Outubro – 2012 IC - UFMT
	Slide 1
	Sumário
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Escalonamento Vertical (“Scaling Up”)
	Slide 9
	Slide 10
	Introdução
	Slide 12
	Slide 13
	Big Data
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	NoSQL
	NoSQL
	Slide 23
	Teorema CAP
	Slide 25
	Slide 26
	Teorema CAP
	Escalabilidade
	Paradigma MapReduce
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Tipos de Soluções NoSQL
	Tipos de Soluções NoSQL
	Tipos de Soluções NoSQL
	Slide 42
	Tipos de Soluções NoSQL
	NoSQL
	Sumário
	Categorias de NoSQL
	Key-Value Stores
	Column Family (BigTable)
	Document Databases
	Graph Databases
	Slide 51
	Slide 52
	Slide 53
	Hadoop
	Slide 55
	Estudo de Caso
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Ambiente de Programação
	Slide 66
	Hadoop Map Reduce Framework
	Hadoop Map Reduce Framework
	Hadoop Hive
	Slide 70
	Slide 71
	Slide 72
	Slide 73
	CouchDB e BigCouch
	Slide 75
	Slide 76
	CouchDB e BigCouch
	Slide 78
	Slide 79
	Slide 80
	Slide 81
	Slide 82
	Slide 83
	Slide 84
	Slide 85
	Slide 86
	Slide 87
	SciDB
	scidb
	Slide 90
	Slide 91
	Slide 92
	SciDB
	Slide 94
	Slide 95
	Slide 96
	Slide 97
	Slide 98
	Slide 99
	Slide 100
	Slide 101
	Slide 102
	Slide 103
	Slide 104
	Slide 105
	Slide 106
	Slide 107
	Slide 108
	Slide 109
	Sumário
	Considerações Finais
	Slide 112
	Slide 113
	Slide 114
	Considerações Finais
	Considerações Finais
	Considerações Finais
	Considerações Finais
	Considerações Finais
	Considerações Finais
	Slide 121
	Slide 122
	Slide 123
	Slide 124
	Slide 125
	Slide 126
	Slide 127
	Slide 128
	Slide 129
	Slide 142