Introdução
Olá e bem-vindo à segunda parte desta série!
Se você chegou aqui e não está totalmente ciente do que está acontecendo, este é um conteúdo que foi dividido em duas partes no qual compartilho meus resultados após testart a performance do MongoDB da versão 3.6 até a 8.0.
Neste post, não vou descrever a ideia principal por trás desta série, o ambiente ou como os testes foram conduzidos. Para isso, temos a primeira parte, que cobre todos esses pontos com todos os detalhes que consegui pensar.
Se você quiser entender este e outros detalhes por trás dos testes, fique a vontade para explorar a primeira parte no link abaixo:
Como usar o artigo:
Esta seção será um breve guia sobre os dados e como usá-los/interpretá-los.
Abaixo, você verá cinco abas que podem ser acessadas para ver os resultados para cada número de threads testado e os cenários.
- Apenas cliquer, e ela se expandirá com os resultados.
Assim que expandir a aba, você verá uma tabela com as operações testadas (Cenário) na coluna mais à esquerda, e o resultado de todas as versões à direita.
- Os números após cada versão nessa linha significam Operações por Segundo.
Por exemplo:
- Para o cenário de Aggregation.FindProjectionDottedField.Indexed.
- O MongoDB 3.6 foi capaz de realizar 549,82 operações por segundo.
- O MongoDB 4.0 foi capaz de realizar 520,79 operações por segundo.
- e assim por diante…
Para mais detalhes sobre a metodologia, por favor, consulte a seção que a explica melhor na Parte 1.
Para ajudar na sua análise, as tabelas possuem algumas funcionalidades que podem ser usadas.
1. Você pode comparar os resultados facilmente: selecione a sua versão preferida e passe o mouse sobre a outra.
Por exemplo – Vamos usar a versão 8.0 como referencia.
- Dessa forma, clique no cabeçalho daquela coluna:
Depois disso, ao passar o mouse sobre essa mesma linha, será mostrada a diferença percentual em comparação com a 8.0:
– Para aquele cenário, MongoDB 7.0 performou 33.19% menos operações quando comparado com 8.0.
2. Você pode habilitar/desabilitar “Highlight Version” (destacar versão).
A minha ideia era simples aqui: já que é um teste de benchmark, eu não queria mais só comparar os resultados. Mas queria também saber qual versão “ganhava” em cada cenário.
Quando habilitamos essa opção, ela destaca qual versão teve melhor desempenho para cada cenário:
3. Por fim, se você quiser analisar os números mais a fundo, pode simplesmente copiar e colar as tabelas no programa de sua preferência.
Além disso, a função de Pesquisa também está habilitada. Você pode filtrar as operações de seu interesse na tabela para refinar a análise, exibindo apenas os resultados correspondentes.
Resultados
Conclusão
Deixarei o julgamento final para você.
Isso porque uma das ideias por trás do uso de diferentes números de threads foi permitir que aqueles com recursos limitados pudessem entender melhor o que esperar do Mongo nestes cenários.
É quase impossível tirar uma conclusão de todos esses testes e expressá-la em uma única observação. Portanto, leve o seu tempo, examine os dados e a metodologia mais de perto e sinta-se à vontade para compartilhar suas opiniões na seção de comentários abaixo.
Dito isso, algumas considerações gerais podem ser compartilhadas.
- É justo comparar o MongoDB 8.0 com releases mais antigas, como 3.6, 4.0, e assim por diante?
Na minha opinião, não é.
Se olharmos para o componente principal, como a engine WiredTiger, ela mudou drasticamente para acomodar todas as novas funcionalidades e reforços de segurança (hardening) em torno do produto que você gosta; compará-los neste ponto é como comparar produtos diferentes.
Ainda assim, vale a pena tambem mencionar que essas mudanças não devem ser usadas para justificar regressões de desempenho em novas releases. Embora não seja justo comparar ambos os produtos, você é o seu próprio benchmark; e uma coisa que sabemos com certeza é que os usuários não aceitam ser enganados, especialmente quando se trata de perda de desempenho.
De acordo com as publicações nos posts do blog da equipe de engenharia (1,2,3), eles estavam cientes disso, e a abordagem mudou para o MongoDB 8:
[..] For instance, if any commit would regress a benchmark by more than 5% for our most important workloads, we would revert the commit. However, this threshold does not detect regressions of 0.1%, and there are thousands of commits per release (e.g., more than 9000 in MongoDB 8.0).
During the release of MongoDB 7.0, we started to take this gradual accumulation of performance loss by tiny regressions of release over release regressions seriously, so we changed the rules of the game. We decided we could not ship MongoDB 7.0 unless it at least matched MongoDB 6.0’s performance on the most important benchmarks.
É discutível se o 7.0 tem o mesmo desempenho do MongoDB 6.0, seja com base nos testes acima ou na experiência pessoal após trabalhar com todas essas releases.
Ainda assim, há uma coisa que este estudo e as notas dos engenheiros têm em comum
- O MongoDB 8.0 de fato tem um desempenho melhor que seus antecessores próximos.
Vale observar que este estudo não cobre áreas como consumo de recursos, que é um ótimo candidato para uma séries de posts separados.
Mas, neste momento, minha recomendação pessoal é fazer o upgrade para a release 8.0 o mais rápido possível para aproveitar essas melhorias.
Outra observação final e um fato curioso deste estudo é que, se removermos o MongoDB 8.0 dos resultados, podemos ver o MongoDB 3.6 lutando pela segunda release mais performática neste teste de benchmark, apresentando resultados ótimos e consistentes no geral.
Sinta-se a vontade para deixar sua opinião nos comentários abaixo, ou sinta-se à vontade para me contatar no LinkedIn.
Até mais!
Referencias:
