SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
Meetup MUG-RS
16/11/2016
Christiano Anderson
Twitter: @dump
2.
Agenda
● Abertura e apresentações;
● Novidades da versão 3.4 e schema design (Christiano Anderson - Propus Science);
● Case Superplayer (Robson Almeida - Superplayer);
● Palestras relâmpago (você participa);
● Sugestões e dicas para próximos meetups
3.
Sobre o MUG - RS
● Mais de 200 participantes;
● Já realizou outros 3 meetups passados;
● Ideias para tornar os encontros mais frequentes;
4.
Sobre o palestrante
● Trabalha com MongoDB desde o início do projeto;
● Sócio da Propus Data Science, primeira parceira da MongoDB no Brasil;
● Trabalha com Data Science, foco em persistência de grandes volumes de dados;
● Participa de outras comunidades de software livre como Python, R e Fedora
Project;
6.
MongoDB 3.2
● É a atual versão estável
● Melhorias no storage engine WiredTiger;
● Implementação de validação de documentos;
● Implementação do operador $lookup que simula algo parecido com Joins nos
bancos relacionais;
O MongoDB está acrescentando muitas features interessantes!
7.
Melhorias no WiredTiger
● O storage engine WiredTiger foi incorporado na versão 3.0;
● Implementa melhor compactação dos dados sem influenciar na performance;
● Da versão 3.0 para a 3.2, algumas otimizações e uso mais adequado de cache e
paginação de memória foram implementados;
● Na versão 3.2 o wiredTiger passa a ser o StorageEngine padrão em toda instalação
do MongoDB;
8.
Validação de documentos
● Quando precisamos manter a integridade dos dados, geralmente fazemos
validação via código;
● O controle via código é bem eficiente, mas nada impede que alguém manipule
documentos manualmente;
● A versão 3.2 do MongoDB implementou um validador de documentos, verifica se
o documento inserido em determinada coleção atende alguns requisitos de
validação;
● Caso o documento não atenda os requisitos, o MongoDB gera automaticamente
uma mensagem de erro e o documento não é inserido;
9.
Quando acontece essa validação?
● Somente nos inserts e updates;
● Se a validação é implementada em uma coleção já existente, somente os novos
documentos passarão a ser validados;
10.
Exemplo de validação
● Supondo que seja necessário persistir dados que atendam as seguintes condições:
○ Cadastros de usuários da região sul;
○ Aceitar apenas maiores de 18 anos;
○ Aceitar apenas operadoras de celular Claro, Tim, Oi e Vivo;
16.
Problema
● Juntar dados de duas coleções diferentes;
● Possível fazer via código, geralmente realiza duas ou mais queries no MongoDB;
● É possível agora usar um operador de agregação chamado $lookup e realizar esse
trabalho diretamente no MongoDB;
22.
Está em release candidate
● A versão 3.4 ainda está em desenvolvimento, mas já possui versões RC liberadas
para testes;
● A maior implementação está no suporte a views;
● Sim, o MongoDB suporta validação de documentos, joins e agora suporta views;
27.
Segundo exemplo
Limitar a projeção de determinados campos, no caso da coleção de funcionários, listar
apenas o nome e departamento:
> db.createView("funcionarios_depto", "funcionarios", [
... {$project: {"_id": 0, "nome": 1, "departamento": 1}}])
{ "ok" : 1 }
28.
Show collections
> show collections
funcionarios
funcionarios_depto
funcionarios_rs
system.views
30.
Sobre as views
● São apenas leitura;
● Utilizam os mesmos padrões de índices da coleção pai;
● Ao inserir novos documentos na coleção pai, automaticamente aparecem na view;
32.
O que é?
● Em qualquer banco NoSQL, o schema design é um item fundamental para o
sucesso de uma implementação;
● Existe um vício em pensar como SQL;
● É necessário esquecer detalhes de SQL e entender como funciona cada
paradigma, seja documentos (MongoDB), grafos (Neo4J), colunar (HBase) ou
chave-valor (Redis);
● Vícios do SQL podem tornar a aplicação bastante engessada e não vai usufruir dos
principais benefícios da modelagem não relacional;
33.
Exemplo
● Dada duas coleções de um sistema de escolas:
○ Alunos
○ Livros
● Como você desenvolveria uma aplicação para controlar aluguel de livros pelos
alunos?
● Seria possível desenvolver essa aplicação utilizando apenas as duas coleções
acima?
0 likes
Be the first to like this
Views
Total views
838
On SlideShare
0
From Embeds
0
Number of Embeds
35
You have now unlocked unlimited access to 20M+ documents!
Unlimited Reading
Learn faster and smarter from top experts
Unlimited Downloading
Download to take your learnings offline and on the go
You also get free access to Scribd!
Instant access to millions of ebooks, audiobooks, magazines, podcasts and more.
Read and listen offline with any device.
Free access to premium services like Tuneln, Mubi and more.