Passons à votre question une par une :
Regarder les mesures de performance à partir d'une seule exécution n'est vraiment pas la façon dont cela fonctionne. Vous devriez prendre la moyenne sur plusieurs exécutions avant de conclure car il y a plusieurs facteurs en jeu. Cela étant dit, MongoDB met en cache les documents les plus fréquemment utilisés en mémoire et les y conserve à moins qu'il ne doive céder de la mémoire pour un autre document. Ainsi, si une requête accède à des documents déjà mis en cache à partir d'une requête précédente, cela devrait être plus rapide.
Également dans MongoDB, l'agrégation utilise des index uniquement au début, le cas échéant. Par exemple $match et $sort les phases peuvent utiliser des index. Dans votre cas $match est la première étape du pipeline, c'est donc une victoire.
Dans MongoDB, les données sont stockées dans BSON , donc les dates sont essentiellement des nombres lorsqu'ils sont comparés. Il n'y a donc aucune différence.
Bien que je ne l'aie pas testé, je doute vraiment que l'approche time_bucket donne une réponse plus rapide. Depuis created_at augmentera toujours, l'index, dans ce cas, sera également ajouté à la fin sans time_bucket. De plus, la taille de l'index sera relativement énorme lorsqu'il est créé sur un tableau que sur un simple champ de date. Cela ne causera-t-il pas le problème d'ajustement de l'index dans la RAM.
L'utilisation d'un time_bucket est logique lorsque vous utilisez une fonction sur le champ de date avant la correspondance. Si vous extrayez uniquement l'année du champ de date avant la correspondance, cela rendra l'index existant sur la date inutile.
Il est toujours préférable de convertir vos paramètres pour qu'ils correspondent au type de données dans la base de données plutôt que l'inverse.
Oui c'est possible. Si c'est $and , il vous suffit de spécifier tous vos filtres séparés par des virgules dans le $match phase. Si c'est $or utilisez le $or
opérateur.
Si vous avez deux $macth phases une par une MongoDB le combine en un
. Vous n'avez donc pas à vous soucier d'ajouter les résultats de plusieurs phases de match.
Maintenant votre Optimisation Points
Oui, requêtes couvertes sont beaucoup plus rapides.
Si la taille des documents est réduite dans le $group étape en utilisant $project , alors oui c'est vrai.
Ce n'est pas forcément vrai mais c'est généralement le cas. Vous pouvez vérifier cette réponse .
