‫Jonas : Bon retour.
‫Parlons maintenant un
‫peu des performances de lecture dans MongoDB, pourquoi quelque
‫chose appelé index est si important et comment
‫nous pouvons réellement les créer nous-mêmes.
‫Et je veux commencer cette démonstration sur les index en
‫lançant une simple requête sur toutes nos tournées.
‫Alors venons-en ici pour obtenir toutes les
‫visites et je vais
‫également filtrer pour un prix inférieur à 1 000.
‫D'accord et voyons voir.
‫Ouais, donc on obtient trois résultats, d'accord.
‫Et il est important de garder
‫à l'esprit ce que je vais vous
‫montrer ensuite, c'est-à-dire que nous pouvons également obtenir quelques
‫statistiques sur la requête elle-même.
‫Passons donc ici essentiellement à la fonction de gestionnaire.
‫Et donc, rappelez-vous en ce moment dans l'usine de manutention.
‫Bon, donc c'est ça, je pense que c'est
‫en bas.
‫Ouais donc c'est ça, obtenez toutes les fonctions
‫d'usine qui créeront ce gestionnaire qui
‫est appelé pour la requête que nous venons d'exécuter.
‫Et donc ici sur la
‫requête, je vais en fait maintenant ajouter une méthode d'explication.
‫Bon, donc après la requête, nous appellerons expliquer tout droit.
‫Et donc jetons un coup d'oeil à cela.
‫Et donc nous obtenons maintenant un résultat complètement
‫différent, qui est essentiellement ces statistiques.
‫Maintenant, il y a beaucoup de choses ici.
‫Mais
‫ce qui m'intéresse vraiment, ce sont ces statistiques d'exécution, d'accord.
‫Donc, vous voyez ici que le nombre
‫de documents qui ont été retournés était de trois.
‫Et c'est exactement le résultat que nous avons obtenu avant.
‫Donc avant de bien expliquer.
‫Mais ce qu'il est vraiment important de noter
‫ici, c'est que
‫le nombre de documents qui ont été examinés est de neuf, d'accord.
‫Et cela signifie donc que MongoDB a
‫dû examiner, donc fondamentalement, numériser les neuf documents
‫afin de trouver les trois bons.
‫Donc, les trois qui correspondent à la requête sont d'accord.
‫Et donc ce n'est pas efficace du tout, n'est-ce pas ?
‫Maintenant, bien sûr, à
‫cette échelle avec seulement neuf documents, cela ne fait absolument aucune différence.
‫Mais si nous avions des centaines
‫de milliers, voire des millions de documents
‫ici, cela affecterait considérablement
‫les performances de lecture de cette requête.
‫Encore une fois, ce ne sera pas le cas dans cette application, mais
‫ce sera peut-être dans une application que vous créerez un jour.
‫Et donc vous devez vraiment vous renseigner sur les index.
‫Parce qu'avec les index, nous
‫pourrons en quelque sorte résoudre ce problème.
‫Ainsi, nous pouvons créer des index sur des champs spécifiques dans une collection.
‫Par exemple, Mongo crée automatiquement un index
‫sur le champ ID par défaut.
‫Et voyons ça dans Compass d'accord.
‫Par exemple dans toutes les visites, nous avons ici l'onglet index.
‫Donc, jusqu'à présent, nous n'étions ici que dans
‫l'onglet documents, mais
‫comme vous le voyez, nous avons beaucoup de choses différentes
‫ici et l'une d'elles est les index.
‫Et encore une fois, vous voyez que par défaut, nous avons un index d'identification.
‫Et cet index d'ID est alors essentiellement une liste ordonnée de
‫tous les ID qui sont stockés quelque part
‫en dehors de la collection, d'accord.
‫Et vous pouvez en fait
‫voir une taille ici, qu'il a 36 kilo-octets, cet index très bien.
‫Et cet indice est extrêmement utile.
‫Parce que chaque fois que
‫des documents sont interrogés par l'ID, MongoDB recherchera cet index ordonné au lieu de
‫rechercher dans toute la collection et examinera
‫tous les documents un par un, ce
‫qui est bien sûr beaucoup plus lent.
‫Encore une fois, sans index, Mongo doit examiner chaque
‫document un par un.
‫Mais avec un index sur le champ que nous
‫recherchons, ce processus devient beaucoup plus efficace.
‫C'est donc plutôt intelligent, non ?
‫Et bien sûr, nous pouvons définir nos propres index
‫sur les champs que nous interrogeons très souvent.
‫Faisons-le donc avec le champ de prix
‫que nous venons de demander auparavant,
‫car je pense que c'est l'un des champs
‫les plus importants que les gens recherchent, d'accord.
‫Et c'est ainsi que cela fonctionne.
‫Nous devons donc aller au modèle de tournée à droite.
‫Et puis faisons-le juste ici après cette déclaration intérieure et
‫nous disons tourschema. indice d'accord.
‫Et puis un objet avec le nom du
‫champ et rappelez-vous comment j'ai dit
‫que nous allions définir l'indice sur le prix, puis soit un un, soit un moins.
‫Et un un signifie que nous trions l'indice
‫des prix dans un
‫ordre croissant, tandis que le moins signifie un ordre décroissant d'accord.
‫Et il existe en fait d'autres types d'index, comme pour le
‫texte ou pour les données géospatiales, mais nous verrons
‫cela un peu plus tard.
‫D'accord, sauvegardons-le maintenant
‫et réessayons notre requête.
‫Et en fait, je le ferai plusieurs
‫fois ici pour m'assurer que l'index est vraiment défini.
‫Parce que parfois, ce n'est pas réglé tout de suite.
‫Mais regardons maintenant ici.
‫Et donc effectivement nous obtenons toujours notre nombre de retours à trois mais cette
‫fois le nombre de documents qui ont été examinés,
‫donc qui ont été scannés, n'étaient également que de trois.
‫Et donc cela prouve qu'avec cet
‫indice, nous avons pratiquement atteint exactement ce que nous voulions.
‫Ainsi, avant, nous devions numériser les neuf documents et maintenant,
‫le moteur n'a besoin que de numériser les trois
‫documents qui sont également renvoyés.
‫Et encore parce que leurs
‫prix sont désormais classés dans cet indice.
‫Et cela permet au moteur MongoDB de
‫les trouver beaucoup plus facilement et beaucoup plus rapidement.
‫Et c'est donc bien sûr un gain de performances énorme.
‫Voyons maintenant également Compass ici, et en fait, rechargeons
‫toute la base de données, et maintenant elle devrait être
‫ici, mais pour une
‫raison quelconque, ce n'est pas le cas.
‫Essayons peut-être de recharger les documents.
‫Peut-être qu'il apparaît alors.
‫Pas vraiment, analysons aussi le schéma, et c'est quelque chose
‫dont nous parlerons
‫un peu plus tard.
‫Mais comme vous le voyez, nous n'avons toujours que ces deux index.
‫Mais cela n'a pas d'importance du tout car
‫nous savons déjà que l'index fonctionne réellement, n'est-ce pas ?
‫Il est donc
‫tout à fait normal que la mise à jour prenne parfois un certain temps.
‫Maintenant, une autre chose que vous remarquerez peut-être ici
‫est la façon dont cet index d'identification
‫dont nous avons parlé plus tôt dit unique ici, d'accord.
‫Et si unique est aussi une propriété
‫que l'on peut donner aux index.
‫Et c'est en fait la
‫raison pour laquelle les identifiants doivent toujours être uniques.
‫Donc tout simplement parce
‫que l'index de l'ID a cette propriété unique.
‫Vous avez probablement également remarqué qu'il existe un index pour
‫le nom ici, n'est-ce pas ?
‫Mais nous n'avons pas créé cela manuellement nous-mêmes, n'est-ce pas ?
‫Alors, pouvez-vous deviner pourquoi il est ici ?
‫Eh bien, c'est parce que dans notre définition de schéma, nous
‫définissons le champ de nom pour qu'il soit unique.
‫Et donc, ce que Mongos fait
‫ensuite dans les coulisses afin de garantir l'unicité de ce
‫domaine, c'est de créer un index unique pour lui, d'accord.
‫Et donc à cause de cela, non
‫seulement l'ID mais aussi le nom doivent toujours être uniques.
‫D'accord et c'est déjà super.
‫Ainsi, lorsque tout ce que nous faisons
‫est de rechercher un seul
‫champ, un index de champ unique est parfait,
‫car rappelez-vous que l'index que nous
‫venons de définir s'appelle un index de champ unique.
‫Je ne sais pas si je l'ai mentionné à l'époque, mais je pense que je l'ai fait.
‫Mais de toute façon, si nous interrogeons parfois ce champ
‫mais que nous le combinons avec un autre,
‫il est en fait
‫plus efficace de créer un index composé.
‫Donc un avec deux champs et pas un seul.
‫Créons donc une requête pour cela juste pour l'illustrer.
‫Et donc un autre domaine qui,
‫je pense, va être interrogé tout le temps est la moyenne des notes.
‫Donc les notes moyennes, je pense que c'est comme ça que ça s'appelle, et disons que
‫nous voulons supérieur ou égal à 4. 7 d'accord.
‫Envoyons cette requête.
‫Et voyons combien de résultats nous obtenons.
‫Où est-ce?
‫Ouais ici.
‫Donc le nombre de résultats,
‫donc le nombre de documents qui sont renvoyés,
‫donc qui correspondent à cette requête est de deux.
‫Mais il nous restait à examiner trois documents.
‫Et encore une fois, à cette échelle bien
‫sûr, cela ne fait aucune différence.
‫Mais comme vous le comprenez, ce n'est qu'un exemple.
‫Et maintenant, nous voulons également corriger la situation et pour
‫cela, nous allons utiliser un indice composé.
‫Revenons donc ici.
‫Commentez celui-ci.
‫Ou en fait, dupliquez-le d'abord, puis commentez.
‫Et donc c'est en fait très simple.
‫Il suffit d'ajouter ici l'autre champ.
‫Donc, les notes sont moyennes et mettons celle-ci dans
‫l'ordre croissant.
‫Ou en fait, c'est l'ordre décroissant d'accord.
‫Alors faisons une sauvegarde.
‫Revenons ici.
‫Et encore, je vais le faire quelques fois ici d'accord.
‫Et voyons nos résultats.
‫Et maintenant, nous obtenons le résultat que nous voulions.
‫Ainsi, seuls deux documents ont été
‫scannés afin de retrouver les deux documents que nous recherchions réellement.
‫Parfait et en fait, cet index composé que nous venons
‫de créer fonctionnera également lorsque la requête pour un
‫seul de ces deux champs ici individuellement, donc le
‫prix ou les notes moyennes.
‫Ainsi, lorsque nous créons un index composé comme
‫celui-ci, nous n'avons pas besoin de
‫créer également un individu pour chacun des champs, d'accord.
‫Je veux juste voir à quoi ça ressemble dans Compass maintenant.
‫Mais bon c'est toujours pareil.
‫Mais encore une fois, pas vraiment important.
‫Une chose que l'on peut encore voir
‫ici et qui est
‫assez intéressante, c'est qu'en fait la taille de ces index.
‫Donc 72 kilo-octets, c'est en fait bien plus que la taille
‫totale de tous les documents combinés, qui n'est que
‫de 14 kilo-octets, n'est-ce pas ?
‫Et donc fondamentalement, ces index que nous
‫créons pour rechercher les documents prennent beaucoup plus de
‫place que les documents eux-mêmes.
‫Mais encore une fois, c'est simplement parce que
‫nous opérons à une si petite échelle dans cet exemple.
‫Et donc ce n'est pas vraiment pertinent d'accord.
‫Mais il est toujours important d'en
‫parler car en fait, cela m'amène à notre prochaine question.
‫Et cette question
‫est, comment décidons-nous quel champ nous devons réellement indexer ?
‫Et pourquoi ne définissons-nous pas des index sur tous les champs ?
‫Eh bien, nous avons en quelque sorte utilisé la stratégie
‫que j'ai utilisée pour définir les indices sur le prix et sur la note moyenne.
‫Donc, fondamentalement, nous devons étudier attentivement les modèles d'accès
‫de notre application afin de déterminer quels
‫champs sont les plus interrogés,
‫puis définir les index pour ces champs.
‫Par exemple, je ne définis pas ici d'index sur la taille du groupe car
‫je ne pense pas
‫vraiment que beaucoup de gens interrogeront ce paramètre, et je
‫n'ai donc pas besoin d'y créer un index.
‫Parce que nous ne voulons vraiment pas en faire trop avec les index.
‫Nous ne voulons donc pas définir aveuglément des index sur tous les
‫champs et espérer le meilleur en gros.
‫Et la raison
‫en est que chaque index utilise réellement des
‫ressources, comme vous pouvez le voir ici à droite.
‫De plus, chaque index doit être mis à jour chaque fois
‫que la collection sous-jacente est mise à jour.
‫Donc, si vous avez une collection avec un rapport écriture-lecture élevé, donc une
‫collection sur laquelle on écrit principalement, alors cela
‫n'aurait absolument aucun sens de créer
‫un index sur n'importe quel champ de cette collection car le
‫coût de toujours mettre à jour l'index
‫et de conserver il en mémoire l'emporte clairement sur
‫l'avantage d'avoir l'index en premier lieu si
‫nous avons rarement des
‫recherches, donc des requêtes, pour cette collection.
‫Donc, en résumé, lorsque nous décidons
‫d'indexer ou non un certain champ,
‫nous devons en quelque sorte
‫équilibrer la fréquence des requêtes utilisant ce
‫champ exact avec le coût de maintenance de
‫cet index, ainsi qu'avec le modèle de lecture-écriture de la ressource.
‫Cependant, tout comme c'est le cas avec la modélisation des données,
‫il n'y a pas vraiment de règles strictes ici.
‫Donc tout est un
‫peu flou et vous avez vraiment besoin
‫d'expérimentation et aussi d'expérience pour bien faire les choses, d'accord.
‫Mais quoi que vous fassiez, ne vous contentez pas d'ignorer l'indexation.
‫Car même si ce n'est
‫pas parfait, cela aura toujours un énorme avantage pour votre application.
‫Très bien, et c'est en fait tout ce que
‫j'avais à vous dire sur les index.
‫Il y a juste un autre indice que je veux en fait définir
‫ici, qui est pour le slug de la tournée, d'accord.
‫Parce que plus tard, nous
‫voudrons en fait utiliser le slug unique pour rechercher des visites.
‫Cela signifie donc que le slug deviendra alors
‫probablement le champ le plus interrogé.
‫Et il est
‫donc logique d'avoir également un index pour celui-là.
‫Donc tourschema. index
‫et slug un.
‫Et la plupart du temps, le un ou le moins n'est pas si important.
‫Bon maintenant, je suis vraiment curieux d'essayer de
‫voir cela ici dans Compass.
‫Donc, ce que je vais faire, c'est essayer de me reconnecter à la
‫base de données ici.
‫Et donc je peux juste obtenir cela ici à partir des plus récents.
‫Cliquez, connectez-vous, puis nous devrions nous connecter à la
‫même base de données.
‫Alors natours, tours, venons-en à nos index.
‫Et maintenant, nous y allons.
‫Alors maintenant, nous avons nos index ici.
‫Alors agrandissons cette fenêtre
‫et regardons ce que nous avons.
‫Donc nous avons bien notre limace ici.
‫Nous avons le prix, qui est le premier que nous fixons.
‫Et puis nous avons aussi la moyenne des prix et des
‫notes, qui est composée et vous voyez aussi
‫ici que celui-ci ici est ascendant et celui-ci est
‫descendant car il a le moins.
‫Et une autre chose que vous remarquerez peut-être,
‫c'est qu'en fait,
‫nous n'avons plus cet indice de prix dans notre code.
‫Mais c'est toujours là.
‫Et donc il ne suffit pas de supprimer l'index
‫de notre code, nous devons vraiment le supprimer de la base de données elle-même.
‫Alors rappelez-vous que nous l'avions ici au
‫début, puis nous l'avons
‫commenté et créé ce nouvel indice composé,
‫mais encore une fois, l'indice est immobile ici.
‫Mais puisque nous n'en avons
‫plus besoin, nous pouvons simplement continuer et le supprimer d'accord.
‫Maintenant, nous devons taper le nom juste pour nous
‫assurer de ne pas faire d'erreurs.
‫Et donc on y va, super.
‫Voilà donc le pouvoir des index.
‫Ils peuvent vraiment améliorer nos performances
‫de lecture sur les bases de données.
‫Et donc, dans vos propres
‫applications, vous ne devriez vraiment jamais les ignorer.
‫Et avant de terminer, reprenons en fait cette
‫méthode d'explication que nous avons
‫ajoutée ici dans notre fonction de gestionnaire.
‫Et en fait, juste à
‫titre de référence, je vais le laisser ici comme ça d'accord.
‫Donnez-lui une sauvegarde.
‫Retour dans le menu des articles.
‫Essayons ça maintenant.
‫Et en effet, c'est de retour au travail.
‫Bon et maintenant c'est vraiment ça.