Selon la documentation de MongoDB, il n'est généralement pas nécessaire de reconstruire régulièrement les index.
REMARQUE :Tout conseil sur le stockage devient plus intéressant avec MongoDB 3.0+, qui a introduit un API de moteur de stockage enfichable . Mes commentaires ci-dessous font spécifiquement référence au moteur de stockage MMAP par défaut dans MongoDB 3.0 et versions antérieures. WiredTiger et d'autres moteurs de stockage ont différentes implémentations de stockage pour les données et les index.
Il peut être avantageux de reconstruire un index avec le moteur de stockage MMAP si :
-
Un index consomme une quantité d'espace plus importante que prévu par rapport aux données. Remarque :vous devez surveiller les données historiques et la taille de l'index pour disposer d'une base de comparaison.
-
Vous souhaitez migrer d'un ancien format d'index vers un nouveau. Si une réindexation est conseillée, cela sera mentionné dans les notes de mise à jour. Par exemple, MongoDB 2.0 a introduit d'importantes améliorations des performances d'index les notes de publication incluent donc une suggestion de réindexation au format v2.0 après la mise à niveau. De même, MongoDB 2.6 a introduit
2dsphere(v2.0) index qui ont un comportement par défaut différent (sparse par défaut). Les index existants ne sont pas reconstruits après les mises à niveau de version d'index ; le choix de si/quand mettre à niveau est laissé à l'administrateur de la base de données. -
Vous avez changé le
_idformat d'une collection vers ou depuis une clé croissante de manière monotone (par exemple, ObjectID) vers une valeur aléatoire. C'est un peu ésotérique, mais il y a une optimisation d'index qui divise les buckets b-tree 90/10 (au lieu de 50/50) si vous insérez_ids qui augmentent toujours (ref :SERVER-983 ). Si la nature de votre_ids change de manière significative, il peut être possible de construire un b-tree plus efficace avec un ré-index.
Pour plus d'informations sur le comportement général de B-tree, voir :Wikipedia :B-tree
Visualiser l'utilisation de l'index
Si vous êtes vraiment curieux de creuser un peu plus dans l'index interne, il existe des commandes/outils expérimentaux que vous pouvez essayer. Je suppose que ceux-ci sont limités à MongoDB 2.4 et 2.6 uniquement :
