Modelos NoSQL e a Persistência Poliglota

Modelos NoSQL e a Persistência
Poliglota
(com pitadas de Big Data)
ERDB 2014
Programa de Pós-Graduação em Computação Aplicada
Prof. Orientador: Fabiano Baldo, PhD
Mestrando: Glaucio Scheibel
UNIVERSIDADE DO ESTADO DE SANTA CATARINA-UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS-CCT
v.2

Agenda
• Ser Poliglota
• Big Data
• O Teorema CAP
• ACID x BASE
• NoSQL
• Além do Relacional
• Map-Reduce
• JSON e BSON
• Modelos de dados
NoSQL
– Chave-Valor
– Documento
– Família de colunas
– Grafo

Poliglotismo
• s.m. Característica da pessoa que é poliglota.
Habilidade ou aptidão para falar várias línguas
(idiomas). (Etm. poliglota + ismo)

Programação Poliglota
• Termo criado por Neal Ford em 2006.
• Hoje quando desenvolvemos um projeto, já não
usamos mais apenas uma linguagem.
– SQL na camada de persistência
– Java, C#, Python ou similar na camada de negócio
– HTML e Javascript na camada de apresentação
• “Applications of the future will take advantage of
the polyglot nature of the language world” –
Ford, 2006

Persistência Poliglota
• Similar a Programação Poliglota onde temos
um mix de linguagens, poderíamos também
ter um mix de modelos de dados.
• Diferentes bancos de dados são desenhados
para resolver diferentes problemas. (Sadalage
e Fowler 2013)

RDBMS para todo o Armazenamento
Fonte: Sadalage e Fowler

Persistência Poliglota

Persistência Poliglota SOA

Modelos NoSQL e a Persistência Poliglota

NoSQL e BigData
• NoSQL ≠ BigData
• BigData:
– Quantidade de dados que ultrapassa alguns Terabytes
• Tamanho que necessita mais de um storage.
• Tamanho onde técnicas tradicionais de RDBMS começam a
mostrar sinais de stress.
– Crescimento em 3 V’s
• Velocidade
• Variedade
• Volume

Estatísticas Tweeter (Mar/14)
• Usuários: 1 Bilhão
• Tweets enviados: 300 Bilhões
• Tweets/dia: 500 Milhões
• Usuários ativos/mês: 241 Milhões
• Média seguidores: 208/usuário
• Recorde tweets/seg.: 143.199 em 03/08/2013
Fonte: Digital Marketing Ramblings

Estatísticas Facebook (Mar/14)
• Usuários: 1,26 Bilhões (140 Milhões fakes)
• Usuários ativos/dia: 757 Milhões
• Likes/dia: 4,5 Bilhões
• Fotos/dia: 350 Milhões
• Páginas: 50 Milhões
• Aplicações: 10 Milhões
• Total de Likes: 1,13 Trilhões
• Total de dados: 300 Petabytes

Estatísticas Youtube (Fev/14)
• Usuários: 1 Bilhão
• Visualizações por dia: 4 Bilhões
• Horas por mês: 6 Bilhões
• Qtde de upload/min: 100 Horas de vídeo

Big Data
• De acordo com pesquisa da GigaOM:
– 90% dos dados armazenados no mundo foram
gerados nos 2 últimos anos.
– 80% destes dados não são estruturados.
• Definição em um post de Richard Dale1:
– “Big Data são dados que crescem em volume,
variedade e velocidade acima da Lei de Moore.”
1http://venturecyclist.blogspot.com.br/2012/08/a-better-definition-of-big-data.html

“Hoje, em um único dia, estamos
criando mais dados do que a
humanidade toda criou desde o seu
início até o ano 2000.”
Andreas Weigend / IAB fórum 2013

O que é Big Data?
• É o termo aplicado a dados que não podem ser
processados ou analisados usando processos e
ferramentas tradicionais (Zikopoulos et al., 2012)
• “Big data” is high-volume, -velocity and -variety
information assets that demand cost-effective,
innovative forms of information processing for
enhanced insight and decision making. (Gartner,
2012).

