MongoDB não é magicamente mais rápido. Se você armazena os mesmos dados, organizados basicamente da mesma maneira e os acessa exatamente da mesma maneira, não deve esperar que seus resultados sejam muito diferentes. Afinal, MySQL e MongoDB são ambos GPL, então se o Mongo tivesse algum código de E/S magicamente melhor, então a equipe do MySQL poderia simplesmente incorporá-lo em sua base de código.

As pessoas estão vendo o desempenho real do MongoDB em grande parte porque o MongoDB permite que você consulte de uma maneira diferente, mais sensível à sua carga de trabalho.

Por exemplo, considere um design que persistiu muitas informações sobre uma entidade complicada de forma normalizada. Isso poderia facilmente usar dezenas de tabelas no MySQL (ou qualquer banco de dados relacional) para armazenar os dados no formato normal, com muitos índices necessários para garantir a integridade relacional entre as tabelas.

Agora considere o mesmo design com um armazenamento de documentos. Se todas essas tabelas relacionadas forem subordinadas à tabela principal (e geralmente são), você poderá modelar os dados de forma que toda a entidade seja armazenada em um único documento. No MongoDB você pode armazenar isso como um único documento, em uma única coleção. É aqui que o MongoDB começa a permitir um desempenho superior.

No MongoDB, para recuperar toda a entidade, você deve executar:

• Uma pesquisa de índice na coleção (supondo que a entidade seja buscada por id)
• Recuperar o conteúdo de uma página de banco de dados (o documento json binário real)

Portanto, uma pesquisa de árvore b e uma leitura de página binária. Log(n) + 1 IO. Se os índices puderem residir inteiramente na memória, então 1 IO.

No MySQL com 20 tabelas, você deve executar:

• Uma pesquisa de índice na tabela raiz (novamente, supondo que a entidade seja buscada por id)
• Com um índice clusterizado, podemos supor que os valores da linha raiz estão no índice
• Mais de 20 pesquisas de intervalo (esperamos em um índice) para o valor de pk da entidade
• Esses provavelmente não são índices clusterizados, portanto, as mesmas mais de 20 pesquisas de dados quando descobrirmos quais são as linhas filhas apropriadas.

Portanto, o total para o mysql, mesmo assumindo que todos os índices estão na memória (o que é mais difícil, pois há 20 vezes mais deles) é de cerca de 20 pesquisas de intervalo.

Essas pesquisas de intervalo provavelmente são compostas de E/S aleatórias — tabelas diferentes definitivamente residirão em pontos diferentes no disco, e é possível que linhas diferentes no mesmo intervalo na mesma tabela para uma entidade não sejam contíguas (dependendo de como a entidade foi atualizado, etc).

Portanto, para este exemplo, a contagem final é cerca de 20 vezes mais IO com MySQL por acesso lógico, comparado ao MongoDB.

É assim que o MongoDB pode aumentar o desempenho em alguns casos de uso .