1
Banco de DadosBanco de Dados
na Nuvemna Nuvem
Natal/RN
2014
Pós-graduação em Arquitetura de Nuvem
Prof.Marcos Luiz Lins
Filho
2
Agenda
2
1 Dia (10/12)ᵒ – Histórico, evolução e conceitos
dos Bancos de Dados NoSQL
2 Dia (11/12)ᵒ – BD em Grafos com Neo4J
3 Dia (12/12)ᵒ – AWS e BDs na Nuvem
4 Dia (13/12)ᵒ – Apresentação de trabalhos
3
Agenda
3
4
Motivação
4
 Contexto
 BD relacionais são o padrão quase SEMPRE;
 A escolha é qual o BD relacional usar;
 BD relacionais ameaçados pelos BD OO na década de 90, mas não vingou;
 Porque os BD OOs não decolaram?
 BD Relacionais de volta ao DOMINIO ABSOLUTO
 Depois de longo tempo de DOMÍNIO, surge nova ameaça BDs NoSQL;
 Na verdade não é ameaça, é alternativa;
 O que os BDs NoSQL tem de diferente dos BD OOs para decolar?
Fonte: FOWLER e SADALAGE, 2013.
55
 Memória Principal x Memória Secundária
 Armazenamento secundário
 Arquivos
 Banco de Dados
 BD = Flexibilidade
 Recuperação de parte do todo de forma rápida e fácil
 Concorrência (conceito de transações)
 Integração(Relação:Um para muitos - BD x Aplicações)
Histórico dos BDs Relacionais
Fonte: FOWLER e SADALAGE, 2013.
66
 Por que BDs Relacionais foram bem sucedidos?
 Flexibilidade, Concorrência, Integração com padronização
 Aprende um MODELO, aplica a vários projetos
Histórico dos BDs Relacionais
Fonte: FOWLER e SADALAGE, 2013.
77
 O que é isso ?
Incompatibilidade de Impedância
Fonte: BARRY, Douglas K.
Modelo Relacional
(tuplas e relações)
Estruturas de Dados
(Listas, pilhas, árvores etc)
88
 Se tornou mais aparente com o avanço da programação OO;
 Causa de grande frustração dos desenvolvedores OO;
 Forte Limitação dos BDs Relacionais ;
 Fez emergir os BDs OOs;
 No final tivemos:
 Linguagens OO se tornaram mais e mais fortes;
 BDs OO sucumbiram
 BDs Relacionais se fortaleceram amparados no suporte a SQL como
linguagem padrão de manipulação de dados;
 Divisão profissional entre desenvolvedores e DBAs;
 Surgimento de frameworks de mapeamento objeto-relacional (Ex.
Hibernate)
Incompatibilidade de Impedância
Fonte: FOWLER e SADALAGE, 2013.
99
Incompatibilidade de Impedância
Fonte: FOWLER e SADALAGE, 2013.
OO to Relacional
Relacional to OO
O PROBLEMA DO MAPEAMENTO
1010
BDs x Orientação a Serviços
Fonte: FOWLER e SADALAGE, 2013.
SQL
BD
INTEGRAÇÃO
1111
BDs x Orientação a Serviços
Fonte: FOWLER e SADALAGE, 2013.
SQL
BD
APLICATIVO
1212
BDs x Orientação a Serviços
Fonte: FOWLER e SADALAGE, 2013.
SERVIÇOS
1313
 Encapsulamento nos serviços;
 Mais flexibilidade na resposta (Relações x Estrutura de dados)
 A camada de BDs pode ser de qualquer tipo (Relacional, OO,
NoSQL)
 Não há necessidade de conhecer como usar o BD e sim o serviço;
 Não há mais acesso direto ao BD (Segurança);
Fonte: FOWLER e SADALAGE, 2013.
BDs x Orientação a Serviços
1414
 Década de 90 = Era da Internet e Bolha das .com (Crescimento)
 Evolução dos Websites (Registro de atividades, novas estruturas)
 Surgimento de redes sociais
 Novas formas de interação, novos usuários
 MUITO, MUITO, MUITO mais DADOS
 Necessidade de mais recursos computacionais
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
1515
DILEMA
IR PARA CIMA
X
OU PARA FORA
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
1616
ESCOLHA
PARA FORA
CLUSTERS
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
1717
NOVO DILEMA
BDs RELACIONAIS NÃO
FORAM PROJETADOS PARA
CLUSTERS
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
1818
PRIMEIROS PASSOS
 BDs em Clusters funcionando baseado num subsistema de disco compartilhado
 Oracle RAC ou Microsoft SQL Server
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
Sistema de
Arquivos
Cluster
reconhece
Subsistema de Disco
Compartilhadopersiste
1919
PRIMEIROS PASSOS
 BDs em Clusters funcionando baseado num subsistema de disco compartilhado
 Oracle RAC ou Microsoft SQL Server
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
Sistema de
Arquivos
Cluster
reconhece
Subsistema de Disco
Compartilhadopersiste
PONTO DE FALHA
2020
OUTRA IDEIA
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
FRAGMENTAÇÃO
2121
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
FRAGMENTAÇÃO
 Necessidade de melhor controle dos dados
 Controle vem para a aplicação
 Rastreamento de ONDE tá O QUE preciso para ter O QUE QUERO
 VAI PARA O ESPAÇO (ATRAVÉS DOS FRAGMENTOS)
 Consultas
 Integridade Referencial
 Transações
 E controle de consistência
2222
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
FRAGMENTAÇÃO
 Aumenta a complexidade técnica
 Custos de licenças se multiplicam (Licenças de BD por servidor)
 Tá difícil convencer o setor de compras a pagar várias vezes mais
para ter “QUASE” o mesmo
E agora?
Quem poderá nos defender?
2323
Fonte: FOWLER e SADALAGE, 2013.
A Era dos BDs em Clusters
Big Table Dynamo
2424
Fonte: FOWLER e SADALAGE, 2013.
Surgimento dos BDs NoSQL
2009
Eric Evans Johan Oskarsson
Reunião / Evento / Encontro
BDs Opensource e baseados em novas
alternativas de armazenamento de dados
2525
Fonte: FOWLER e SADALAGE, 2013.
Surgimento dos BDs NoSQL
 Não utilizam SQL
 Tem linguagens próprias de consulta
 Não há ainda padrão (Motivo: Flexibilidade)
 Geralmente projetos Opensource
 Maioria orientada a execução em clusters
 Consistência e Distribuição diferentes (ACID não se aplica)
 Sem esquemas e estrutura fixas
Características Básicas
2626
Fonte: FOWLER e SADALAGE, 2013.
Surgimento dos BDs NoSQL
 Diferentes tipos de armazenamento de dados para diferentes
circunstâncias
 Alternativas ao Modelo relacional
 Entender a natureza dos dados e como iremos manipulá-los para
escolher a melhor opção
NOVA REALIDADE
Mistura de tecnologias
Fortalecimento do uso de serviços
Persistência Poliglota
2727
Fonte: FOWLER e SADALAGE, 2013.
Surgimento dos BDs NoSQL
Clusters
e
Produtividade
2828
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
2929
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
Modelo Relacional
3030
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
Modelo Relacional
Tabela: Cliente
Id Nome
1 Marcos
Tabela: ItemPedido
Id IdPedido IdProduto Preço
1 2 10 350,00
Tabela: Produto
Id Nome
10 Laptop
Tabela: Endereço
Id Logradouro Cidade Estado CEP
1 Av. Sen.
Salgado Filho
Natal RN 59.056-000
Tabela: Pedido
Id IdCliente IdEndEntreg
a
1 1 1
3131
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
Modelo Agregado
3232
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
Modelo Agregado
3333
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
Modelo Agregado - Consequências
 Conhecimento da estrutura agregada ajuda a armazenar e
distribuir os dados
 Flexibilidade para estabelecer modelos de agregados
 Relacionais não possuem conceito de agregados no modelo de
dados
 Bom para análise do agregado, ruim para análise de vários
agregados juntos
 Necessidade de conhecer previamente como e o que você vai
querer saber sobre os dados
3434
Fonte: FOWLER e SADALAGE, 2013.
A lógica por trás dos BDs NoSQL
Modelo Agregado
chave de linha
chave de coluna valor de coluna
Família de colunas
perfil
pedidos
3535
Fonte: IGNATOVICZ e FERNANDES, 2013.
Por que então NoSQL?
3636
Fonte: IGNATOVICZ e FERNANDES, 2013.
Por que então NoSQL?
3737
Fonte: ARMBRUSTER e HUNGER, 2013.
Por que então NoSQL?
3838
Fonte: ARMBRUSTER e HUNGER, 2013.
Por que então NoSQL?
3939
Por que então NoSQL?
Fonte: IGNATOVICZ e FERNANDES, 2013.
4040
A função COMPLEXIDADE
Fonte: ARMBRUSTER e HUNGER, 2013.
4141
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Chave -valor
Oracle Riak (chave-valor)
Instância de Banco de Dados Cluster Riak
Tabela Bucket
Linha Chave-valor
RowID Chave
UserProfile
SessionData
ShoppingCart
CartItem
<Bucket = userData>
<Key = sessionID>
<Value = Object>
CartItem
 Valor é armazenado, sem preocupação com o
que representa
 Aplicação faz o tratamento e se preocupa com
entendimento do valor
 Muito escalar devido o acesso somente pela
chave
 Pode armazenar tudo num Bucket ou criar
buckets de domínio
 LIMITAÇÃO: Consulta só pela chave, retornando
o valor. Valor não pode ser consultado por
atributo.Geração das chaves.
4242
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Chave -valor
UserProfile
SessionData
ShoppingCart
CartItem
<Bucket = userData>
<Key = sessionID>
<Value = Object>
CartItem
 Armazenamento de informações de sessão
 Perfis de usuários e preferências
 Dados de carrinhos de compras
Bom para
 Relacionamento entre dados
 Transações com múltiplas operações
 Consultas por dados e atributos
 Operações por conjuntos
Ruim para
4343
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Documentos
 Acesso fácil aos atributos internos do documento
 Uso de visões materializadas para agregar
informações ou estabelecer consultas específicas
nos agregados
 Possível fazer consulta dos dados dentro do
documento no nível de atributo
 LIMITAÇÃO: Documentos armazenados devem
ser de uma mesma coleção.
Oracle MongoDB(documentos)
Instância de Banco de Dados Instância MongoDB
Esquema Banco de Dados
Tabela Coleção
Linha Documento
RowID _id
Junção DBRef
4444
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Documentos
 Registro de eventos (log)
 Sistema de Gerenciamento de Conteúdo (CMS)
 Análise web ou em tempo real (analytics)
 Aplicativos de comercio eletrônico
Bom para
 Transações complexas com diferentes
operações
 Consultas em estruturas de agregados variáveis
Ruim para
4545
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Família de Colunas
 Uso de famílias de colunas padrão e
SUPERCOLUNAS (Encadeamento)
 Eficaz para manter dados relacionados
agrupados
 Operações básicas usando GET, SET e DEL
 CQL (Padrão semelhante SQL – Cassandra)
 LIMITAÇÃO: Colunas lidas e
desserializadas de uma vez (Value
único).
Oracle Cassandra(colunas)
Instância de Banco de Dados Cluster
Banco de Dados Keyspace
Tabela Família de Colunas
Linha Linha
Coluna (a mesma para todas as
linhas)
Coluna (podem ser diferentes
por linhas)
Família de Colunas
Key
Key
Key
Coluna1
Co'luna1
Coluna1
Coluna2 ColunaN
Coluna2 ColunaN
Coluna2 ColunaN
Name1:
value1
Name1:
value2
NameN:
valuen
Name1:
value1
Name1:
value2
NameN:
valuen
Name1:
value1
Name1:
value2
NameN:
valuen
4646
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Família de Colunas
 Registro de eventos (log)
 Sistema de Gerenciamento de Conteúdo (CMS)
 Contadores
Bom para
 Sistemas que requerem ACID para leituras e
gravações
Ruim para
Família de Colunas
Key
Key
Key
Coluna1
Co'luna1
Coluna1
Coluna2 ColunaN
Coluna2 ColunaN
Coluna2 ColunaN
Name1:
value1
Name1:
value2
NameN:
valuen
Name1:
value1
Name1:
value2
NameN:
valuen
Name1:
value1
Name1:
value2
NameN:
valuen
4747
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Grafos
 Baseado na Teoria dos Grafos
 Dois elementos principais: Nós e
Relacionamentos
 Permite armazenar relacionamentos entre
entidades
 Possibilita encontrar padrões
interessantes entre Nós
 Uma consulta é uma TRAVESSIA (forma de
percorrer)
 Custo baixo para inserir relacionamentos
novos (oposto de BD Relacional)
 Relacionamentos persistidos e não
calculados no momento da consulta
 Modelagem de fácil entendimento
4848
Fonte: FOWLER e SADALAGE, 2013.
Tipos de BDs NoSQL
•Grafos
 Dados conectados
 Roteamentos, envio e serviços baseados em
localização
 Sistemas de recomendação
Bom para
 Sistemas com atualização em lote
(várias entidades atualizadas numa operação)
Ruim para
49
Agenda
49
5050
O que é um GRAFO?
5151
De onde surgiram os grafos?
Leonhard Euler
Fonte: ARMBRUSTER e HUNGER, 2013.
Sete pontes de Königsberg
Resolveu em 1736
5252
De onde surgiram os grafos?
Fonte: TV Cultura
Sete pontes de Königsberg
Vídeo
5353
Por que GRAFOS?
Dados cada vez mais conectados
Fonte: ARMBRUSTER e HUNGER, 2013.
5454
Por que GRAFOS?
Grafos estão em todos os lugares
• Política, Economia, História, Ciência, Transportes
• Biologia, Química, Física, Sociologia
• Internet, Hardware, Software
• Redes Sociais : Família, Amigos, Trabalho, Vizinhos
Fonte: ARMBRUSTER e HUNGER, 2013.
5555
Por que GRAFOS?
Todo mundo tá usando Grafos
Fonte: ARMBRUSTER e HUNGER, 2013.
5656
Por que GRAFOS?
Todo mundo tá usando Grafos
Fonte: ARMBRUSTER e HUNGER, 2013.
5757
Relacional x Grafos
Relacional
Fonte: ARMBRUSTER e HUNGER, 2013.
Grafos
5858
Modelagem Simplificada
5959
Modelagem Simplificada
6060
O que é o BD em Grafo?
 Banco de dados com estrutura interna de armazenamento usando