Artigos BigTable e Dynamo
• Google BigTable (2006)
– Modelo família de colunas
– “Internet Scale”
• Web Search: 1.2 milhões de requisições por segundo.
• Google analytics: 200 TB (base) + 20 TB (sumário)
• Google Earth: 70 TB
• Amazon Dynamo (2007)
– Modelo chave-valor
– Amazon’s Always-on Experience
• “Always writable”
• SLA: resposta dentro de 300ms em 99,9% das requisições

Teorema CAP
• N1 e N2 são dois nós na
rede
• Duas bases dados com
valor V0
• Programas A e B
Fonte: Browne, 2010

Execução sem Falha de Rede
Fonte: Browne, 2010

Execução com Falha de Rede
Fonte: Browne, 2010

Sincronização
Fonte: Browne, 2010

Teorema CAP [Brewer]
• Consistency
– Consistência.
– Todos os clientes veem o mesmo dado, mesmo com a
presença de updates.
• Availability
– Disponibilidade.
– Todos os clientes acham uma réplica do dado mesmo na
presença de falhas.
• Partition-tolerance
– tolerante a particionamento
– As propriedades do sistema são mantidas mesmo quando
este é particionado.

Teorema CAP [Brewer]
• Pode-se ter no máximo
duas destas
propriedades para
qualquer sistema de
dados compartilhado.
– Consistência
– Disponibilidade
– Tolerância a partições de
rede.

O Teorema CAP foi Comprovado
• “É impossível no modelo assíncrono de rede
implementar uma leitura / gravação de
objetos de dados que garanta as propriedades
de disponibilidade e consistência atômica em
todas as execuções justas (incluindo aqueles
em que as mensagens são perdidos).” [Gilbert
e Lynch, 2002]

ACID
• Atomicity
– Requer que toda transação seja “Ou tudo ou nada”.
• Consistency
– Uma transação leva a base de dados de um estado
consistente a outro.
• Isolation
– Uma transação não interfere em outra, como
estivessem sendo executadas uma após a outra.
• Durability
– Uma vez “comitada”, as modificações da transação
são mantidas.
Header e Reuter, 1983

BASE (Consistência Eventual)
• Basically Available
– Haverá uma resposta a qualquer requisição.
– O armazenamento parece funcionar a maior parte do
tempo.
• Soft state
– Armazenamentos não tem que ter uma escrita
consistente, nem as réplicas têm de ser coerentes
entre si o tempo todo.
• Eventual consistency
– O sistema, eventualmente, ficará consistente após
parar de receber as entradas de dados.

ACID x BASE
ACID
• Forte consistência
• Isolamento
• Foco no “commit”
• Transações aninhadas
• Disponibilidade?
• Conservador (pessimista)
• Evolução difícil (schema)
BASE
• Consistência fraca
• Disponibilidade é prioridade
• Respostas aproximadas são
OK
• Agressivo (otimista)
• Mais simples!
• Mais rápido
• Evolução fácil
Brewer, 2000

NoSQL
• Termo sugerido por Eric Evans para um encontro em 2009
em San Francisco organizado por Johan Oskarson (last.fm).
– Dava uma boa hashtag no Twitter
• NoSQl é um movimento, não uma tecnologia.
• Não há órgão regulamentador.
• Não há consenso com relação ao significado.
– No SQL
– Not Only SQL
– NOSQL
– no:sql

Definição NoSQL
• É a geração de bancos de dados que possuem
as seguintes características: ser não relacional,
distribuído, open-source e horizontalmente
escalável.
– nosql-database.org

Seis Características NoSQL
1. Capacidade de escalar horizontalmente uma simples
operação através de muitos servidores.
2. Capacidade de replicar e de distribuir os dados ao
longo de muitos servidores (partições).
3. Ter um protocolo ou interface simples de
comunicação (em contraste com SQL).
4. um modelo de concorrência mais fraca do que as
transações ACID.
5. Utilização eficiente dos índices e memória RAM para
o armazenamento de dados distribuídos.
6. Capacidade de adicionar novos atributos
dinamicamente nos registros de dados.
Fonte: Catell, 2011

Agregação
• É uma coleção de dados relacionados que é
tratado como uma unidade.
• É o limite de uma operação ACID / BASE.
• O modelo relacional é considerado aggregate-
ignorant.

Agregação: Modelo Relacional

