O documento resume os principais pontos sobre performance no MongoDB, incluindo:
1) Fatores que afetam a performance como hardware, armazenamento, indexação e replicação;
2) Ferramentas para análise como Explain(), profiling e benchmarking;
3) Conceitos-chave como modelagem de dados, replica sets, sharding e query planner.
2. Sobre a apresentação
QUEM SOU EU?
◦ Desenvolvedor Web Java há quase 6 anos
◦ BRQ, IBM, GFT
◦ Itaú, Bradesco, Porto
◦ ”@jeffersondev” – ”in/jeffersondev”
INTERESSES
◦ Front-End
◦ JavaScript
◦ MEAN Stack
3. Sobre a apresentação
IDEIA
◦ MongoDB University
◦ MongoDB for Java Developers (M101J)
◦ MongoDB for Node.js Developers (M101JS)
◦ MongoDB Performance (M201)
OBJETIVO
◦ Fatores que afetam positivamente/negativamente a performance
◦ Ferramentas e comandos utilitários que podemos utilizar para análise
5. MongoDB - Overview
MONGODB – OVERVIEW
o FATORES DE PERFORMANCE
o UTILITÁRIOS E BENCHMARKING
6. MongoDB - Overview
• NoSQL
• Modelagem de dados
• Replica Set
• Sharded Cluster
• Journal
• Index
• Query Planner
7. NoSQL
NoSQL
◦ Not Only SQL
◦ Bancos de dados não relacionais
◦ Tipos
◦ Documentos
◦ Grafos
◦ Chave-Valor
◦ Colunares
8. NoSQL
POR QUE NoSQL?
◦ Dificuldades de escalar horizontalmente
◦ Representação dos dados
◦ Schema flexível
http://nosql-database.org
◦ Mais de 255 bancos de dados NoSQL
◦ 32 Banco de dados orientado a documentos
12. Replica Set
REPLICA SET é o mecanismo presente no MongoDB para
garantir disponibilidade e tolerância a falhas. Um Replica Set é um
conjunto de membros, executando o processo “mongod”, que estão
em sincronia e possuem os mesmos dados de forma replicada.
13.
14. Replica Set
Mínimo de 3 membros e máximo de 50
Os membros secundários podem ser:
◦ Regular – default (possui os dados replicados e pode se tornar primário)
◦ Priority 0 – não pode se tornar primário
◦ Hidden – não é visível pelos drivers das aplicações
◦ Delayed – tem a replicação atrasada
◦ Arbiter – só participa na votação da eleição do novo primário
15. Sharding
SHARDING é o método utilizado pelo MongoDB para escalar sua
capacidade horizontalmente distribuindo os dados entre vários
servidores.
16.
17. Journal
JOURNAL é o mecanismo utilizado para garantir consistência e integridade ao
banco de dados em caso de uma falha inesperada. O Journal são registros que
mantém todas as operações de escrita que ocorrem no MongoDB.
Em um caso de crash, o MongoDB utiliza o Journal para verificar se todas
as operações registradas nele foram persistidas no database.
21. Query Planner
“QUERY PLAN” são os planos que o MongoDB realiza para
verificar qual será a melhor estratégia para executar a query recebida.
O MongoDB utiliza um conceito chamado “Empirical Query Planner”.
22.
23. Query Planner
O cache é excluído nas situações
◦ Se algum index for criado ou excluído na collection
◦ Se a performance estiver muito mais lenta
◦ Se os indexes forem recriados
◦ Restart do servidor
24. Fatores de Performance
MONGODB – OVERVIEW
FATORES DE PERFORMANCE
o UTILITÁRIOS E BENCHMARKING
25. Fatores de Performance
• Hardware / Network
• Storage Engine
• Armazenamento em disco (WiredTiger)
• Index
• Replica Set para performance
• Sharding
28. Storage Engine
STORAGE ENGINE é o componente responsável
por gerenciar como os dados serão armazenados,
tanto em memória RAM quanto no disco rígido.
MongoDB
◦ WiredTiger
◦ MMAPv1
◦ In-Memory
Terceiros
◦ RocksDB (Facebook)
◦ PerconaFT (Percona)
29.
30. MMAPv1
Default até o MongoDB 3.0
Memória gerenciada pelo Sistema Operacional
Power of 2 Sized Allocations
◦ 32, 64, 128, 256 ... 2MB
◦ Vai gastar mais espaço em memória e disco
Collection Lock Level
◦ Pode ser gerar um problema de performance em sistemas com muitas escritas
Working Set em memória para boa performance
31. WiredTiger
• Empresa adquirida pela MongoDB Inc. em 2014
• Disponível no MongoDB 3.0 e default a partir do
MongoDB 3.2
• Document Lock Level
• Mais escritas em paralelo
• Compressão de dados
• Economia de espaço em memória e disco
• Menor tempo com I/O
• Memory Cache
32. WiredTiger – Compressão dos dados
Compressão dos dados
◦ Sem compressão
◦ Snappy (default)
◦ Equilíbrio CPU vs Taxa Compressão
◦ zlib
◦ Maior compressão
34. In-Memory
• Sem persistência em disco rígido*
• Disponível a partir do MongoDB 3.2.6 Enterprise
• Document Lock Level
• Utilização de memória
◦ 50% menos 1GB
◦ Configurável
35. Armazenamento em disco (WiredTiger)
• Database catalog
• Arquivos de dados
• Arquivos de index
• Arquivos de journal
36.
37. Armazenamento em disco (WiredTiger)
• ”mongod --dbpath /data/db”
• ”--directoryperdb”
• ”--wiredTigerDirectoryForIndexes”
• Symbolic links
38.
39. Index
• db.restaurants.createIndex( { cuisine: 1 } )
• Mínimo de 1 e máximo de 31 campos
• Máximo de 64 indexes por collection
• Limite de 1024 bytes por registro em cada index
40. Index – Partial & Sparse
• db.restaurants.createIndex( { cuisine: 1 }, { partialFilterExpression: { stars: { $gte: 4 } } } )
• Index condicional
• db.restaurants.createIndex( { cuisine: 1 } , { sparse: true } )
• Se o documento não possuir o atributo ou o mesmo for nulo, documento não é indexado
• Economia de espaço
• Economia de processamento para manter o index
41. Index – Covered Queries
Quando todos os atributos dos documentos solicitados fizerem parte de um index
Não busca os documentos, pega as informações direto no index
Performance +++
42. Index – Sorting
In-memory
◦ Custosa, pois traz todos os documentos para a memória RAM e faz a ordenação
◦ Utiliza no máximo 32MB na operação, se passar disso gera erro
Índice
◦ É a opção mais viável e performática
◦ O index pode estar ascendente ou descendente, não faz diferença
44. Index – Insert Performance
Tempo e processamento para manter a árvore binária é cada vez maior
Write Concern (confiabilidade vs performance)
◦ { w: <value>, j: <boolean>, wtimeout: <number> }
◦ { w: 1, j: false, wtimeout: 5000 }
◦ { w: “majority”, j: true }
45.
46. Index – Resumo
• Sempre crie index para apoiar as queries da aplicação!
• Sempre delete indexes que não sejam mais necessários!
47. Replica Set para performance
O principal objetivo do Replica Set é garantir disponibilidade e segurança a falhas.
Mas existem cenários em que pode ser utilizado para ganho de performance.
◦ BI
◦ Analytics
◦ Relatórios
Pode ser uma estratégia dependendo da região geográfica em que os membros da
Replica Set estão localizados.
48.
49.
50. Sharding
•O limite da escala vertical (processamento, memória RAM, I/O) foi atingido?
•Latência da rede entre os diversos nós
•Conhecimento do padrão de crescimento dos dados?
•Conhecimento do padrão de acesso aos dados?
•Importância do “shark key”
55. Explain()
Comando que mostra informações sobre a execução dos comandos
(find, update, delete...)
Nível default
◦ db.restaurants.explain()
◦ db.restaurants.explain(“queryPlanner”)
◦ Informações sobre “Winning Plan”
◦ Não executa o comando em análise
56. Explain()
db.restaurants.explain(“executionStats”)
◦ Mesmo que “queryPlanner” + detalhes como tempo de execução, número de indexes e
documentos analisados, etc.
◦ Executa o comando em análise
db.restaurants.explain(“allPlansExecution”)
◦ Mesmo que “executionStats” + “Rejected Plans”
◦ Executa o comando em análise
57. Explain()
Estágios da “Query Plan” representados no “explain()”
◦ COLLSCAN for a collection scan
◦ IXSCAN for scanning index Keys
◦ FETCH for retrieving documents
◦ SHARD_MERGE for merging results from shards
58. POCDriver
GitHub do John Page (Consulting Engineer na MongoDB, Inc.)
◦ https://github.com/johnlpage/POCDriver
◦ Não é uma ferramenta oficial
Projeto em Java para realizar uma ”Prova de Conceito”
◦ Testando inserts / updates / queries
59. Logging e Profiling
Log default de queries que demorem mais que 100 milissegundos
Profiler registra as queries em ”system.profile”
◦ 0 – desligado, não registra nada (default)
◦ 1 – registra as queries ”lentas” (configurável)
◦ 2 - registra todas as queries
62. Benchmarking
Low Level (I/O, RAM, Thread...)
◦ Sysbench (https://launchpad.net/sysbench)
◦ iibench-mongodb (https://github.com/tmcallaghan/iibench-mongodb)
High Level (Carga de dados, Escritas/Leituras por segundo…)
◦ YCSB (https://github.com/brianfrankcooper/YCSB)
◦ TCP Benckmark (http://www.tpc.org/information/benchmarks.asp)
Distributed Systems (Linearization, Serialization, Tolerancia a falhas)
◦ HiBench (https://github.com/intel-hadoop/HiBench)
◦ Jepsen (https://jepsen.io/)
63. Obrigado!
MONGODB – OVERVIEW
FATORES DE PERFORMANCE
UTILITÁRIOS E BENCHMARKING
Notas do Editor
Sou desenvolvedor Web Java há quase seis anos. Durante esse período venho trabalhando em consultorias como BRQ, IBM e GFT em grandes projetos de bancos como Itaú e Bradesco. Recentemente meu interesse por JavaScript começou a aumentar e após aprender um pouco sobre MEAN Stack resolvi começar meus estudos sobre MongoDB, NodeJS e AngularJS.
A ideia dessa apresentação surgiu após os cursos M101J (MongoDB for Java Developers), M101JS (MongoDB for Node.js Developers) e M201 (MongoDB Performance) feitos na MongoDB University. Aqui eu reuni todas as lições aprendidas nesses cursos que se referem a performance no MongoDB, além de buscar bastante informações na documentação oficial do MongoDB.
O foco é mostrar os fatores que afetam a performance do banco de dados positiva ou negativamente e algumas ferramentas que estão disponíveis no MongoDB para analisar esses fatores. Também irei mostrar alguns exemplos da utilização dessas ferramentas para analisar os impactos na performance.