Grafos
 Cada nós conhece seus vizinhos (nós adjacentes)
 A medida que o número de nós cresce o custo de recuperação de
informação permanece a mesma
 Implementa um índice para pesquisas
Fonte: IGNATOVICZ e FERNANDES, 2013.
6161
Benchmarking
Fonte: IGNATOVICZ e FERNANDES, 2013.
6262
Trabalhando com o Neo4j
Fonte: IGNATOVICZ e FERNANDES, 2013.
 Gremlin
 Cypher – Query Language
 Java API, Framework Traversal e
REST API
6363
Trabalhando com o Neo4j
Fonte: IGNATOVICZ e FERNANDES, 2013.
Gremlin
6464
Trabalhando com o Neo4j
Fonte: NEO4J.COM
Cypher
 Linguagem declarativa para grafos
 Simples, porém poderosa
 Consultas auto-explicativas
 Foco em O QUE recuperar e não COMO
recuperar
 Mix de diversas linguagens (SQL, SPARQL,
Python)
6565
Trabalhando com o Neo4j
Fonte: NEO4J.COM
Cypher – Cláusulas Básicas
 Consulta
 MATCH
 RETURN
 Atualização
 CREATE e DELETE (Nós e Relacionamentos)
 SET e REMOVE (propriedades)
6666
Trabalhando com o Neo4j
Fonte: NEO4J.COM
 Nós
 Nó simples - ( identificador )
 Nós relacionados – ( a ) --> ( b ) / ( a ) <-- ( b )
 Etiqueta – ( a:Pessoa ) --> ( b )
 Propriedades – ( a {nome: “Marcos”})
 Definindo Relacionamentos
 (a)-[r:REL_TYPE]->(b)
 Intervalos
 (a)-[*1..3]->(b)
Cypher – Padrões
6767
Trabalhando com o Neo4j
Fonte: IGNATOVICZ e FERNANDES, 2013.
Cypher
6868
Trabalhando com o Neo4j
Fonte: IGNATOVICZ e FERNANDES, 2013.
Cypher
6969
Trabalhando com o Neo4j
Fonte: IGNATOVICZ e FERNANDES, 2013.
Cypher
Terra
? Maior
Trabalhando com o Neo4j
Vamos
testar ???
71
Natal/RN
2014
FOWLER, Martin e SADALAGE, Pramod. J. NoSQL DISTILLED – A brief guide to the
emerging world of polyglot persistence. 1a ed, Pearson Education. Inc, 2013.
ROBINSON, Ian., WEBER, Jim. e EIFREM, Emil. Graph Databases. First edition, O´Reilly
Media Inc., 2013.
ARMBRUSTER, Stefan e HUNGER, Michael. Introduction Graph Databases and Neo4j,
2013. Disponível em: http://www.bibliopedant.com/DXRf60i5GJh5jUPMGuUX
IGNATOWICZ, Eder e FERNANDES, Thiago. Neo4 o quê? Um guia prático para banco de
dados em grafos, 2013. Disponível em: http://www.infoq.com/br/presentations/neo4j-visao-
pratica
UNGER, Michael. Neo4J - NoSQL Database based in Java, 2010. Disponível em:
http://www.infoq.com/br/news/2010/03/neo4j-10
BARRY, Douglas K. Impedance Mismatch When Mapping from a Relational Database.
Disponível em: http://www.service-architecture.com/articles/object-oriented-
databases/impedance_mismatch. html
Referências Bibliográficas
72
Obrigado !!!
Marcos Luiz Lins
Filhowww.f acebook.com/ marcosluiz.linsf i
lho
marcoslins@gmail.com
@marcoslinsfilho