Além do Relacional
• Da perspectiva de desenvolvimento de
aplicações, bancos de dados relacionais são a
resposta, independentemente da pergunta.
[O’Grady, 2013]

Além do Relacional
• Bancos de dados relacionais são consolidados
e amplamente utilizados, mas...
– Golden Hammer Anti-pattern
• Confiança excessiva na ferramenta favorita.
• Resolver diferentes problemas com uma mesma
ferramenta.
• “I suppose it is tempting, if the only tool you have is a
hammer, to treat everything as if it were a nail.” -
Abraham H. Maslow
– “One size fits all”

Schemaless
• Agilidade e flexibilidade no desenvolvimento e
evolução do software.
• Existe um “Schema Implícito” que é função da
aplicação e não da camada de persistência.
– set “cliente.1.nome” “ABC Transportes”
– set “cliente.2.razao” “XYZ Comercio” // Ops!
Fonte: Sadalage e Fowler, 2012

Agilidade em Software
• Agilidade em software é a capacidade de se
adaptar o software rapidamente às mudanças de
requisitos de negócios.
• Agilidade é fortemente associada tanto a
robustez operacional quanto a produtividade do
desenvolvedor.
• A agilidade é mais do que criar rapidamente
novas aplicações; significa ser capaz de responder
às mudanças de regras de negócio, sem
reescrever o código.
Fonte: McCreary e Kelly, 2013

MapReduce
• É construído sobre o conceito comprovado de
dividir e conquistar: é muito mais rápido quebrar
uma enorme tarefa em pequenos pedaços e
processá-los em paralelo. (Schneider, 2012)
• MapReduce é um modelo de programação
desenhado para processar grandes volumes de
dados em paralelo, dividindo o trabalho em um
conjunto de tarefas independentes. (Wikipedia,
23/04/14)

Map Step
• O nó mestre pega uma entrada, separa em
sub-problemas menores, e os distribui para
nós workers. Um worker pode fazê-lo
novamente, que por sua vez, conduz a uma
estrutura de árvore de múltiplos níveis. O
worker processa esse problema menor, e
passa a resposta de volta para o nó mestre.
Fonte: http://mapreduce.org

Map Step

Reduce Step
• O nó mestre, em seguida, pega as respostas
de todos os sub-problemas e os combina de
forma a obter o resultado, que é a resposta
para o problema original.
Fonte: http://mapreduce.org

Reduce Step

JSON
• JSON (JavaScript Object Notation - Notação de
Objetos JavaScript) é uma formatação leve de
troca de dados.
– Para seres humanos, é fácil de ler e escrever.
– Para máquinas, é fácil de interpretar e gerar.
• Constituído em duas estruturas:
– Uma coleção de pares nome/valor.
– Uma lista ordenada de valores.
Fonte: http://www.json.org

Exemplo JSON
{"widget": {
"debug": "on",
"window": {
"title": "Sample Konfabulator Widget",
"width": 500,
"height": 500
},
"image": {
"src": "Images/Sun.png",
"hOffset": 250,
"vOffset": 250,
"alignment": "center"
},
"text": {
"data": "Click Here",
"size": 36,
"style": "bold",
"name": "text1",
"hOffset": 250,
"vOffset": 100,
"alignment": "center"
}
}}

BSON
• Abreviação de Binary JSON, é a serialização
binária de documentos JSON.
• Vantagens sobre JSON:
– Tipos além do String
• byte, int32, int64, double, boolean, datetime,
timestamp
Fonte: http://bson.org

Modelo Chave-Valor
• Base simples baseada em Tabela Hash.
– Uma tabela de duas colunas: Key, Value
• Key: String, Value: Blob
• Modelo mais simples.

Modelo Chave-Valor
Bucket: coleção de chave-valor no Riak

Ranking Chave-Valor
Fonte: db-engines.com

Prática
• Usar banco chave-valor com Redis
• http://redis.io

Modelo Documento
• Baseados em documentos (xml, json, bson...)
– Não confundir com documentos de texto,
planilhas, etc
• O documento é considerado um todo,
evitando a divisão do dado.
• Forte modelo agregado.

