Eh bien non, il n'y a pas de réglage et si vous y réfléchissez vraiment, il y a une bonne raison à cela. Donc, si vous considérez d'abord ce que fait l'agrégat et ce que fait MongoDB en général, cela devrait devenir clair.
C'est ce que "devrait" être à la "tête" de tout pipeline d'agrégation sensé :
db.collection.aggregate([
{ "$match:{ /* Something here */ } },
Et voici les raisons :
-
C'est de bon sens pour essayer pour réduire l'ensemble de travail sur lequel vous travaillez dans tout opération.
-
C'est aussi le seul fois que vous avez la possibilité d'utiliser un index pour faciliter la recherche dans la sélection. Qui est toujours mieux qu'un scan de collection.
-
Même s'il existe un "optimiseur" intégré qui recherche des éléments tels que des "projections" limitant les champs "sélectionnés", le meilleur contrôleur de la taille de l'ensemble de travail est de seulement travailler sur les enregistrements valides. Les matchs des étapes ultérieures ne sont pas "optimisés" de cette manière.(Voir point 1 )
La prochaine chose à considérer est le comportement général de MongoDB. Pour que le processus serveur veut faire, c'est "consommer" autant de la mémoire disponible de la machine afin de contenir les données du "jeu de travail" (collections et/ou index) afin de "travailler" sur ces données par les moyens les plus efficaces .
Donc c'est vraiment dans le "meilleur intérêt" du moteur de base de données pour "dépenser" le plus de son allocation de mémoire de cette manière. De cette façon, à la fois votre "agrégat" travail et tous les autres les processus concurrents ont accès aux "données de travail" dans l'espace mémoire.
Il n'est donc "pas optimal" pour que MongoDB "vole" cette allocation de mémoire loin des autres opérations simultanées juste pour gérer votre opération d'agrégation en cours d'exécution.
Dans la rubrique "programmation selon les exigences matérielles" termes, vous savez bien que les futures versions permettent au pipeline d'agrégation d'implémenter "l'utilisation du disque" afin de permettre un traitement plus important. Vous pouvez toujours implémenter des SSD ou d'autres éléments rapides techniques de stockage. Et bien sûr "10 %" de RAM dépend de la quantité de RAM installée dans un système. Ainsi, vous pouvez toujours augmenter ça.
Le résumé de ceci est que MongoDB a un vrai travail d'être un "magasin de données simultané" et le fait bien. Ce qu'il n'est pas est un spécifique "agrégation job-runner " et ne doit pas être traité comme tel.
Alors soit "rupture" vos charges de travail, ou augmenter vos spécifications matérielles, ou simplement basculer la grande activité "tâche en cours d'exécution" vers quelque chose qui fait se concentrer sur le travail en cours d'exécution tel qu'un style Hadoop "mapReduce", et laissez MongoDB à son travail de servir les données.
Ou bien sûr, changez votre design pour simplement "pré-agréger" les données requises quelque part "en écriture" .
Comme dit le proverbe, "Des chevaux pour les cours" , ou utilisez vos outils pour ce pour quoi ils ont été conçus pour .
