INTRODUÇÃO A BANCO DE DADOS

NÃO RELACIONAIS

Prof.: Ricardo da Silva Torres

rtorres@ic.unicamp.br
www.ic.unicamp.br/~rtorres
INF-0325 Maio de 2019
 Agradecimentos
2

◻ Prof. Julio Reis

 Objetivos da aula
3

◻ Aprender conceitos básicos de Recuperação de

Informação

◻ Aprender os conceitos básicos em banco de dados

não relacionais

◻ Estudar uma visão geral dos principais modelos

noSQL
 Modelos de banco de dados
4

◻ Maneira lógica de estruturar os dados da

aplicação

◻ Modelo determina como sistemas de banco de

dados manipulam informações

◻ Banco de dados relacionais é um dos mais

populares
 Qualidade dos bancos relacionais
5

◻ Persistência consistente
◻ Integração de dados
◻ Controle de transações
◻ Controle de concorrência
◻ Segurança e alta confiabilidade
◻ Linguagem de consulta eficaz e eficiente
SQL
 Aplicações de software modernas
6

◻ Criam volume de dados massivos com tipo de

dados de mudam rapidamente
(não) estruturados, semi-estruturados, e “dados
polimórficos” (complexos)

◻ Não há mais longos ciclos de desenvolvimento em

cascata
Pequenos times trabalham em sprints ágeis
Interação rápida para a geração de código
semanalmente (ou mesmo diário)
 Aplicações de software modernas
7

◻ Aplicações não mais criadas para uma audiência

finita e bem delimitada
Implantadas como serviço
■ Acessível 100% online para muitos dispositivos
■ Escalável para milhões de usuários

◻ Organizações indo em direção a arquiteturas

escaláveis de software de código aberto
Computação em nuvem
 BIG DATA!!
8

https://commons.wikimedia.org/wiki/File:BigData_2267x1146_white.png (As of May 2018).

 BIG DATA!!
9

◻ Grande volume de dados

CLUSTERS!!
■ Volume e processamento

◻ Trilhões de transações

◻ Internet das coisas

Objetos conectados e persistindo dados todo o tempo
 BIG DATA!!
10

◻ Grande volume de dados

CLUSTERS!!
■ Volume e processamento

◻ Trilhões de transações

◻ Internet das coisas

Objetos conectados e persistindo dados todo o tempo

◻ Como consultar e “navegar” facilmente nos dados?

Como detectar relações (associações) não triviais?
 BIG DATA!!
11

Wu, Caesar & Buyya, Rajkumar & Ramamohanarao, Kotagiri. (2016). Big Data Analytics
= Machine Learning + Cloud Computing.
 BIG DATA: Sistemas Inteligentes
12

Wu, Caesar & Buyya, Rajkumar & Ramamohanarao, Kotagiri. (2016). Big Data Analytics
= Machine Learning + Cloud Computing.
 Aprendizado Supervisionado
13

Wu, Caesar & Buyya, Rajkumar & Ramamohanarao, Kotagiri. (2016). Big Data Analytics
= Machine Learning + Cloud Computing.
 Aprendizado Não-Supervisionado
14

Wu, Caesar & Buyya, Rajkumar & Ramamohanarao, Kotagiri. (2016). Big Data Analytics
= Machine Learning + Cloud Computing.
 Limitações dos bancos relacionais
15

◻ Não foram projetados visando

Lidar com os desafios de escalabilidade e agilidade de
aplicações modernas
Tirar proveito do poder de processamento atual

◻ Colunas/tuplas são limitadas a tipos de dados

simples

◻ Estruturas mais complexas não “encaixam”

naturalmente no modelo relacional
 Limitações dos bancos relacionais
16

◻ Problema de escalabilidade

◻ Servidores maiores implicam alto custo

◻ Clusters tendem a perder eficiência em SGBDRs

◻ Projetados para funcionar em um único nó

 Limitações de consultas em BD relacional
17

◻ Análise de dados comprometida

Combinação de muitos joins diminuiu efetividade das
consultas

◻ Necessários meios de permitir consultas mais

refinadas com menor complexidade computacional
Melhor recuperação/análise dos dados
■ encontrar relações “não explícitas”
Recuperar dados com consultas menos complexas
 Banco de dados não relacionais
18

◻ Tecnologia criada para responder às demandas na

construção de aplicações modernas
Não explora modelo relacional!

◻ Não utiliza SQL como DDL/DML

◻ Desenvolvido para lidar com as limitações de banco de

