Atualmente utilizamos MongoDB em um sistema que processa uma média de 300k eventos por dia. O objetivo dessa paletra é compartilhar as lições aprendidas e técnicas de otimizações que utilizamos com foco nos seguintes pontos: Queries, Fields, Sort, Indexes, Replicação, Consistência de dados, Consumo de CPU/memória, Transação.
2. Introdução
Onde o MongoDB foi utilizado
Sistema missão critica
Orientado a Eventos
Dividido em 6 módulos consumindo o mesma instancia do MongoDB
Alta concorrência em curto espaço de tempo, média de mil eventos em um minuto
Documentos com grande número de campos – de 60 até 130.
3. Introdução
“MongoDB is like Microsoft, they have a great marketing” - Lynn Langit
Primeiras impressões - NoSQL resolve todos os problemas do SQL tradicional
NoSQL - MongoDB geram diferentes problemas do SQL tradicional
4. Introdução
MongoDB é um banco NoSQL orientado a documentos, open-source.
Alta performance
Alta disponibilidade
Escalonamento automático.
6. Introdução
MongoDB é Consistente e Tolerante a Partições de Rede
Replicas recebem os dados do mestre de forma assíncrona
Replicas elegem novo mestre durante partições de rede
12. Projeções
Documentos tentem a ser grandes por serem não normalizado - NoSQL
Alto IO, latência, consumo de memória
Analisar consultas, conhecer os dados, criar Data Transfer Object, efetuar
projeções nas consultas.
Cautela ao utilizar frameworks de persistência
14. Ordenação
As ordenações são executadas em memórias pelo MongoDB
Existe ganho ao executar a ordenação na aplicação, quando falta o index específico
MongoDB ignora indexes quando a ordenação não respeita a direção dos indexes.
23. Replicação
Quão é critico o MongoDB para sua aplicação
Sistemas críticos não tem janela de manutenção
Replicação permite manutenção sem indisponibilidade*
Encontramos problemas ao criar a replicação
IP x Hostname
Indisponibilidade ao trocar o standalone para replicado
26. Transações
MongoDB: solução para todos os seus problemas?
A nível individual (único documento) MongoDB, é atômico, consistente,
isolado e talvez durável.
Não existem transações, lidar com dinheiro se torna extremamente complexo
27. Transações – como abordamos?
Modelamos o sistema orientado a eventos
Cada evento e documento conhece seu estado, impedindo execução duplicada
Usamos o conhecimento do negócio para mitigar falhas no controle
Não temos a necessidade de voltar atrás (rollback)
28. Migração
Migramos do Mongo 3.0.4 para o 3.2.0
Problemas ao criar a replicação, da instancia antiga para a nova.
Criamos a instancia nova com replicação em três nós
Codificamos uma ferramenta que consulta e insere para migração dos dados
Ganho de performance – WiredTiger oferece lock por Documento
29. Conclusão e Perguntas
MongoDB pode ser a ferramenta ideal para seu sistema
Conheça os seus dados, modelagem faz diferença
Padronize suas consultas
Fragmentação existe no WiredTiger e MMAPv1
Replicas são essenciais