Suponhamos que existam 100 tipos de cães espalhados pelos documentos da minha coleção. Se eu preciso agrupar por tipos de cães e depois calcular algumas estatísticas agregadas sobre cada tipo de cão, por que realizar uma consulta envolvendo , $groupque em princípio processa cada documento sequencialmente, em vez de enviar 100 consultas separadas e simultâneas ao banco de dados onde cada consulta é filtrada com base sobre o tipo de cachorro?
As 100 consultas simultâneas e separadas não seriam mais rápidas?
Se for mais rápido, em escala, qual é a desvantagem de não fazê-lo, se houver?
Isto não é necessariamente verdade. O mecanismo de banco de dados foi projetado para ser otimizado para esse tipo de operação, quando você arquiteta seu banco de dados adequadamente. Paralelismo e operações baseadas em conjuntos de mecanismos de banco de dados não são iguais ao processamento sequencial.
Quanto mais informações você fornecer, ou seja, uma consulta completa, e depender de operações de banco de dados para serem tratadas na camada de banco de dados, mais eficiente ela poderá ser no processamento e fornecimento dos resultados. O motor apresenta um plano para executar da maneira mais otimizada que acredita, com base em todas as informações que tem em mãos.
Geralmente não, por causa do que eu disse acima. Também há sobrecarga para essas 100 consultas simultâneas, tanto do ponto de vista de simultaneidade quanto de gargalos de hardware, como o retorno de mais dados pela rede do que se você retornasse apenas o conjunto final de resultados processados de uma única consulta.
Então você também acabaria remontando esses 100 resultados de consultas e fazendo suas agregações na camada de aplicativo, o que normalmente tem menos desempenho do que permitir que um mecanismo de banco de dados otimizado faça esse trabalho para você da maneira mais eficiente que conhece.