Meetup MUG-RS KingHost
-
Upload
christiano-anderson -
Category
Technology
-
view
200 -
download
0
Transcript of Meetup MUG-RS KingHost
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
Sobre o MUG - RS● Mais de 200 participantes;● Já realizou outros 3 meetups passados;● Ideias para tornar os encontros mais frequentes;
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;
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!
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;
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;
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;
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;
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} } ] }} )
Se a coleção já existedb.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} } ] }} )
Inserindo um documento válido> db.cadastro_sul.insert({... 'nome': 'Christiano',... 'email': '[email protected]',... 'celular': '(51) 9111-0000',... 'operadora_celular': 'Claro',... 'uf': 'RS',... 'ano_nascimento': 1979}) WriteResult({ "nInserted" : 1 })
Inserindo um documento não válido> db.cadastro_sul.insert({... 'nome': 'Joaquim',... 'email': '[email protected]',... 'celular': '(51) 9111-0000',... 'operadora_celular': 'Nextel',... 'uf': 'RS',... 'ano_nascimento': 1988})
WriteResult({ "nInserted" : 0, "writeError" : { "code" : 121, "errmsg" : "Document failed validation" }})
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;
ExemploColeçã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 }
Usando o operador $lookupdb.pedidos.aggregate([ { $lookup: { from: "produtos", localField: "produto_id", foreignField: "_id", as: "pedidos_realizados" } }])
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 } ]}
Uso com outros agregadoresÉ possível mesclar o resultado e limitar a saída usando outros operadores como:
$match
$project
$unwind
(...)
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;
Exemplo 01Database: 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" : "[email protected]"
}
Criar uma view para listar apenas funcionários do RSdb.createView('funcionarios_rs', 'funcionarios', [
{$match: {'uf': 'RS'} }
])
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" : "[email protected]"
}
{"_id" :
ObjectId("582c82db90456c496b5dc5e0"),"cidade" : "Porto Alegre","nome" : "Isabela Silva","ano_nascimento" : 1988,"departamento" : "RH","uf" : "RS","email" : "[email protected]"
}
Segundo exemploLimitar 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 }
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" }
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;
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;