dados SQL

◻ Não tem uma maneira comum de consultar os dados

(“Not only SQL”)
 Bancos de Dados NoSQL
19
 Bancos de Dados NoSQL
20
 Características
21

◻ Não relacional (metamodelo de dados)

◻ Movimento Open Source

◻ Persistência “poliglota”
 Benefícios: Schema flexível
22

◻ BDs relacionais requerem que o schema seja

definido de antemão
Não adequado para desenvolvimento ágil
Modificação constante do schema (avanços rápidos)

◻ Se a base é grande então isso é altamente custoso

 Benefícios: Schema flexível
23

◻ “Schemaless”
Esquema implícito ou flexível

◻ Bases NoSQL são construídos para permitir inserção

de dados sem um schema totalmente pré-definido
Mudanças na aplicação em tempo real, sem se
preocupar com interrupções de serviço
 Benefício: Escalabilidade
24

◻ BDs relacionais escalam verticalmente

Um único servidor precisa hospedar o BD inteiro para
garantir um desempenho aceitável para junções e
transações entre tabelas

◻ BDs relacionais em múltiplos servidores aumenta

complexidade para fazer o hardware agir como
um único servidor
 Benefício: Escalabilidade
25

◻ BDs relacionais escalam verticalmente

Um único servidor precisa hospedar o BD inteiro para
garantir um desempenho aceitável para junções e
transações entre tabelas
◻ BDs relacionais em múltiplos servidores aumenta
complexidade para fazer o hardware agir como
um único servidor
◻ NoSQL é “Cluster-friendly”
Distribuição de dados e consistência em diversos nós
 Benefício: Escalabilidade
26

◻ Bases noSQL distribuem dados nativamente e

automaticamente por um número arbitrário de
servidores
Não exige que o aplicativo esteja ciente da composição
dos servidores
 Benefício: Escalabilidade
27

◻ Bases noSQL distribuem dados nativamente e

automaticamente por um número arbitrário de
servidores
Não exige que o aplicativo esteja ciente da composição
dos servidores

◻ Carregamento de dados e consultas é balanceado

automaticamente entre os servidores
Quando um servidor fica inativo, ele pode ser substituído
de forma rápida e transparente, sem interrupção do
aplicativo (uso de computação em nuvem)
 Benefícios: Performance
28

◻ Sistema de cache em BDs relacionais podem

aprimorar a performance de leituras
Mas não melhoram o desempenho de gravação
Adicionam complexidade operacional às implantações
do sistema
 Benefícios: Performance
29

◻ Tecnologias noSQL apresentam funcionalidades

para lidar com sistema de caches integrados
Mantêm dados frequentemente usados em memória o
máximo possível
 Benefícios: Performance
30

◻ Tecnologias noSQL apresentam funcionalidades

para lidar com sistema de caches integrados
Mantêm dados frequentemente usados em memória o
máximo possível

◻ Oferecem uma camada de gerenciamento de

banco de dados integrada na memória
Totalmente gerenciada para cargas de trabalho que
exigem maior throughput
 Benefícios: Replicação
31

◻ Suporte à replicação automática de banco de dados

Manter a disponibilidade em caso de interrupções ou
eventos de manutenção planejados

◻ Oferecem tratamento de erros e recuperação

automatizados
 Benefícios: Replicação
32

◻ Suporte à replicação automática de banco de dados

Manter a disponibilidade em caso de interrupções ou
eventos de manutenção planejados

◻ Oferecem tratamento de erros e recuperação

automatizados

◻ Capacidade de distribuir o banco de dados em

várias regiões geográficas para resistir a falhas
regionais e permitir a localização de dados
 Síntese Relacional vs. NoSQL
33
Relacional NoSQL
Tipos Um apenas (SQL) Diversos
Exemplos MySQL, Postgres, MongoDB,
Microsoft SQL Server, Cassandra, HBase,
Oracle Neo4j
Modelo Registros individuais Diferente com base
armazenamento como tuplas em tabelas no modelo
Schemas Estrutura e tipo de dados dinâmico, com
fixados a priori algumas regras de
validação de dados.
Aplicativos podem
adicionar novos
campos rapidamente
 Síntese Relacional vs. NoSQL
34

Relacional NoSQL
Escalabilidade Vertical usualmente com Horizontalmente,
base em único servidor administrador de BD pode
adicionar mais servidores
ou instâncias de nuvem
Modelo de Mistura de código aberto e Código aberto
desenvolvimento fechado
Manipulação dados Linguagem específica API orientada a objetos
usando as instruções
Selecionar, Inserir e
Atualizar
Consistência Pode ser configurado com Alguns SGBDs oferecem
alta consistência outros não
 (Meta)modelos
