Bueno, no, no hay configuración y si realmente lo piensas, hay una buena razón para esto. Entonces, si primero considera qué está haciendo el agregado y qué hace MongoDB en general, debería quedar claro.
Esto es lo que "debería" estar a la "cabeza" de cualquier tubería de agregación sensible:
db.collection.aggregate([
{ "$match:{ /* Something here */ } },
Y estas son las razones:
-
Tiene buen sentido para probar para reducir el conjunto de trabajo en el que está operando en cualquier operación.
-
Esta es también la única vez que tenga la oportunidad de usar un índice para ayudar en la búsqueda de la selección. Que es siempre mejor que un escaneo de colección.
-
Aunque hay un "optimizador" integrado que busca cosas tales como "proyecciones" que limitan los campos "seleccionados", el mejor escrutador del tamaño del conjunto de trabajo es solo trabajar en los registros válidos. Los partidos de etapas posteriores no están "optimizados" de esta manera. (Ver punto 1 )
Lo siguiente a considerar es el comportamiento general de MongoDB. Para que el proceso del servidor quiera hacer, es "consumir" como mucho de la memoria disponible de la máquina como sea posible para contener los datos del "conjunto de trabajo" (colecciones y/o índice) para "trabajar" sobre esos datos en los medios más eficientes .
Entonces realmente es en el "mejor interés" del motor de la base de datos para "gastar" la mayoría de su asignación de memoria de esta manera. De esa manera, tanto su "agregado" trabajo y todos los otros los procesos concurrentes tienen acceso a los "datos de trabajo" en el espacio de memoria.
Entonces, por lo tanto, es "no óptimo" para MongoDB para "robar" esta asignación de memoria lejos de las otras operaciones concurrentes simplemente para dar servicio a su operación de agregación en ejecución.
En la "programación según requisitos de hardware" términos, bueno, sabe que las versiones futuras permiten que la canalización de agregación implemente el "uso del disco" para permitir un procesamiento mayor. Siempre puede implementar SSD u otros rápidos tecnologías de almacenamiento. Y por supuesto "10%" de RAM es subjetivo a la cantidad de RAM que está instalada en un sistema. Así que siempre puedes aumentar eso.
El resumen de esto es que MongoDB tiene un trabajo real de ser un "almacén de datos concurrente" y lo hace bien. Lo que no es es un específico "agregación corredor de trabajos " y no debe ser tratado como tal.
Así que "romper" sus cargas de trabajo, o aumentar su especificación de hardware, o simplemente cambie la gran actividad de "ejecución de tareas" a algo que haga centrarse en el trabajo en ejecución, como un estilo Hadoop "mapReduce", y deja MongoDB en su trabajo de servir los datos.
O, por supuesto, cambie su diseño para simplemente "pre-agregar" los datos requeridos en algún lugar "al escribir" .
Como dice el refrán, "Caballos para carreras" , o usa tus herramientas para lo que fueron diseñadas para .