Banco de Dados - NoSQL

  • 1.
    1 Banco de DadosBancode Dados na Nuvemna Nuvem Natal/RN 2014 Pós-graduação em Arquitetura de Nuvem Prof.Marcos Luiz Lins Filho
  • 2.
    2 Agenda 2 1 Dia (10/12)ᵒ– Histórico, evolução e conceitos dos Bancos de Dados NoSQL 2 Dia (11/12)ᵒ – BD em Grafos com Neo4J 3 Dia (12/12)ᵒ – AWS e BDs na Nuvem 4 Dia (13/12)ᵒ – Apresentação de trabalhos
  • 3.
  • 4.
    4 Motivação 4  Contexto  BDrelacionais são o padrão quase SEMPRE;  A escolha é qual o BD relacional usar;  BD relacionais ameaçados pelos BD OO na década de 90, mas não vingou;  Porque os BD OOs não decolaram?  BD Relacionais de volta ao DOMINIO ABSOLUTO  Depois de longo tempo de DOMÍNIO, surge nova ameaça BDs NoSQL;  Na verdade não é ameaça, é alternativa;  O que os BDs NoSQL tem de diferente dos BD OOs para decolar? Fonte: FOWLER e SADALAGE, 2013.
  • 5.
    55  Memória Principalx Memória Secundária  Armazenamento secundário  Arquivos  Banco de Dados  BD = Flexibilidade  Recuperação de parte do todo de forma rápida e fácil  Concorrência (conceito de transações)  Integração(Relação:Um para muitos - BD x Aplicações) Histórico dos BDs Relacionais Fonte: FOWLER e SADALAGE, 2013.
  • 6.
    66  Por queBDs Relacionais foram bem sucedidos?  Flexibilidade, Concorrência, Integração com padronização  Aprende um MODELO, aplica a vários projetos Histórico dos BDs Relacionais Fonte: FOWLER e SADALAGE, 2013.
  • 7.
    77  O queé isso ? Incompatibilidade de Impedância Fonte: BARRY, Douglas K. Modelo Relacional (tuplas e relações) Estruturas de Dados (Listas, pilhas, árvores etc)
  • 8.
    88  Se tornoumais aparente com o avanço da programação OO;  Causa de grande frustração dos desenvolvedores OO;  Forte Limitação dos BDs Relacionais ;  Fez emergir os BDs OOs;  No final tivemos:  Linguagens OO se tornaram mais e mais fortes;  BDs OO sucumbiram  BDs Relacionais se fortaleceram amparados no suporte a SQL como linguagem padrão de manipulação de dados;  Divisão profissional entre desenvolvedores e DBAs;  Surgimento de frameworks de mapeamento objeto-relacional (Ex. Hibernate) Incompatibilidade de Impedância Fonte: FOWLER e SADALAGE, 2013.
  • 9.
    99 Incompatibilidade de Impedância Fonte:FOWLER e SADALAGE, 2013. OO to Relacional Relacional to OO O PROBLEMA DO MAPEAMENTO
  • 10.
    1010 BDs x Orientaçãoa Serviços Fonte: FOWLER e SADALAGE, 2013. SQL BD INTEGRAÇÃO
  • 11.
    1111 BDs x Orientaçãoa Serviços Fonte: FOWLER e SADALAGE, 2013. SQL BD APLICATIVO
  • 12.
    1212 BDs x Orientaçãoa Serviços Fonte: FOWLER e SADALAGE, 2013. SERVIÇOS
  • 13.
    1313  Encapsulamento nosserviços;  Mais flexibilidade na resposta (Relações x Estrutura de dados)  A camada de BDs pode ser de qualquer tipo (Relacional, OO, NoSQL)  Não há necessidade de conhecer como usar o BD e sim o serviço;  Não há mais acesso direto ao BD (Segurança); Fonte: FOWLER e SADALAGE, 2013. BDs x Orientação a Serviços
  • 14.
    1414  Década de90 = Era da Internet e Bolha das .com (Crescimento)  Evolução dos Websites (Registro de atividades, novas estruturas)  Surgimento de redes sociais  Novas formas de interação, novos usuários  MUITO, MUITO, MUITO mais DADOS  Necessidade de mais recursos computacionais Fonte: FOWLER e SADALAGE, 2013. A Era dos BDs em Clusters
  • 15.
    1515 DILEMA IR PARA CIMA X OUPARA FORA Fonte: FOWLER e SADALAGE, 2013. A Era dos BDs em Clusters
  • 16.
    1616 ESCOLHA PARA FORA CLUSTERS Fonte: FOWLERe SADALAGE, 2013. A Era dos BDs em Clusters
  • 17.
    1717 NOVO DILEMA BDs RELACIONAISNÃO FORAM PROJETADOS PARA CLUSTERS Fonte: FOWLER e SADALAGE, 2013. A Era dos BDs em Clusters
  • 18.
    1818 PRIMEIROS PASSOS  BDsem Clusters funcionando baseado num subsistema de disco compartilhado  Oracle RAC ou Microsoft SQL Server Fonte: FOWLER e SADALAGE, 2013. A Era dos BDs em Clusters Sistema de Arquivos Cluster reconhece Subsistema de Disco Compartilhadopersiste
  • 19.
    1919 PRIMEIROS PASSOS  BDsem Clusters funcionando baseado num subsistema de disco compartilhado  Oracle RAC ou Microsoft SQL Server Fonte: FOWLER e SADALAGE, 2013. A Era dos BDs em Clusters Sistema de Arquivos Cluster reconhece Subsistema de Disco Compartilhadopersiste PONTO DE FALHA
  • 20.
    2020 OUTRA IDEIA Fonte: FOWLERe SADALAGE, 2013. A Era dos BDs em Clusters FRAGMENTAÇÃO
  • 21.
    2121 Fonte: FOWLER eSADALAGE, 2013. A Era dos BDs em Clusters FRAGMENTAÇÃO  Necessidade de melhor controle dos dados  Controle vem para a aplicação  Rastreamento de ONDE tá O QUE preciso para ter O QUE QUERO  VAI PARA O ESPAÇO (ATRAVÉS DOS FRAGMENTOS)  Consultas  Integridade Referencial  Transações  E controle de consistência
  • 22.
    2222 Fonte: FOWLER eSADALAGE, 2013. A Era dos BDs em Clusters FRAGMENTAÇÃO  Aumenta a complexidade técnica  Custos de licenças se multiplicam (Licenças de BD por servidor)  Tá difícil convencer o setor de compras a pagar várias vezes mais para ter “QUASE” o mesmo E agora? Quem poderá nos defender?
  • 23.
    2323 Fonte: FOWLER eSADALAGE, 2013. A Era dos BDs em Clusters Big Table Dynamo
  • 24.
    2424 Fonte: FOWLER eSADALAGE, 2013. Surgimento dos BDs NoSQL 2009 Eric Evans Johan Oskarsson Reunião / Evento / Encontro BDs Opensource e baseados em novas alternativas de armazenamento de dados
  • 25.
    2525 Fonte: FOWLER eSADALAGE, 2013. Surgimento dos BDs NoSQL  Não utilizam SQL  Tem linguagens próprias de consulta  Não há ainda padrão (Motivo: Flexibilidade)  Geralmente projetos Opensource  Maioria orientada a execução em clusters  Consistência e Distribuição diferentes (ACID não se aplica)  Sem esquemas e estrutura fixas Características Básicas
  • 26.
    2626 Fonte: FOWLER eSADALAGE, 2013. Surgimento dos BDs NoSQL  Diferentes tipos de armazenamento de dados para diferentes circunstâncias  Alternativas ao Modelo relacional  Entender a natureza dos dados e como iremos manipulá-los para escolher a melhor opção NOVA REALIDADE Mistura de tecnologias Fortalecimento do uso de serviços Persistência Poliglota
  • 27.
    2727 Fonte: FOWLER eSADALAGE, 2013. Surgimento dos BDs NoSQL Clusters e Produtividade
  • 28.
    2828 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL
  • 29.
    2929 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL Modelo Relacional
  • 30.
    3030 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL Modelo Relacional Tabela: Cliente Id Nome 1 Marcos Tabela: ItemPedido Id IdPedido IdProduto Preço 1 2 10 350,00 Tabela: Produto Id Nome 10 Laptop Tabela: Endereço Id Logradouro Cidade Estado CEP 1 Av. Sen. Salgado Filho Natal RN 59.056-000 Tabela: Pedido Id IdCliente IdEndEntreg a 1 1 1
  • 31.
    3131 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL Modelo Agregado
  • 32.
    3232 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL Modelo Agregado
  • 33.
    3333 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL Modelo Agregado - Consequências  Conhecimento da estrutura agregada ajuda a armazenar e distribuir os dados  Flexibilidade para estabelecer modelos de agregados  Relacionais não possuem conceito de agregados no modelo de dados  Bom para análise do agregado, ruim para análise de vários agregados juntos  Necessidade de conhecer previamente como e o que você vai querer saber sobre os dados
  • 34.
    3434 Fonte: FOWLER eSADALAGE, 2013. A lógica por trás dos BDs NoSQL Modelo Agregado chave de linha chave de coluna valor de coluna Família de colunas perfil pedidos
  • 35.
    3535 Fonte: IGNATOVICZ eFERNANDES, 2013. Por que então NoSQL?
  • 36.
    3636 Fonte: IGNATOVICZ eFERNANDES, 2013. Por que então NoSQL?
  • 37.
    3737 Fonte: ARMBRUSTER eHUNGER, 2013. Por que então NoSQL?
  • 38.
    3838 Fonte: ARMBRUSTER eHUNGER, 2013. Por que então NoSQL?
  • 39.
    3939 Por que entãoNoSQL? Fonte: IGNATOVICZ e FERNANDES, 2013.
  • 40.
    4040 A função COMPLEXIDADE Fonte:ARMBRUSTER e HUNGER, 2013.
  • 41.
    4141 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Chave -valor Oracle Riak (chave-valor) Instância de Banco de Dados Cluster Riak Tabela Bucket Linha Chave-valor RowID Chave UserProfile SessionData ShoppingCart CartItem <Bucket = userData> <Key = sessionID> <Value = Object> CartItem  Valor é armazenado, sem preocupação com o que representa  Aplicação faz o tratamento e se preocupa com entendimento do valor  Muito escalar devido o acesso somente pela chave  Pode armazenar tudo num Bucket ou criar buckets de domínio  LIMITAÇÃO: Consulta só pela chave, retornando o valor. Valor não pode ser consultado por atributo.Geração das chaves.
  • 42.
    4242 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Chave -valor UserProfile SessionData ShoppingCart CartItem <Bucket = userData> <Key = sessionID> <Value = Object> CartItem  Armazenamento de informações de sessão  Perfis de usuários e preferências  Dados de carrinhos de compras Bom para  Relacionamento entre dados  Transações com múltiplas operações  Consultas por dados e atributos  Operações por conjuntos Ruim para
  • 43.
    4343 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Documentos  Acesso fácil aos atributos internos do documento  Uso de visões materializadas para agregar informações ou estabelecer consultas específicas nos agregados  Possível fazer consulta dos dados dentro do documento no nível de atributo  LIMITAÇÃO: Documentos armazenados devem ser de uma mesma coleção. Oracle MongoDB(documentos) Instância de Banco de Dados Instância MongoDB Esquema Banco de Dados Tabela Coleção Linha Documento RowID _id Junção DBRef
  • 44.
    4444 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Documentos  Registro de eventos (log)  Sistema de Gerenciamento de Conteúdo (CMS)  Análise web ou em tempo real (analytics)  Aplicativos de comercio eletrônico Bom para  Transações complexas com diferentes operações  Consultas em estruturas de agregados variáveis Ruim para
  • 45.
    4545 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Família de Colunas  Uso de famílias de colunas padrão e SUPERCOLUNAS (Encadeamento)  Eficaz para manter dados relacionados agrupados  Operações básicas usando GET, SET e DEL  CQL (Padrão semelhante SQL – Cassandra)  LIMITAÇÃO: Colunas lidas e desserializadas de uma vez (Value único). Oracle Cassandra(colunas) Instância de Banco de Dados Cluster Banco de Dados Keyspace Tabela Família de Colunas Linha Linha Coluna (a mesma para todas as linhas) Coluna (podem ser diferentes por linhas) Família de Colunas Key Key Key Coluna1 Co'luna1 Coluna1 Coluna2 ColunaN Coluna2 ColunaN Coluna2 ColunaN Name1: value1 Name1: value2 NameN: valuen Name1: value1 Name1: value2 NameN: valuen Name1: value1 Name1: value2 NameN: valuen
  • 46.
    4646 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Família de Colunas  Registro de eventos (log)  Sistema de Gerenciamento de Conteúdo (CMS)  Contadores Bom para  Sistemas que requerem ACID para leituras e gravações Ruim para Família de Colunas Key Key Key Coluna1 Co'luna1 Coluna1 Coluna2 ColunaN Coluna2 ColunaN Coluna2 ColunaN Name1: value1 Name1: value2 NameN: valuen Name1: value1 Name1: value2 NameN: valuen Name1: value1 Name1: value2 NameN: valuen
  • 47.
    4747 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Grafos  Baseado na Teoria dos Grafos  Dois elementos principais: Nós e Relacionamentos  Permite armazenar relacionamentos entre entidades  Possibilita encontrar padrões interessantes entre Nós  Uma consulta é uma TRAVESSIA (forma de percorrer)  Custo baixo para inserir relacionamentos novos (oposto de BD Relacional)  Relacionamentos persistidos e não calculados no momento da consulta  Modelagem de fácil entendimento
  • 48.
    4848 Fonte: FOWLER eSADALAGE, 2013. Tipos de BDs NoSQL •Grafos  Dados conectados  Roteamentos, envio e serviços baseados em localização  Sistemas de recomendação Bom para  Sistemas com atualização em lote (várias entidades atualizadas numa operação) Ruim para
  • 49.
  • 50.
    5050 O que éum GRAFO?
  • 51.
    5151 De onde surgiramos grafos? Leonhard Euler Fonte: ARMBRUSTER e HUNGER, 2013. Sete pontes de Königsberg Resolveu em 1736
  • 52.
    5252 De onde surgiramos grafos? Fonte: TV Cultura Sete pontes de Königsberg Vídeo
  • 53.
    5353 Por que GRAFOS? Dadoscada vez mais conectados Fonte: ARMBRUSTER e HUNGER, 2013.
  • 54.
    5454 Por que GRAFOS? Grafosestão em todos os lugares • Política, Economia, História, Ciência, Transportes • Biologia, Química, Física, Sociologia • Internet, Hardware, Software • Redes Sociais : Família, Amigos, Trabalho, Vizinhos Fonte: ARMBRUSTER e HUNGER, 2013.
  • 55.
    5555 Por que GRAFOS? Todomundo tá usando Grafos Fonte: ARMBRUSTER e HUNGER, 2013.
  • 56.
    5656 Por que GRAFOS? Todomundo tá usando Grafos Fonte: ARMBRUSTER e HUNGER, 2013.
  • 57.
    5757 Relacional x Grafos Relacional Fonte:ARMBRUSTER e HUNGER, 2013. Grafos
  • 58.
  • 59.
  • 60.
    6060 O que éo BD em Grafo?  Banco de dados com estrutura interna de armazenamento usando Grafos  Cada nós conhece seus vizinhos (nós adjacentes)  A medida que o número de nós cresce o custo de recuperação de informação permanece a mesma  Implementa um índice para pesquisas Fonte: IGNATOVICZ e FERNANDES, 2013.
  • 61.
  • 62.
    6262 Trabalhando com oNeo4j Fonte: IGNATOVICZ e FERNANDES, 2013.  Gremlin  Cypher – Query Language  Java API, Framework Traversal e REST API
  • 63.
    6363 Trabalhando com oNeo4j Fonte: IGNATOVICZ e FERNANDES, 2013. Gremlin
  • 64.
    6464 Trabalhando com oNeo4j Fonte: NEO4J.COM Cypher  Linguagem declarativa para grafos  Simples, porém poderosa  Consultas auto-explicativas  Foco em O QUE recuperar e não COMO recuperar  Mix de diversas linguagens (SQL, SPARQL, Python)
  • 65.
    6565 Trabalhando com oNeo4j Fonte: NEO4J.COM Cypher – Cláusulas Básicas  Consulta  MATCH  RETURN  Atualização  CREATE e DELETE (Nós e Relacionamentos)  SET e REMOVE (propriedades)
  • 66.
    6666 Trabalhando com oNeo4j Fonte: NEO4J.COM  Nós  Nó simples - ( identificador )  Nós relacionados – ( a ) --> ( b ) / ( a ) <-- ( b )  Etiqueta – ( a:Pessoa ) --> ( b )  Propriedades – ( a {nome: “Marcos”})  Definindo Relacionamentos  (a)-[r:REL_TYPE]->(b)  Intervalos  (a)-[*1..3]->(b) Cypher – Padrões
  • 67.
    6767 Trabalhando com oNeo4j Fonte: IGNATOVICZ e FERNANDES, 2013. Cypher
  • 68.
    6868 Trabalhando com oNeo4j Fonte: IGNATOVICZ e FERNANDES, 2013. Cypher
  • 69.
    6969 Trabalhando com oNeo4j Fonte: IGNATOVICZ e FERNANDES, 2013. Cypher Terra ? Maior
  • 70.
    Trabalhando com oNeo4j Vamos testar ???
  • 71.
    71 Natal/RN 2014 FOWLER, Martin eSADALAGE, Pramod. J. NoSQL DISTILLED – A brief guide to the emerging world of polyglot persistence. 1a ed, Pearson Education. Inc, 2013. ROBINSON, Ian., WEBER, Jim. e EIFREM, Emil. Graph Databases. First edition, O´Reilly Media Inc., 2013. ARMBRUSTER, Stefan e HUNGER, Michael. Introduction Graph Databases and Neo4j, 2013. Disponível em: http://www.bibliopedant.com/DXRf60i5GJh5jUPMGuUX IGNATOWICZ, Eder e FERNANDES, Thiago. Neo4 o quê? Um guia prático para banco de dados em grafos, 2013. Disponível em: http://www.infoq.com/br/presentations/neo4j-visao- pratica UNGER, Michael. Neo4J - NoSQL Database based in Java, 2010. Disponível em: http://www.infoq.com/br/news/2010/03/neo4j-10 BARRY, Douglas K. Impedance Mismatch When Mapping from a Relational Database. Disponível em: http://www.service-architecture.com/articles/object-oriented- databases/impedance_mismatch. html Referências Bibliográficas
  • 72.
    72 Obrigado !!! Marcos LuizLins Filhowww.f acebook.com/ marcosluiz.linsf i lho marcoslins@gmail.com @marcoslinsfilho