Modelo Documento
JSON
{
"firstname": "Pramod",
"citiesvisited": [
"Chicago",
"London",
"Pune",
"Bangalore"
],
"addresses": [
{
"state": "AK",
"city": "DILLINGHAM",
"type": "R"
}, {
"state": "MH",
"city": "PUNE",
"type": "R"
}
],
"lastcity": "Chicago"
}
XML
<person>
<firstname>Pramod</firstname>
<citiesvisited>
<cityvisited>Chicago</cityvisited>
<cityvisited>London</cityvisited>
<cityvisited>Pune</cityvisited>
<cityvisited>Bangalore</cityvisited>
</citiesvisited>
<addresses>
<address>
<state>AK</state>
<city>DILLINGHAM</city>
<type>R</type>
</address>
<address>
<state>MH</state>
<city>PUNE</city>
<type>R</type>
</address>
</addresses>
<lastcity>Chicago</lastcity>
</person>

Ranking Documento

Ranking Documento XML

Prática
• Usar um banco documento com MongoDB.
• Linguagem JavaScript
• http://www.mongodb.org

Modelo Família de Colunas
• A unidade de informação é a coluna (chave-valor) e um
“registro” é uma família de colunas.
• Coluna:
– Par chave-valor
• Super coluna:
– Array de colunas
• Família de colunas:
– Um container para colunas ordenadas por seus nomes. Família
de colunas são referenciadas e classificadas por rowkeys.
• Família de super colunas:
– Um container para super colunas ordenados por seus nomes.
Famílias como Coluna, Famílias de super coluna são
referenciados e ordenados por rowkeys.
Fonte: http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet

Modelo Família de Colunas
Fonte: Sadalage e Fowler 2012

Coluna

Super Coluna

Família de Colunas

Família de Super Colunas

Ranking Família de Colunas

Prática
• Usar um banco família de colunas com o
Apache Cassandra
• Linguagem CQL
• http://cassandra.apache.org

Modelo em Grafos
• Dados organizados em nós e vértices.
• Modelo onde o foco é o relacionamento.

Busca de Amigos Relacional
• Amigos:
– select distinct uf.* from t_user_friend uf where
uf.user_1 = ?
• Amigos dos Amigos:
– select distinct uf2.* from t_user_friend uf1 inner
join t_user_friend uf2 on uf1.user_1 = uf2.user_2
where uf1.user_1 = ?
• Amigos dos Amigos dos Amigos:
– select distinct uf3.* from t_user_friend uf1 inner
join t_user_friend uf2 on uf1.user_1 = uf2.user_2
inner join t_user_friend uf3 on uf2.user_1 =
uf3.user_2 where uf1.user_1 = ?
Fonte: Partner 2013

Busca de Amigos Grafo
• TraversalDescription traversalDescription
= Traversal.description().
relationships(“IS_FRIEND_OF”,
Direction.OUTGOING).evaluator(Evaluators.a
tDepth(2)).uniqueness(Uniqueness.NODE_GLOB
AL);
• Iterable<Node> nodes =
traversalDescription. traverse(nodeById).
nodes();

Busca de Amigos
• 1.000.000 usuários com 50 amigos
• MySql:
Fonte: Partner 2013

Busca de Amigos
• 1.000.000 usuários com 50 amigos
• Neo4j:
Fonte: Partner 2013

Por que o tempo do Relacional?
• Para encontrar todos os amigos de um usuário
em profundidade 5, um motor de banco de
dados relacional precisa gerar o produto
cartesiano da tabela t_user_friend cinco
vezes. Com 50.000 registros na tabela, o
conjunto resultante terá 50.0005 linhas (102,4
× 1021), o que leva bastante tempo e poder
computacional para calcular. Em seguida,
descartar mais de 99% dos dados, para
retornar apenas 1000 registros!
Fonte: Partner 2013

Por que o tempo do Grafo?
• Devido a estrutura de dados.
• Se alguém lhe perguntar quantas pessoas
estão sentados a 5 metros em torno de você,
você vai se levantar e contá-los. Se o estádio
está meio vazio, você vai contar com as
pessoas ao seu redor tão rápido quanto você
pode contar. Se o estádio está lotado, você
ainda vai fazê-lo em um tempo semelhante.
Fonte: Partner 2013

Ranking Grafos

Prática
• Usar um banco em grafo com o Neo4J
• Linguagem Cypher
• http://www.neo4j.org