35

◻ Chave-Valor

◻ Documentos

◻ Família de Colunas

◻ Grafos
 Modelos agregados???
36

◻ Unidades/estruturas de dados mais complexas

◻ Domain-Driven Design
◻ Operações atômicas
◻ Comunicação com banco em termos de unidades
agregadas
◻ Replicação e particionamento em nível de unidade
◻ Abstração mais natural para as linguagens de
programação
37

Visão geral dos modelos

 Schema relacional de exemplo
38

1 *
Brands Models
 Schema relacional de exemplo
39
 Visão geral dos modelos
40

◻ Chave-Valor

◻ Documentos

◻ Família de Colunas

◻ Grafos
 Lembrando tabelas de espalhamento
41
 Modelo chave-valor
42

◻ Composto por uma coleção de pares de elementos

Cada par consiste de uma chave, que é única e
identifica o par, e um valor associado a essa chave
 Modelo chave-valor
43

◻ Composto por uma coleção de pares de elementos

Cada par consiste de uma chave, que é única e
identifica o par, e um valor associado a essa chave

Chave 1 valor

Chave 2 valor

Chave 3 valor

Chave 4 valor
 Modelo chave-valor
44

◻ Composto por uma coleção de pares de elementos

Cada par consiste de uma chave, que é única e
identifica o par, e um valor associado a essa chave
Cadeia de
Chave 1 valor
caracteres

Lista de
Chave 2 valor itens

Tabela de
Chave 3 valor espalhamento
(campo, valor)

Chave 4 valor
 Exemplo (do carro)
45

(identificador)
chave

valor
 Casos apropriados para uso
46

◻ Armazenar informações que necessitem de rápido

acesso

◻ Dados que serão descartados em breve por possuir

um tempo de vida curto
Lista de itens (carrinho de compra)
 Restrições
47

◻ Realizar junção entre os dados

◻ Não é recomendado quando é necessário

representar relacionamentos entre diferentes
conjuntos de dados

◻ Limitado para processar transações com múltiplas

operações ou quando se deseja realizar consultas
complexas com múltiplas condições
 Operação de inserção
48

◻ Inserção de dados simples (chave valor)

SET chave valor
■ SET ano 2018

◻ Inserção de coleção de dados

HSET chave campo1 valor1
HSET chave campo2 valor2
■ HSET 044488 nome Joao da Silva
■ HSET 044488 email joao@unicamp.br
 Operação de remoção
49

◻ Exclusão de chave
DEL chave
■ DEL 044488

◻ Exclusão de um campo
HDEL chave campo
■ HDEL 044488 nome
 Operação de consulta
50

◻ Consulta (busca sempre pela chave)

GET ano
■ Recupera valor da chave ano

HGET 044488 nome

■ Recupera o valor do campo nome da chave 044488

HGETALL 044488
■ Recupera todos os campos da tabela associada à chave
044488
 SGBDs chave-valor
51

◻ Amazon DynamoDB

◻ Redis
 Visão geral dos modelos
52

◻ Chave-Valor

◻ Documentos

◻ Família de Colunas

◻ Grafos
 Modelo de documentos
53

◻ Base de dados é uma coleção de documentos

◻ Chave (com identificador único) associada a uma

estrutura de dados complexa (documento)

◻ Cada documento é um objeto de dados

Um ou mais campos com tipo de valor
Pode conter diferentes campos
Documentos aninhados

◻ Especialização do modelo chave-valor

 Exemplo (do carro)
54

documento
Coleção de
documentos

Identificador Pode armazenar relação

do documento com Brands

atributos
 Características do modelo
55

◻ Não depende de um esquema rígido

Não obriga uma estrutura fixa como ocorre nos bancos
relacionais

◻ Documento tem formato livre

Permite que ocorra uma atualização na estrutura do
documento, adicionando novos campos

◻ Melhor acoplamento com dados modelados com

orientação a objetos
 Características do modelo
56

◻ Desnormalização
Armazenando de dados redundantes para otimizar o
armazenamento e consulta

◻ Ligações entre diferentes documentos (semelhante à

chave estrangeira em BDs relacionais)
Facilitar as consultas
Não são verificadas pelo SGBD
 Exemplo de implementação
57

◻ Formato JSON (JavaScript Object Notation)

