O documento descreve como o MongoDB foi criado pelos fundadores da Doubleclick em 2007 e se tornou popular entre grandes empresas como Foursquare, Github e EA Games. O documento também discute conceitos como NoSQL, armazenamento de documentos, modelagem flexível de dados e escalabilidade.
1. e NoSQL
Tudo o que você precisa saber
Fórum Internacional de Software Livre 2015
Christiano Anderson
anderson@propus.com.br
http://www.propus.com.br
Twitter: @dump
2. Quem sou?
●
Arquiteto de dados na Propus Science;
●
Trabalho com web e software livre desde
1995;
●
Python desde 2000;
●
MongoDB desde o início do projeto;
●
Colaboro e já colaborei com projetos como:
– GNU Project (Free Software Foundation);
– Debian Project;
– Python;
– MongoDB – MUG - SP;
●
Twitter: @dump
●
Blog:
http://christiano.me
●
Facebook, LinkedIn:
Christiano Anderson
3. Mongo?
●
Sim, em muitos idiomas pode ser um
termo pejorativo, mas a origem vem de:
Humongous
“Gigantesco”
4. História
●
Foi criado pelos fundadores da
Doubleclick;
●
10gen foi fundada em 2007;
●
A ideia inicial era fazer um produto
semelhante ao Google App Engine;
5. Alta curva de crescimento
Contribuições ao core do MongoDB
7. Um pouco de conceitos...
●
NoSQL: O termo foi criado por Carlo
Strozzi e Eric Evans como referência a um
tipo de armazenamento de dados;
●
Nunca, mas nunca está relacionado a ódio
ao modelo SQL, pelo contrário, podem até
trabalhar em conjunto;
●
O termo NoREL e Não Relacional também
é bastante utilizado
8. Por que usar NoSQL?
●
Novos paradigmas (nem tão novos
assim);
●
Funcionalidades;
●
Escalabilidade;
●
Performance;
●
Não ficar preso a modelagem;
9. Volume de dados
●
Grande volume é relativo, o que você
considera grande?
– Dados que crescem exponencialmente;
– Agregam muitos valores dinamicamente;
– Não precisam de modelagem;
10. Considere uso de MongoDB se...
●
Está usando muito cache em sua aplicação;
●
Os dados mudam muito;
●
Os dados estão crescendo de forma exponencial;
●
Precisa de processamento em tempo real;
●
Gosta de desenvolvimento ágil;
●
Sua aplicação é “beta perpétua”;
●
Tem dificuldade para trabalhar com modelo relacional;
●
Usa muito “join” na sua aplicação relacional;
11. Iniciando com MongoDB
●
Sua distribuição GNU/Linux deve possuir
pacotes prontos;
●
No site da MongoDB, possível baixar
binários para outros sistemas
operacionais;
●
A instalação é bem simples, a
configuração padrão do MongoDB já
atende quase todos os cenários;
12. Pode substituir o banco relacional?
●
Até pode, mas é uma questão de
arquitetura e escolhas;
●
Uma aplicação pode usar MongoDB e
banco relacional;
●
Tudo vai depender da sua arquitetura;
13. Não existe a melhor ferramenta...
… Existe a que atende melhor a sua necessidade.
A necessidade pode exigir mais de uma ferramenta.
14. Suporte a linguagens de
programação
●
Praticamente todas as linguagens de programação possuem
suporte (driver) para MongoDB;
●
Suporte oficial às principais linguagens (Python, C, C++, PHP,
Java, NodeJS, Perl, Scala, Ruby, C#);
●
Suporte da comunidade a diversas outras linguagens (R, Go,
Erlang, LISP, Lua, Matlab, Smalltalk, entre outras)
17. Stemming
●
Se a frase abaixo estiver indexada
como FTS:
“Enquanto houver vontade de lutar, haverá
esperança de vencer”
●
Se houver uma busca pela palavra
“vencendo”, a mesma será exibida no
resultado de busca.
18. Interface em JavaScript
●
O MongoShell é baseado em JavaScript,
oferece toda flexibilidade para gerenciar o
banco de dados e executar operações
administrativas
19. Nomenclaturas
Banco Relacional MongoDB
Base de dados --> Base de Dados
Tabela --> Coleção
Registro --> Documento
Índice --> Índice
Join --> Documento embarcado
Foreign key --> Referência
21. Realizando operações via
MongoShell
●
O MongoDB é implícito, não existe
necessidade de criar toda estrutura do
banco de dados antes;
●
O MongoShell é uma ótima forma de
aprendizado!
24. Inserindo um registro
anderson@endor:~$ mongo
MongoDB shell version: 2.4.6
connecting to: test
> use escola
switched to db escola
> db.alunos.insert({
... 'nome':'Rolando Rocha',
... 'turma':'Python',
... 'nota': 10})
>
Nesse ponto, o banco foi criado
e o documento foi inserido, já
está persistido em disco
25. Verificando o registro
> db.alunos.findOne()
{
"_id" :
ObjectId("525ecd6585512f4130afd2c4")
,
"nome" : "Rolando Rocha",
"turma" : "Python",
"nota" : 10
}
ObjectId é único
para cada
documento
39. Comparativo SQL
SQL MongoDB
INSERT INTO USERS VALUES(1,1) db.users.insert({a:1, b:1})
SELECT a,b FROM users db.users.find({}, {a: 1, b: 1})
SELECT * FROM users db.users.find()
SELECT * FROM users WHERE age=33 db.users.find({age: 33})
SELECT * FROm users WHERE name =
“pedro”
db.users.find({name:”pedro”})
40. Comparativo SQL
SQL MongoDB
SELECT * FROM users WHERE age=33
ORDER BY name
db.users.find({‘age’:33}).sort({na
me:1})
SELECT * FROM users WHERE age < 33 db.users.find({‘age’:{$lt:33}})})
CREATE INDEX myindexname ON
user(name)
db.users.ensureIndex({name:1})
SELECT * FROM users WHERE a = 1
AND b = ‘q’
db.users.find({a:1, b:’q’})
SELECT * FROM users LIMIT 10 SKIP 20 db.users.find().limit(10).skip(20)
41. Como descobrir documentos que
não possuem determinada chave
> db.alunos.find({'email':
{$exists: false} })
42. Adicionando chave em todos os
documentos
> db.alunos.update({ },
{ $set: { 'aprovado': true } },
{ multi: true })
O que adicionar
Query
Grava a alteração em todos
Os registros que atendem
Ao critério
45. Explicação primeiro cenário
●
Adicionado à coleção de ALUNOS uma
chave chamada biblioteca_id;
●
Facilita a pesquisa de quais alunos
alugaram livros (dentro da coleção
alunos);
●
Dificulta a pesquisa de quais livros foram
alugados (dentro da coleção da
biblioteca);
47. Explicação segundo cenário
●
Adicionada uma chave “aluguel” dentro da coleção
biblioteca;
●
Todos livros alugados possuem o atributo “aluguel”;
●
Facilita a busca dos livros disponíveis e alugados;
●
Pode criar histórico de alugueis;
●
Mas dificulta a busca de quais alunos estão alugando livro
(visão: coleção de alunos);
●
Esse seria um cenário recomendado!
48. Terceiro cenário
●
Criar uma collection de referência,
exemplo: “aluguel_livros” e relacionar o
_id do aluno com _id do livro, assim
como qualquer outra informação
adicional
NÃO USE ESSE MODELO!
É MUITO RELACIONAL!
50. {
"_id" : ObjectId("541f6a9092a2ee25fedaa655"),
"titulo" : "Aqui é o título",
"tags" : [
"teste",
"exemplo",
"mongodb"
],
"conteudo" : "Aqui vem o Lorem Ipsum básico",
"comentarios" : [
{
"usuario" : "Usuario Troll",
"email" : "troll@troland.com",
"comentario" : "Vim aqui só trollar"
},
{
"usuario" : "Usuario Sério",
"email" : "serio@serioland.com",
"comentario" : "Parabéns pelo post"
}
]
}
Exemplo Aplicação Blog
Os comentários ficam
embarcados no
mesmo documento
que o post
51. Guardar logs, séries temporais e muitos
documentos pequenos, também tem uma
modelagem específica para isso.
Pense nas possibilidades de uso desses dados
antes de gravar qualquer coisa!
Faça testes, muitos testes
55. Documentos únicos
●
Um dia possui 86.400 segundos;
●
86.400 documentos por dia na coleção;
●
Se quiser pegar o histórico de um dia, terá de
varrer 86.400 documentos;
●
Se quiser pegar o histórico de um ano, serão
31.556.926 documentos consultados!!!
●
Isso para o MongoDB é pouco, mas pode ser
otimizado...
56. Agregado por minuto
{
timestamp_minute: ISODate("2013-10-
10T23:06:00.000Z"),
type: “memory_used”,
values: {
0: 999999,
…
37: 1000000,
38: 1500000,
…
59: 2000000
}
}
23:06
Todos os segundos
das 23:06
57. Documentos agregados por minuto
●
Um dia possui 1.440 minutos;
●
1.440 documentos por dia na coleção;
●
Se quiser pegar o histórico de um dia, terá de
varrer 1.440 documentos;
●
Se quiser pegar o histórico de um ano, serão
525.600 documentos consultados!!!
●
Ainda pode ser mais otimizado...
58. Agregado por hora
{
timestamp_hour: ISODate("2013-10-
10T23:00:00.000Z"),
type: “memory_used”,
values: {
0: 999999,
1: 1000000,
…,
3598: 1500000,
3599: 2000000
}
}
Cada segundo dessa
hora e seus
respectivos valores
1h = 3.600 segundos
23h
59. Documentos agregados por hora
●
Um dia possui 24 horas;
●
24 documentos por dia na coleção;
●
Se quiser pegar o histórico de um dia, terá de
varrer apenas 24 documentos;
●
Se quiser pegar o histórico de um ano, serão
apenas 365 documentos consultados!!!
●
Chegamos em um nível interessante de
granularidade de dados...
60. Melhor schema
A pergunta de ouro:
Como buscar o maior número de
informações com menor número de
queries (de preferência, uma)?
61. Melhor schema
●
Eficiência na gravação
●
Eficiência na leitura
●
Não existe mágica, é necessário entender o
funcionamento da aplicação
●
Bom schema, bom código = sucesso garantido
●
Índices e agregadores podem ser necessários.
●
Pesquise mais sobre Schema Design MongoDB;
62. Conclusão
●
É um novo paradigma, evite pensar
de forma relacional, senão o projeto
ficará engessado;
●
Pode parecer estranho no começo,
mas a prática mostra que esse
modelo funciona muito bem e é muito
produtivo;
63. Perguntas???
Obrigado!!! Se não deu tempo de responder sua
pergunta, me chame nas redes sociais ou pelos
corredores do FISL! :-)
http://christiano.me
Twitter: @dump
Email: chris@christiano.me
Facebook, LinkedIn: Christiano Anderson