Para responder a la Q sobre $in....
Hice algunas pruebas de rendimiento con el siguiente escenario:
~24 millones de documentos en una colección
Busque 1 millón de esos documentos en función de una clave (indexada)
Usando el controlador CSharp de .NET
Resultados:
Consultar 1 a la vez, subproceso único:109s
Consultar 1 a la vez, subprocesos múltiples:48s
Consultar 100K a la vez usando $in, subproceso único =20s
Consultar 100 000 a la vez con $in, varios subprocesos =9 s
Por lo tanto, un rendimiento notablemente mejor con un $in grande (restringido al tamaño máximo de consulta).
Actualizar: Siguiendo los comentarios a continuación sobre cómo funciona $in con diferentes tamaños de fragmentos (consultas de subprocesos múltiples):
Consultar 10 a la vez (100000 lotes) =8.8s
Consultar 100 a la vez (10000 lotes) =4.32s
Consultar 1000 a la vez (1000 lotes) =4.31s
Consultar 10000 a la vez (100 lotes) =8,4 s
Consultar 100 000 a la vez (10 lotes) =9 s (según los resultados originales anteriores)
Por lo tanto, parece haber un punto óptimo para cuántos valores agrupar en una cláusula $in frente a la cantidad de viajes de ida y vuelta