{
'_id' : 1,
‘nome' : ‘João’
}

documento
 Exemplo de implementação
58

◻ Formato JSON (JavaScript Object Notation)

{
'_id' : 1, campo : valor objeto
‘nome’ : ‘João’,
‘endereço’ : { ‘rua' : ‘da liberdade', ‘cep' : ‘130000' }
}
 Exemplo de implementação
59

◻ Formato JSON (JavaScript Object Notation)

{
'_id' : 1,
‘nome’ : ‘João’, vetor
‘endereço’ : { ‘rua' : ‘da liberdade', ‘cep' : ‘130000’ },
‘atividades' : [ ‘pedreiro', ‘pintor', ‘encanador' ]
}
 Exemplo de implementação
60

◻ Formato JSON (JavaScript Object Notation)

{
“_id” : 1,
“nome” : “João”,
“endereço” : { “rua” : “da Liberdade”, “cep” : “130000” },
“atividades” : [ “pedreiro”, “pintor”, “encanador” ],
“obras” : aninhamentos
[
}
 Exemplo de implementação
61

◻ Formato JSON (JavaScript Object Notation)

{
'_id' : 1,
‘nome’ : ‘João’,
‘endereço’ : { ‘rua' : ‘da liberdade', ‘cep' : ‘130000’ },
‘atividades' : [ ‘pedreiro', ‘pintor', ‘encanador’ ],
‘obras’ :
[
{ “ipo” : “sobrado”, “ano” : 2013 },
{ “tipo” : “casa térrea”, “ano” : 2015 }
]
}
 Exemplo de implementação
62

◻ Formato JSON (JavaScript Object Notation)

{
'_id' : 1,
‘nome’ : ‘João’,
‘endereço’ : { ‘rua' : ‘da liberdade', ‘cep' : ‘130000’ },
‘atividades' : [ ‘pedreiro', ‘pintor', ‘encanador’ ],
‘obras’ :
[
{ “ipo” : “sobrado”, “ano” : 2013 },
{ “tipo” : “casa térrea”, “ano” : 2015 }
]
}
 Casos de uso e restrições
63

◻ Flexível suficientemente para atender aplicações

em geral
◻ Não recomendado quando for necessário ter
transações complexas entre múltiplos documentos
 Casos de uso e restrições
64

◻ Flexível suficientemente para atender aplicações

em geral
◻ Não recomendado quando for necessário ter
transações complexas entre múltiplos documentos

◻ Não adequado para situações quando é necessário

impor um esquema muito rígido de consistência
Não trata redundância com rigor
 Algumas operações
65

◻ Inserção de dados simples

db.Employee.insert ( { "Employeeid" : 1, "EmployeeName" :
"Martin" } )

◻ Atualização
db.Employee.update( {"Employeeid" : 1}, {$set: {
"EmployeeName" : "NewMartin"}});
 Algumas operações
66

◻ Inserção de dados simples

db.Employee.insert ( { "Employeeid" : 1, "EmployeeName" :
"Martin" } )
◻ Atualização
db.Employee.update( {"Employeeid" : 1}, {$set: {
"EmployeeName" : "NewMartin"}});
◻ Remoção
db.Employee.remove({Employeeid:22})
◻ Consulta (busca por qualquer parte do documento)
db.Employee.find({EmployeeName : "Smith"})
 SGBDs orientado a documentos
67

◻ MongoDB (veremos na próxima aula) 

◻ SimpleDB

◻ CouchDB
 Visão geral dos modelos
68

◻ Documentos

◻ Chave-Valor

◻ Família de Colunas

◻ Grafos
 Modelo orientado a colunas
69

◻ Banco é uma coleção de família de colunas

Uma família de colunas é composta por linhas que
possuem uma chave e múltiplas colunas

chave
 Modelo orientado a colunas
70

◻ Banco é uma coleção de família de colunas

Uma família de colunas é composta por linhas que
possuem uma chave e múltiplas colunas
Cada uma das colunas associadas a uma linha consiste
de um par chave-valor e um registro temporal
colunas

Estrutura tabular
Colunas esparsas
Agregado em dois níveis
 Família de colunas
71

Super column name name

value

Cada linha pode ter um conjunto de colunas diferentes

 Exemplo (do carro)
72
 Implementando família de colunas
73

◻ Coluna
{
name: "fullName",
value: "Martin Fowler",
timestamp: 09062018
}
 Implementando família de colunas
74

◻ Família de colunas
//row
"pramod-sadalage" : {
firstName: "Pramod",
lastName: "Sadalage",
lastVisit: "2012/12/12"
}
 Implementando família de colunas
75

◻ Famílias de colunas
{
//row 1
"pramod-sadalage" : { Chave da linha
firstName: "Pramod",
coluna
lastName: "Sadalage",
lastVisit: "2012/12/12"
}

//row 2
"martin-fowler" : {
firstName: "Martin",
lastName: "Fowler",
location: "Boston"
}
}
 Super família de colunas
76

Container de colunas
 Super família de colunas
77

{ //row 1
Chave da linha
name: "billing:martin-fowler",
value: {
address: { Super coluna
name: "address:default",
value: {
coluna
fullName: "Martin Fowler",
street:"100 N. Main Street",
zip: "20145"
}
},
billing: { Super coluna
name: "billing:default",
value: { coluna
creditcard: "8888-8888-8888-8888",
expDate: "12/2016"
}
}
} //finaliza row 1
 Características
78

◻ Surgiu associado ao sistema BigTable criado pelo

Google

◻ Não suporta consultas com junção (joins) entre

diferentes famílias de colunas
Necessário armazenar os dados de forma redundante para
garantir a escalabilidade
 Casos de uso
79

◻ Aplicações com grande volume de dados

Ideal para dados que expiram após um período por
possuir o recurso de timestamp nativo

◻ Aplicações que necessitem particionar os dados em

grandes clusters de computadores
 Restrições
80

◻ Processar operações de agregações

◻ Processar consultas dinâmicas

◻ Modelo não adequado quando não há certeza

sobre os padrões de consulta
Pode ser necessário alterar o formato das famílias de
colunas para atender as consultas.
 Operação de criação da familia
81

CREATE TABLE familia (coluna1 tipo_de_dados, coluna2

tipo_de_dados)

CREATE TABLE clientes (

id text PRIMARY KEY,
idade int,
status text,
telefones map<text,text>
);
 Operação de inserção
82

INSERT INTO familia

VALUE (campo1, campo2, campoMap
{'chave1':'valor1','chave2':'valor2’})

INSERT INTO
clientes (id, idade, status, telefones)
VALUES("Joao", 45, "A" ,
{ 'Comercial':'3973512” , 'Celular':'9951231'})
 Operação de atualização
83

UPDATE familia_de_colunas
SET coluna = valor
WHERE condição

UPDATE clientes
SET status = "C"
WHERE id=1
 Operação de recuperação
84

SELECT colunas
FROM familia_de_coluna
WHERE condição

SELECT id, status

FROM clientes
WHERE id=1 and status=“A”
 Operação de remoção
85

DELETE FROM familia_de_coluna

WHERE condição

DELETE FROM clientes

WHERE id=1
 SGBDs orientada a colunas
86

◻ Google BigTable

◻ Hadoop / HBase

◻ Cassandra
 Visão geral dos modelos
87

◻ Documentos

◻ Chave-Valor

◻ Família de Colunas

◻ Grafos
 Conceito de grafo
88

vértice
 Conceito de grafo
89

aresta
 Modelo de BD orientado a grafos
90

◻ Vértice pode ter um

rótulo

◻ Vértices e arestas
possuem propriedades

◻ Arestas são direcionais

 Exemplo
91
 Exemplo
92
 Exemplo de consulta
93

◻ Recupere todos os registros (nós) que gostam de

NoSQL Distilled
 Exemplo de consulta
94

◻ Recupere todos os registros (nós) que gostam de

NoSQL Distilled
 Exemplo de consulta
95

◻ Recupere todos os registros empregados por BigCo

e que gostam de NoSQL Distilled
 Exemplo de consulta
96

◻ Recupere todos os registros empregados por BigCo

e que gostam de NoSQL Distilled
 Modelo orientado a grafos
97

◻ Cada nó é um registro, que pode possuir atributos

◻ Os relacionamentos podem guardar informações
também
registro

relacionamento
 Schema relacional de exemplo
98
 Exemplo (do carro)
99

2_corcel
tem_marca

Nome=Corcel
prod_begin=1968 1_ford
prod_end=1986

Nome=Ford
Country=USA
Founded=1903
 Casos possíveis de uso
100

◻ Dados conectados em múltiplos níveis que requerem

buscas dinâmicas
Permite agilidade na recuperação de dados

◻ Consultas complexas
Explora uma sequência de relacionamentos que é
resolvida com o percurso de múltiplos níveis do grafo
 SGBDs orientada a grafos
101

◻ Neo4J (veremos em aula futura) 

◻ Giraph

◻ ArangoDB (multimodelo)

◻ Infinite Graph
 Síntese da aula
102

◻ Modelos NoSQL proveem flexibilidade no schema

Relevantes para aplicações de software modernas
SGBDs relacionais ainda dominam o mercado
 Síntese da aula
103

◻ Modelos NoSQL proveem flexibilidade no schema

Relevantes para aplicações de software modernas
SGBDs relacionais ainda dominam o mercado

◻ 4 principais modelos (chave-valor, coluna de

famílias, documentos, grafos)
Chave-valor e coluna de famílias permitem consultas
principalmente pelas chaves
Orientado a documentos tem maior aplicabilidade
(mapeia-se mais diretamente com OO)
Grafos permitem consultas mais dinâmicas
104

Exercícios
 Exercício 1
105

◻ Quais são as características compartilhadas por

bases de dados noSQL?
 Exercício 2
106

◻ Explique os benefícios de banco de dados não

relacionais
 Exercício 3
107

◻ Explique os casos mais adequados de uso para

cada tipo de modelo não relacional e suas
restrições
 Exercício 4
108

◻ Explique qual modelo de BD usaria nas seguintes

situações e por quê
a) Calcular a média dos salários de funcionários
b) Construir um carrinho de compras
c) Armazenar informações estruturas de produtos
d) Encontrar como um usuário foi de um ponto A para
um ponto B
 Exercício 5
109

◻ Para um sistema de cadastro de produtos (imagine

os dados que produtos precisam armazenar)
a) Exemplifique como os dados podem ser persistidos
em um modelo orientado a colunas (crie as operações
com CQL)

b) Exemplifique como os dados podem ser persistidos

em um modelo orientado a documentos (apresente um
exemplo de implementação em JSON)
 Referências
110

1. Pramod J. Sadalage, Martin Fowler. NoSQL

Distilled: A Brief Guide to the Emerging World of
Polyglot Persistence. Pearson Education, Inc,
2013, ISBN 978-0-321-82662-6
 Referências
111

Parte dos slides são baseados em trabalho de Keith W. Hare (“A Comparison of
SQL and NoSQL Databases”)
■ Metadata Open Forum
■ Leituras Adicionais: http://martinfowler.com/articles/nosqlKeyPoints.html
“NoSQL -- Your Ultimate Guide to the Non - Relational Universe!”
■ http://nosql-database.org/links.html
“NoSQL (RDBMS)”
■ http://en.wikipedia.org/wiki/NoSQL
PODC Keynote, July 19, 2000. Towards Robust. Distributed Systems.
Dr. Eric A. Brewer. Professor, UC Berkeley. Co-Founder & Chief
Scientist, Inktomi .
■ www.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
■ “Brewer's CAP Theorem” posted by Julian Browne, January 11, 2009.
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
“How to write a CV” Geek & Poke Cartoon
http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html
 Referências
112

“Exploring CouchDB: A document-oriented database for Web applications”, Joe

Lennon, Software developer, Core International.
■ http://www.ibm.com/developerworks/opensource/library/os-couchdb/index
.html
“Graph Databases, NOSQL and Neo4j” Posted by Peter Neubauer on May 12,
2010 at:
■ http://www.infoq.com/articles/graph-nosql-neo4j
“Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison”,
Kristóf Kovács.
■ http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
“Distinguishing Two Major Types of Column-Stores” Posted by Daniel Abadi
onMarch 29, 2010
■ http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-
of_29.html
 Referências
113

“MapReduce: Simplified Data Processing on Large Clusters”, Jeffrey Dean and

Sanjay Ghemawat, December 2004.
■ http://labs.google.com/papers/mapreduce.html
“Scalable SQL”, ACM Queue, Michael Rys, April 19, 2011
■ http://queue.acm.org/detail.cfm?id=1971597
“a practical guide to noSQL”, Posted by Denise Miura on March 17, 2011 at
■ http://blogs.marklogic.com/2011/03/17/a-practical-guide-to-nosql/
114

Tarefa de Casa
 Descrição
115

◻ Pesquisa e descreva sobre “persistência poliglota”

O que significa?
Quais são as motivações de uso?
Explique um contexto de exemplo de uso?
Quais são os desafios?
Há suporte de gerenciadores NoSQL? Se sim, como?
◻ Instruções
Em dupla
Entrega: 25/05/2019
Duas 2 páginas completas (indicar referências)