Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Meetup MUG-RS KingHost

338 views

Published on

Apresentação sobre MongoDB no meetup do Grupo de Usuários MongoDB do RS, apresentação feita dia 16/11/2016

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Meetup MUG-RS KingHost

  1. 1. Meetup MUG-RS 16/11/2016 Christiano Anderson Twitter: @dump
  2. 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. 3. Sobre o MUG - RS ● Mais de 200 participantes; ● Já realizou outros 3 meetups passados; ● Ideias para tornar os encontros mais frequentes;
  4. 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;
  5. 5. MongoDB 3.2 Novidades na versão atual
  6. 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. 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. 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. 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. 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;
  11. 11. Caso a coleção não exista: db.createCollection( "cadastro_sul", { validator: { $and: [ { celular: { $type: "string" } }, { operadora_celular: { $in: [ "Claro", "Tim", "Oi", "Vivo" ] } }, { uf: { $in: [ "RS", "SC", "PR" ] } }, { ano_nascimento: { $lte: 1998} } ] } } )
  12. 12. Se a coleção já existe db.runCommand( { collMod: "cadastro_sul", validator: { $and: [ { celular: { $type: "string" } }, { operadora_celular: { $in: [ "Claro", "Tim", "Oi", "Vivo" ] } }, { uf: { $in: [ "RS", "SC", "PR" ] } }, { ano_nascimento: { $lte: 1998} } ] } } )
  13. 13. Inserindo um documento válido > db.cadastro_sul.insert({ ... 'nome': 'Christiano', ... 'email': 'xxx@xxx.com', ... 'celular': '(51) 9111-0000', ... 'operadora_celular': 'Claro', ... 'uf': 'RS', ... 'ano_nascimento': 1979}) WriteResult({ "nInserted" : 1 })
  14. 14. Inserindo um documento não válido > db.cadastro_sul.insert({ ... 'nome': 'Joaquim', ... 'email': 'joaquim@xxx.com', ... 'celular': '(51) 9111-0000', ... 'operadora_celular': 'Nextel', ... 'uf': 'RS', ... 'ano_nascimento': 1988}) WriteResult({ "nInserted" : 0, "writeError" : { "code" : 121, "errmsg" : "Document failed validation" } })
  15. 15. Suporte a Joins Operador $lookup
  16. 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;
  17. 17. Exemplo Coleção de produtos { "_id" : 1, "titulo" : "Moto X 2 Geração", "fabricante" : "Motorola", "preco" : 1099.99 } { "_id" : 2, "titulo" : "Capinha para Moto X 2 Geração", "fabricante" : "Xing Ling", "preco" : 29.9 } { "_id" : 3, "titulo" : "Carregador Power Turbo", "fabricante" : "Power Turbo", "preco" : 199 } Coleção de pedidos { "_id" : 1, "usuario" : "Christiano Anderson", "produto_id" : 1, "quantidade" : 1 } { "_id" : 2, "usuario" : "Ivan", "produto_id" : 1, "quantidade" : 1 } { "_id" : 3, "usuario" : "Carol", "produto_id" : 2, "quantidade" : 3 } { "_id" : 4, "usuario" : "Juliana", "produto_id" : 3, "quantidade" : 1 } { "_id" : 5, "usuario" : "Luiz", "produto_id" : 3, "quantidade" : 1 }
  18. 18. Usando o operador $lookup db.pedidos.aggregate([ { $lookup: { from: "produtos", localField: "produto_id", foreignField: "_id", as: "pedidos_realizados" } } ])
  19. 19. Resultado (2 documentos de exemplo) { "_id" : 1, "usuario" : "Christiano Anderson", "produto_id" : 1, "quantidade" : 1, "pedidos_realizados" : [ { "_id" : 1, "titulo" : "Moto X 2 Geração", "fabricante" : "Motorola", "preco" : 1099.99 } ] } { "_id" : 2, "usuario" : "Ivan", "produto_id" : 1, "quantidade" : 1, "pedidos_realizados" : [ { "_id" : 1, "titulo" : "Moto X 2 Geração", "fabricante" : "Motorola", "preco" : 1099.99 } ] }
  20. 20. Uso com outros agregadores É possível mesclar o resultado e limitar a saída usando outros operadores como: $match $project $unwind (...)
  21. 21. Novidades na versão 3.4
  22. 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;
  23. 23. Exemplo 01 Database: acme Coleção: funcionarios > db.funcionarios.findOne() { "_id" : ObjectId("582c82be90456c496b5dc5de"), "cidade" : "Porto Alegre", "nome" : "Christiano Anderson", "ano_nascimento" : 1979, "departamento" : "Data Science", "uf" : "RS", "email" : "anderson@propus.science" }
  24. 24. Criar uma view para listar apenas funcionários do RS db.createView('funcionarios_rs', 'funcionarios', [ {$match: {'uf': 'RS'} } ])
  25. 25. Verificando as coleções > show collections funcionarios funcionarios_rs system.views >
  26. 26. Fazendo uma consulta na view (2 documentos retorno) > db.funcionarios_rs.find().pretty() { "_id" : ObjectId("582c82be90456c496b5dc5de"), "cidade" : "Porto Alegre", "nome" : "Christiano Anderson", "ano_nascimento" : 1979, "departamento" : "Data Science", "uf" : "RS", "email" : "anderson@propus.science" } { "_id" : ObjectId("582c82db90456c496b5dc5e0"), "cidade" : "Porto Alegre", "nome" : "Isabela Silva", "ano_nascimento" : 1988, "departamento" : "RH", "uf" : "RS", "email" : "isa@acme.com" }
  27. 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. 28. Show collections > show collections funcionarios funcionarios_depto funcionarios_rs system.views
  29. 29. Realizando o find na view > db.funcionarios_depto.find().pretty() { "nome" : "Christiano Anderson", "departamento" : "Data Science" } { "nome" : "Isabela Silva", "departamento" : "RH" } { "nome" : "Pedro Martins", "departamento" : "Estagiário" } { "nome" : "Rafael Oliveira", "departamento" : "Pesquisa e Desenvolvimento" } { "nome" : "Patricia Santos", "departamento" : "Marketing" }
  30. 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;
  31. 31. Schema Design
  32. 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. 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?

×