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.

1. Performance no MongoDB
TDC 2017 | FLORIANÓPOLIS – TRILHA DE BIGDATA E NOSQL
JEFFERSON MARTINS DE ANDRADE

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

4. Tópicos da apresentação
• MongoDB – Overview
• Fatores de Performance
• Utilitários e Benchmarking

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

9. COLUNARES
GRAFOS
DOCUMENTOS
CHAVE-VALOR

10. MongoDB Database Model

11. Modelagem do Modelo de Dados

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.

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.

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.

18. Index
Um INDEX serve para agilizar a
busca de algo.

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”.

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

26. Hardware / Network

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)

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

33. WiredTiger – Memory Cache
WT Cache
◦ 50% menos 1GB
◦ 256MB
FS Cache
◦ Máximo disponível

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

37. Armazenamento em disco (WiredTiger)
• ”mongod --dbpath /data/db”
• ”--directoryperdb”
• ”--wiredTigerDirectoryForIndexes”
• Symbolic links

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

43. Index – Criação em Backgroung

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 }

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.

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”

51. Sharding – Latência

52. Ranged Sharding
Hashed Sharding

53. Utilitários e Benchmarking
 MONGODB – OVERVIEW
 FATORES DE PERFORMANCE
 UTILITÁRIOS E BENCHMARKING

54. Utilitários e Benchmarking
• Explain()
• POCDriver
• Logging e Profiling
• Mongotop
• Mongostat
• Benchmarking

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

60. Mongotop
Monitora estatísticas básicas de uso do MongoDB
Pode exibir os dados em JSON

61. Mongostat
Monitora estatísticas básicas também, mas traz mais detalhes
Quantidade de operações por segundo
Uso de memória RAM, Rede...

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