Resumo: Big Data
• É o termo aplicado a dados que não podem
ser processados ou analisados usando
processos e ferramentas tradicionais
(Zikopoulos et al., 2012)
• 3 V’s
– Volume
– Variedade
– Velocidade

Resumo: Bancos NoSQL
• Open-Source
– Movimento
• Roda em computadores
“commodity”.
– Baixo custo.
• Criado para clusters.
– Adição e remoção de nós
sem impacto na operação.
• Consistência eventual.
– BASE invés de ACID
• Não utiliza SQL
• Schemaless
– Flexibilidade
– Produtividade
• Versionamento no lugar
de atualização de dados.
– Timestamp
• Sem transação de
múltiplas chaves.
• Suporte ao BigData.

Referências
• BANKER, Kyle. MongoDB in action. Manning
Publications Co., 2011.
• BEYER, Mark A.; LANEY, Douglas. The Importance of
‘Big Data’: A Definition. Stamford, CT: Gartner, 2012.
• BREWER, Eric A. Towards robust distributed systems.
In: PODC. 2000. p. 7.
• BROWNE, Julian. Brewer’s CAP Theorem-The kool aid
Amazon and Ebay have been drinking. 2010.
• CATTELL, Rick. Scalable SQL and NoSQL data
stores. ACM SIGMOD Record, v. 39, n. 4, p. 12-27,
2011.

Referências
• CHANG, Fay et al. Bigtable: A distributed storage
system for structured data. ACM Transactions on
Computer Systems (TOCS), v. 26, n. 2, p. 4, 2008.
• COOPER, Brian F. et al. PNUTS: Yahoo!'s hosted data
serving platform. Proceedings of the VLDB
Endowment, v. 1, n. 2, p. 1277-1288, 2008.
• DECANDIA, Giuseppe et al. Dynamo: amazon's highly
available key-value store. In: SOSP. 2007. p. 205-220.
• ELMASRI, Ramez; NAVATHE, Shamkant B.; DE OLIVEIRA
MORAIS, Rinaldo. Sistemas de banco de dados. 2005.

Referências
• FORD, Neal. Polyglot programming. 2006.
• GILBERT, Seth; LYNCH, Nancy. Brewer's conjecture and the
feasibility of consistent, available, partition-tolerant web
services. ACM SIGACT News, v. 33, n. 2, p. 51-59, 2002.
• HAERDER, Theo; REUTER, Andreas. Principles of
transaction-oriented database recovery. ACM Computing
Surveys (CSUR), v. 15, n. 4, p. 287-317, 1983.
• LANEY, Douglas. 3-D Data Management: Controlling Data
Volume, Velocity and Variety. META Group Research Note,
February, v. 6, 2001.
• MADDEN, Sam. From databases to big data. Internet
Computing, IEEE, v. 16, n. 3, p. 4-6, 2012.

Referências
• McCREARY, Dan; KELLY, Ann. Making Sense of
NoSQL: A guide for managers and the rest of us.
Manning Publications Co.. 2013
• MÜLLER, Stephan. The CAP-Theorem & Yahoo’s
PNUTS. 2012.
• O'GRADY, Stephen. The New Kingmakers. O'Reilly
Media, 2013.
• PARTNER, Jonas. Neo4j in Action. Manning
Publications Co., 2013.
• PRITCHETT, Dan. Base: An acid alternative.
Queue, v. 6, n. 3, p. 48-55, 2008.

Referências
• ROBINSON, Ian; WEBBER, J.; EIFREM, E. Graph
Databases. O'Reilly Media, 2013.
• SADALAGE, Pramod J.; FOWLER, Martin. NoSQL
distilled: a brief guide to the emerging world of
polyglot persistence. Addison-Wesley, 2012.
• TIWARI, Shashank. Professional NoSQL. John
Wiley & Sons, 2011.
• VOGELS, Werner. Eventually
consistent. Communications of the ACM, v. 52, n.
1, p. 40-44, 2009.

Referências
• VOGELS, Werner. Eventually consistent -
revisited. 2008-12-22. http://www.
allthingsdistributed.
com/2008/12/eventually_consistent. html,
2008.

Modelos NoSQL e a Persistência Poliglota

Mais conteúdo relacionado

Modelos NoSQL e a Persistência Poliglota