Vous lisez mal
Vous interprétez mal l'intention du bloc cité ici quant à ce que .ensureIndex()
(maintenant obsolète, mais toujours appelé par le code de la mangouste) le fait réellement ici dans le contexte.
Dans mongoose, vous définissez un index au niveau du schéma ou du modèle, selon votre conception. Ce que mongoose fait "automatiquement" pour vous, c'est qu'à la connexion, il inspecte chaque modèle enregistré, puis appelle le .ensureIndex() approprié méthodes pour les définitions d'index fournies.
Qu'est-ce que cela fait réellement ?
Eh bien, dans la plupart des cas, après avoir déjà démarré votre application et le .ensureIndexes()
méthode a été exécutée est Absolument Rien . C'est un peu exagéré, mais cela sonne plus ou moins vrai.
Étant donné que la définition d'index a déjà été créée sur la collection de serveurs, un appel ultérieur ne fait rien. C'est-à-dire qu'il ne supprime pas l'index et "recrée". Ainsi, le coût réel est pratiquement nul, une fois l'index lui-même créé.
Créer des index
Donc, puisque la mangouste n'est qu'une couche au-dessus de l'API standard, le createIndex()
contient tous les détails de ce qui se passe.
Il y a quelques détails à considérer ici, comme le fait qu'une construction d'index peut se produire en "arrière-plan", et bien que cela soit moins intrusif pour votre application, cela se fait à ses propres frais. Notamment que la taille de l'index de la génération "en arrière-plan" sera plus grande que si vous l'avez construit au premier plan, bloquant d'autres opérations.
De plus, tous les index ont un coût, notamment en termes d'utilisation du disque ainsi qu'un coût supplémentaire d'écriture des informations supplémentaires en dehors des données de collecte elles-mêmes.
Les avantages d'un index sont qu'il est beaucoup plus rapide de "rechercher" les valeurs contenues dans un index que de parcourir toute la collection et de faire correspondre les conditions possibles.
Ce sont les "compromis" de base associés aux index.
Modèle de déploiement
Retour au bloc cité d'après la documentation, il y a une réelle intention derrière ce conseil.
Il est courant dans les modèles de déploiement et en particulier avec les migrations de données de faire les choses dans cet ordre :
- Remplir les données dans les collections/tables pertinentes
- Activer les index sur les données de collection/table pertinentes pour vos besoins
C'est parce qu'il y a un coût lié à la création d'index, et comme mentionné précédemment, il est souhaitable d'obtenir la taille la plus optimale à partir de la construction de l'index, ainsi que d'éviter que chaque insertion de document ait également la surcharge d'écrire une entrée d'index lorsque vous êtes faire ce "chargement" en masse.
C'est donc à cela que servent les index, ce sont les coûts et les avantages et le message dans la documentation de la mangouste est expliqué.
En général cependant, je suggère de lire sur Index de base de données pour ce qu'ils sont et ce qu'ils font. Pensez à entrer dans une bibliothèque pour trouver un livre. Il y a un fichier à l'entrée. Vous promenez-vous dans la bibliothèque pour trouver le livre que vous voulez ? Ou le cherchez-vous dans l'index des fiches pour trouver où il se trouve ? Cet index a pris du temps à quelqu'un pour le créer et le tenir à jour, mais cela "vous" évite de parcourir toute la bibliothèque juste pour trouver votre livre.
