1
00:00:00,910 --> 00:00:02,310
‫Jonas : Bon retour.

2
00:00:02,310 --> 00:00:04,110
‫Parlons maintenant un

3
00:00:04,110 --> 00:00:07,540
‫peu des performances de lecture dans MongoDB, pourquoi quelque

4
00:00:07,540 --> 00:00:10,630
‫chose appelé index est si important et comment

5
00:00:10,630 --> 00:00:13,053
‫nous pouvons réellement les créer nous-mêmes.

6
00:00:14,560 --> 00:00:18,540
‫Et je veux commencer cette démonstration sur les index en

7
00:00:18,540 --> 00:00:21,873
‫lançant une simple requête sur toutes nos tournées.

8
00:00:23,500 --> 00:00:26,550
‫Alors venons-en ici pour obtenir toutes les

9
00:00:26,550 --> 00:00:28,820
‫visites et je vais

10
00:00:30,190 --> 00:00:33,803
‫également filtrer pour un prix inférieur à 1 000.

11
00:00:35,400 --> 00:00:39,393
‫D'accord et voyons voir.

12
00:00:40,900 --> 00:00:43,970
‫Ouais, donc on obtient trois résultats, d'accord.

13
00:00:43,970 --> 00:00:45,950
‫Et il est important de garder

14
00:00:45,950 --> 00:00:48,230
‫à l'esprit ce que je vais vous

15
00:00:48,230 --> 00:00:51,200
‫montrer ensuite, c'est-à-dire que nous pouvons également obtenir quelques

16
00:00:51,200 --> 00:00:53,070
‫statistiques sur la requête elle-même.

17
00:00:53,070 --> 00:00:56,770
‫Passons donc ici essentiellement à la fonction de gestionnaire.

18
00:00:56,770 --> 00:01:01,523
‫Et donc, rappelez-vous en ce moment dans l'usine de manutention.

19
00:01:02,620 --> 00:01:06,033
‫Bon, donc c'est ça, je pense que c'est

20
00:01:08,100 --> 00:01:09,410
‫en bas.

21
00:01:09,410 --> 00:01:12,000
‫Ouais donc c'est ça, obtenez toutes les fonctions

22
00:01:12,000 --> 00:01:14,290
‫d'usine qui créeront ce gestionnaire qui

23
00:01:14,290 --> 00:01:16,940
‫est appelé pour la requête que nous venons d'exécuter.

24
00:01:16,940 --> 00:01:18,360
‫Et donc ici sur la

25
00:01:18,360 --> 00:01:21,053
‫requête, je vais en fait maintenant ajouter une méthode d'explication.

26
00:01:23,640 --> 00:01:28,300
‫Bon, donc après la requête, nous appellerons expliquer tout droit.

27
00:01:28,300 --> 00:01:30,603
‫Et donc jetons un coup d'oeil à cela.

28
00:01:33,710 --> 00:01:36,770
‫Et donc nous obtenons maintenant un résultat complètement

29
00:01:36,770 --> 00:01:39,490
‫différent, qui est essentiellement ces statistiques.

30
00:01:39,490 --> 00:01:41,920
‫Maintenant, il y a beaucoup de choses ici.

31
00:01:41,920 --> 00:01:43,030
‫Mais

32
00:01:43,030 --> 00:01:48,030
‫ce qui m'intéresse vraiment, ce sont ces statistiques d'exécution, d'accord.

33
00:01:48,110 --> 00:01:50,230
‫Donc, vous voyez ici que le nombre

34
00:01:50,230 --> 00:01:52,420
‫de documents qui ont été retournés était de trois.

35
00:01:52,420 --> 00:01:55,130
‫Et c'est exactement le résultat que nous avons obtenu avant.

36
00:01:55,130 --> 00:01:58,030
‫Donc avant de bien expliquer.

37
00:01:58,030 --> 00:02:00,230
‫Mais ce qu'il est vraiment important de noter

38
00:02:00,230 --> 00:02:01,460
‫ici, c'est que

39
00:02:01,460 --> 00:02:05,180
‫le nombre de documents qui ont été examinés est de neuf, d'accord.

40
00:02:05,180 --> 00:02:07,970
‫Et cela signifie donc que MongoDB a

41
00:02:07,970 --> 00:02:11,200
‫dû examiner, donc fondamentalement, numériser les neuf documents

42
00:02:11,200 --> 00:02:13,780
‫afin de trouver les trois bons.

43
00:02:13,780 --> 00:02:17,260
‫Donc, les trois qui correspondent à la requête sont d'accord.

44
00:02:17,260 --> 00:02:20,320
‫Et donc ce n'est pas efficace du tout, n'est-ce pas ?

45
00:02:20,320 --> 00:02:21,900
‫Maintenant, bien sûr, à

46
00:02:21,900 --> 00:02:25,670
‫cette échelle avec seulement neuf documents, cela ne fait absolument aucune différence.

47
00:02:25,670 --> 00:02:27,740
‫Mais si nous avions des centaines

48
00:02:27,740 --> 00:02:30,020
‫de milliers, voire des millions de documents

49
00:02:30,020 --> 00:02:32,010
‫ici, cela affecterait considérablement

50
00:02:32,010 --> 00:02:34,390
‫les performances de lecture de cette requête.

51
00:02:34,390 --> 00:02:37,850
‫Encore une fois, ce ne sera pas le cas dans cette application, mais

52
00:02:37,850 --> 00:02:41,210
‫ce sera peut-être dans une application que vous créerez un jour.

53
00:02:41,210 --> 00:02:44,150
‫Et donc vous devez vraiment vous renseigner sur les index.

54
00:02:44,150 --> 00:02:46,290
‫Parce qu'avec les index, nous

55
00:02:46,290 --> 00:02:48,530
‫pourrons en quelque sorte résoudre ce problème.

56
00:02:48,530 --> 00:02:53,020
‫Ainsi, nous pouvons créer des index sur des champs spécifiques dans une collection.

57
00:02:53,020 --> 00:02:55,980
‫Par exemple, Mongo crée automatiquement un index

58
00:02:55,980 --> 00:02:58,640
‫sur le champ ID par défaut.

59
00:02:58,640 --> 00:03:02,920
‫Et voyons ça dans Compass d'accord.

60
00:03:02,920 --> 00:03:07,280
‫Par exemple dans toutes les visites, nous avons ici l'onglet index.

61
00:03:07,280 --> 00:03:09,580
‫Donc, jusqu'à présent, nous n'étions ici que dans

62
00:03:09,580 --> 00:03:10,810
‫l'onglet documents, mais

63
00:03:10,810 --> 00:03:13,550
‫comme vous le voyez, nous avons beaucoup de choses différentes

64
00:03:13,550 --> 00:03:15,690
‫ici et l'une d'elles est les index.

65
00:03:15,690 --> 00:03:20,410
‫Et encore une fois, vous voyez que par défaut, nous avons un index d'identification.

66
00:03:20,410 --> 00:03:23,860
‫Et cet index d'ID est alors essentiellement une liste ordonnée de

67
00:03:23,860 --> 00:03:26,380
‫tous les ID qui sont stockés quelque part

68
00:03:26,380 --> 00:03:28,890
‫en dehors de la collection, d'accord.

69
00:03:28,890 --> 00:03:30,750
‫Et vous pouvez en fait

70
00:03:30,750 --> 00:03:35,190
‫voir une taille ici, qu'il a 36 kilo-octets, cet index très bien.

71
00:03:35,190 --> 00:03:37,660
‫Et cet indice est extrêmement utile.

72
00:03:37,660 --> 00:03:39,830
‫Parce que chaque fois que

73
00:03:39,830 --> 00:03:44,140
‫des documents sont interrogés par l'ID, MongoDB recherchera cet index ordonné au lieu de

74
00:03:44,140 --> 00:03:46,390
‫rechercher dans toute la collection et examinera

75
00:03:46,390 --> 00:03:48,660
‫tous les documents un par un, ce

76
00:03:48,660 --> 00:03:50,890
‫qui est bien sûr beaucoup plus lent.

77
00:03:50,890 --> 00:03:54,440
‫Encore une fois, sans index, Mongo doit examiner chaque

78
00:03:54,440 --> 00:03:56,650
‫document un par un.

79
00:03:56,650 --> 00:03:59,830
‫Mais avec un index sur le champ que nous

80
00:03:59,830 --> 00:04:02,810
‫recherchons, ce processus devient beaucoup plus efficace.

81
00:04:02,810 --> 00:04:05,420
‫C'est donc plutôt intelligent, non ?

82
00:04:05,420 --> 00:04:08,230
‫Et bien sûr, nous pouvons définir nos propres index

83
00:04:08,230 --> 00:04:10,890
‫sur les champs que nous interrogeons très souvent.

84
00:04:10,890 --> 00:04:13,430
‫Faisons-le donc avec le champ de prix

85
00:04:13,430 --> 00:04:15,830
‫que nous venons de demander auparavant,

86
00:04:15,830 --> 00:04:18,800
‫car je pense que c'est l'un des champs

87
00:04:18,800 --> 00:04:21,770
‫les plus importants que les gens recherchent, d'accord.

88
00:04:21,770 --> 00:04:25,100
‫Et c'est ainsi que cela fonctionne.

89
00:04:25,100 --> 00:04:30,030
‫Nous devons donc aller au modèle de tournée à droite.

90
00:04:30,030 --> 00:04:33,290
‫Et puis faisons-le juste ici après cette déclaration intérieure et

91
00:04:34,370 --> 00:04:37,097
‫nous disons tourschema. indice d'accord.

92
00:04:42,960 --> 00:04:45,600
‫Et puis un objet avec le nom du

93
00:04:47,070 --> 00:04:49,470
‫champ et rappelez-vous comment j'ai dit

94
00:04:49,470 --> 00:04:54,470
‫que nous allions définir l'indice sur le prix, puis soit un un, soit un moins.

95
00:04:54,500 --> 00:04:57,100
‫Et un un signifie que nous trions l'indice

96
00:04:57,100 --> 00:04:58,660
‫des prix dans un

97
00:04:58,660 --> 00:05:02,120
‫ordre croissant, tandis que le moins signifie un ordre décroissant d'accord.

98
00:05:02,120 --> 00:05:05,520
‫Et il existe en fait d'autres types d'index, comme pour le

99
00:05:05,520 --> 00:05:08,280
‫texte ou pour les données géospatiales, mais nous verrons

100
00:05:08,280 --> 00:05:10,260
‫cela un peu plus tard.

101
00:05:10,260 --> 00:05:13,360
‫D'accord, sauvegardons-le maintenant

102
00:05:13,360 --> 00:05:16,633
‫et réessayons notre requête.

103
00:05:17,820 --> 00:05:20,190
‫Et en fait, je le ferai plusieurs

104
00:05:20,190 --> 00:05:22,860
‫fois ici pour m'assurer que l'index est vraiment défini.

105
00:05:22,860 --> 00:05:26,950
‫Parce que parfois, ce n'est pas réglé tout de suite.

106
00:05:26,950 --> 00:05:28,860
‫Mais regardons maintenant ici.

107
00:05:28,860 --> 00:05:33,140
‫Et donc effectivement nous obtenons toujours notre nombre de retours à trois mais cette

108
00:05:33,140 --> 00:05:36,260
‫fois le nombre de documents qui ont été examinés,

109
00:05:36,260 --> 00:05:39,490
‫donc qui ont été scannés, n'étaient également que de trois.

110
00:05:39,490 --> 00:05:41,540
‫Et donc cela prouve qu'avec cet

111
00:05:41,540 --> 00:05:44,310
‫indice, nous avons pratiquement atteint exactement ce que nous voulions.

112
00:05:44,310 --> 00:05:47,370
‫Ainsi, avant, nous devions numériser les neuf documents et maintenant,

113
00:05:47,370 --> 00:05:50,230
‫le moteur n'a besoin que de numériser les trois

114
00:05:50,230 --> 00:05:51,870
‫documents qui sont également renvoyés.

115
00:05:51,870 --> 00:05:54,080
‫Et encore parce que leurs

116
00:05:54,080 --> 00:05:56,330
‫prix sont désormais classés dans cet indice.

117
00:05:56,330 --> 00:05:58,890
‫Et cela permet au moteur MongoDB de

118
00:05:58,890 --> 00:06:01,870
‫les trouver beaucoup plus facilement et beaucoup plus rapidement.

119
00:06:01,870 --> 00:06:04,883
‫Et c'est donc bien sûr un gain de performances énorme.

120
00:06:05,930 --> 00:06:09,300
‫Voyons maintenant également Compass ici, et en fait, rechargeons

121
00:06:09,300 --> 00:06:13,060
‫toute la base de données, et maintenant elle devrait être

122
00:06:13,060 --> 00:06:14,890
‫ici, mais pour une

123
00:06:14,890 --> 00:06:17,750
‫raison quelconque, ce n'est pas le cas.

124
00:06:17,750 --> 00:06:19,823
‫Essayons peut-être de recharger les documents.

125
00:06:21,040 --> 00:06:22,433
‫Peut-être qu'il apparaît alors.

126
00:06:23,910 --> 00:06:26,963
‫Pas vraiment, analysons aussi le schéma, et c'est quelque chose

127
00:06:28,080 --> 00:06:29,260
‫dont nous parlerons

128
00:06:29,260 --> 00:06:30,583
‫un peu plus tard.

129
00:06:31,420 --> 00:06:34,970
‫Mais comme vous le voyez, nous n'avons toujours que ces deux index.

130
00:06:34,970 --> 00:06:37,760
‫Mais cela n'a pas d'importance du tout car

131
00:06:37,760 --> 00:06:40,760
‫nous savons déjà que l'index fonctionne réellement, n'est-ce pas ?

132
00:06:40,760 --> 00:06:41,830
‫Il est donc

133
00:06:41,830 --> 00:06:45,450
‫tout à fait normal que la mise à jour prenne parfois un certain temps.

134
00:06:45,450 --> 00:06:48,330
‫Maintenant, une autre chose que vous remarquerez peut-être ici

135
00:06:48,330 --> 00:06:50,690
‫est la façon dont cet index d'identification

136
00:06:50,690 --> 00:06:53,830
‫dont nous avons parlé plus tôt dit unique ici, d'accord.

137
00:06:53,830 --> 00:06:56,030
‫Et si unique est aussi une propriété

138
00:06:56,030 --> 00:06:58,220
‫que l'on peut donner aux index.

139
00:06:58,220 --> 00:06:59,950
‫Et c'est en fait la

140
00:06:59,950 --> 00:07:02,550
‫raison pour laquelle les identifiants doivent toujours être uniques.

141
00:07:02,550 --> 00:07:04,290
‫Donc tout simplement parce

142
00:07:04,290 --> 00:07:07,180
‫que l'index de l'ID a cette propriété unique.

143
00:07:07,180 --> 00:07:09,970
‫Vous avez probablement également remarqué qu'il existe un index pour

144
00:07:09,970 --> 00:07:11,760
‫le nom ici, n'est-ce pas ?

145
00:07:11,760 --> 00:07:15,600
‫Mais nous n'avons pas créé cela manuellement nous-mêmes, n'est-ce pas ?

146
00:07:15,600 --> 00:07:17,970
‫Alors, pouvez-vous deviner pourquoi il est ici ?

147
00:07:17,970 --> 00:07:20,790
‫Eh bien, c'est parce que dans notre définition de schéma, nous

148
00:07:20,790 --> 00:07:23,140
‫définissons le champ de nom pour qu'il soit unique.

149
00:07:23,140 --> 00:07:25,580
‫Et donc, ce que Mongos fait

150
00:07:25,580 --> 00:07:28,900
‫ensuite dans les coulisses afin de garantir l'unicité de ce

151
00:07:28,900 --> 00:07:32,170
‫domaine, c'est de créer un index unique pour lui, d'accord.

152
00:07:32,170 --> 00:07:34,630
‫Et donc à cause de cela, non

153
00:07:34,630 --> 00:07:37,410
‫seulement l'ID mais aussi le nom doivent toujours être uniques.

154
00:07:37,410 --> 00:07:40,520
‫D'accord et c'est déjà super.

155
00:07:40,520 --> 00:07:42,970
‫Ainsi, lorsque tout ce que nous faisons

156
00:07:42,970 --> 00:07:45,050
‫est de rechercher un seul

157
00:07:45,050 --> 00:07:47,700
‫champ, un index de champ unique est parfait,

158
00:07:47,700 --> 00:07:50,010
‫car rappelez-vous que l'index que nous

159
00:07:50,010 --> 00:07:53,200
‫venons de définir s'appelle un index de champ unique.

160
00:07:53,200 --> 00:07:56,770
‫Je ne sais pas si je l'ai mentionné à l'époque, mais je pense que je l'ai fait.

161
00:07:56,770 --> 00:07:59,716
‫Mais de toute façon, si nous interrogeons parfois ce champ

162
00:07:59,716 --> 00:08:02,020
‫mais que nous le combinons avec un autre,

163
00:08:02,020 --> 00:08:03,650
‫il est en fait

164
00:08:03,650 --> 00:08:05,930
‫plus efficace de créer un index composé.

165
00:08:05,930 --> 00:08:09,210
‫Donc un avec deux champs et pas un seul.

166
00:08:09,210 --> 00:08:12,883
‫Créons donc une requête pour cela juste pour l'illustrer.

167
00:08:14,100 --> 00:08:16,000
‫Et donc un autre domaine qui,

168
00:08:16,000 --> 00:08:19,713
‫je pense, va être interrogé tout le temps est la moyenne des notes.

169
00:08:22,470 --> 00:08:27,470
‫Donc les notes moyennes, je pense que c'est comme ça que ça s'appelle, et disons que

170
00:08:27,610 --> 00:08:32,610
‫nous voulons supérieur ou égal à 4. 7 d'accord.

171
00:08:35,370 --> 00:08:36,673
‫Envoyons cette requête.

172
00:08:38,230 --> 00:08:42,163
‫Et voyons combien de résultats nous obtenons.

173
00:08:43,050 --> 00:08:44,440
‫Où est-ce?

174
00:08:44,440 --> 00:08:45,400
‫Ouais ici.

175
00:08:45,400 --> 00:08:47,010
‫Donc le nombre de résultats,

176
00:08:47,010 --> 00:08:49,290
‫donc le nombre de documents qui sont renvoyés,

177
00:08:49,290 --> 00:08:51,960
‫donc qui correspondent à cette requête est de deux.

178
00:08:51,960 --> 00:08:55,390
‫Mais il nous restait à examiner trois documents.

179
00:08:55,390 --> 00:08:57,480
‫Et encore une fois, à cette échelle bien

180
00:08:57,480 --> 00:08:59,250
‫sûr, cela ne fait aucune différence.

181
00:08:59,250 --> 00:09:01,920
‫Mais comme vous le comprenez, ce n'est qu'un exemple.

182
00:09:01,920 --> 00:09:05,150
‫Et maintenant, nous voulons également corriger la situation et pour

183
00:09:05,150 --> 00:09:07,853
‫cela, nous allons utiliser un indice composé.

184
00:09:09,010 --> 00:09:10,870
‫Revenons donc ici.

185
00:09:10,870 --> 00:09:12,360
‫Commentez celui-ci.

186
00:09:12,360 --> 00:09:15,890
‫Ou en fait, dupliquez-le d'abord, puis commentez.

187
00:09:15,890 --> 00:09:17,500
‫Et donc c'est en fait très simple.

188
00:09:17,500 --> 00:09:20,103
‫Il suffit d'ajouter ici l'autre champ.

189
00:09:21,530 --> 00:09:25,270
‫Donc, les notes sont moyennes et mettons celle-ci dans

190
00:09:25,270 --> 00:09:26,633
‫l'ordre croissant.

191
00:09:29,150 --> 00:09:33,160
‫Ou en fait, c'est l'ordre décroissant d'accord.

192
00:09:33,160 --> 00:09:35,290
‫Alors faisons une sauvegarde.

193
00:09:35,290 --> 00:09:37,060
‫Revenons ici.

194
00:09:37,060 --> 00:09:41,720
‫Et encore, je vais le faire quelques fois ici d'accord.

195
00:09:41,720 --> 00:09:43,970
‫Et voyons nos résultats.

196
00:09:43,970 --> 00:09:47,080
‫Et maintenant, nous obtenons le résultat que nous voulions.

197
00:09:47,080 --> 00:09:49,880
‫Ainsi, seuls deux documents ont été

198
00:09:49,880 --> 00:09:54,010
‫scannés afin de retrouver les deux documents que nous recherchions réellement.

199
00:09:54,010 --> 00:09:57,420
‫Parfait et en fait, cet index composé que nous venons

200
00:09:57,420 --> 00:10:00,700
‫de créer fonctionnera également lorsque la requête pour un

201
00:10:00,700 --> 00:10:04,020
‫seul de ces deux champs ici individuellement, donc le

202
00:10:04,020 --> 00:10:06,330
‫prix ou les notes moyennes.

203
00:10:06,330 --> 00:10:09,000
‫Ainsi, lorsque nous créons un index composé comme

204
00:10:09,000 --> 00:10:11,350
‫celui-ci, nous n'avons pas besoin de

205
00:10:11,350 --> 00:10:14,193
‫créer également un individu pour chacun des champs, d'accord.

206
00:10:15,720 --> 00:10:19,603
‫Je veux juste voir à quoi ça ressemble dans Compass maintenant.

207
00:10:21,310 --> 00:10:22,890
‫Mais bon c'est toujours pareil.

208
00:10:22,890 --> 00:10:25,320
‫Mais encore une fois, pas vraiment important.

209
00:10:25,320 --> 00:10:27,440
‫Une chose que l'on peut encore voir

210
00:10:27,440 --> 00:10:28,933
‫ici et qui est

211
00:10:28,933 --> 00:10:31,663
‫assez intéressante, c'est qu'en fait la taille de ces index.

212
00:10:32,640 --> 00:10:36,680
‫Donc 72 kilo-octets, c'est en fait bien plus que la taille

213
00:10:36,680 --> 00:10:39,930
‫totale de tous les documents combinés, qui n'est que

214
00:10:39,930 --> 00:10:42,680
‫de 14 kilo-octets, n'est-ce pas ?

215
00:10:42,680 --> 00:10:45,470
‫Et donc fondamentalement, ces index que nous

216
00:10:45,470 --> 00:10:48,680
‫créons pour rechercher les documents prennent beaucoup plus de

217
00:10:48,680 --> 00:10:50,890
‫place que les documents eux-mêmes.

218
00:10:50,890 --> 00:10:53,530
‫Mais encore une fois, c'est simplement parce que

219
00:10:53,530 --> 00:10:56,260
‫nous opérons à une si petite échelle dans cet exemple.

220
00:10:56,260 --> 00:10:59,300
‫Et donc ce n'est pas vraiment pertinent d'accord.

221
00:10:59,300 --> 00:11:01,530
‫Mais il est toujours important d'en

222
00:11:01,530 --> 00:11:05,150
‫parler car en fait, cela m'amène à notre prochaine question.

223
00:11:05,150 --> 00:11:06,510
‫Et cette question

224
00:11:06,510 --> 00:11:10,150
‫est, comment décidons-nous quel champ nous devons réellement indexer ?

225
00:11:10,150 --> 00:11:13,710
‫Et pourquoi ne définissons-nous pas des index sur tous les champs ?

226
00:11:13,710 --> 00:11:16,720
‫Eh bien, nous avons en quelque sorte utilisé la stratégie

227
00:11:16,720 --> 00:11:20,640
‫que j'ai utilisée pour définir les indices sur le prix et sur la note moyenne.

228
00:11:20,640 --> 00:11:24,380
‫Donc, fondamentalement, nous devons étudier attentivement les modèles d'accès

229
00:11:24,380 --> 00:11:27,130
‫de notre application afin de déterminer quels

230
00:11:27,130 --> 00:11:29,690
‫champs sont les plus interrogés,

231
00:11:29,690 --> 00:11:32,530
‫puis définir les index pour ces champs.

232
00:11:32,530 --> 00:11:36,640
‫Par exemple, je ne définis pas ici d'index sur la taille du groupe car

233
00:11:36,640 --> 00:11:38,060
‫je ne pense pas

234
00:11:38,060 --> 00:11:41,300
‫vraiment que beaucoup de gens interrogeront ce paramètre, et je

235
00:11:41,300 --> 00:11:43,890
‫n'ai donc pas besoin d'y créer un index.

236
00:11:43,890 --> 00:11:47,930
‫Parce que nous ne voulons vraiment pas en faire trop avec les index.

237
00:11:47,930 --> 00:11:51,610
‫Nous ne voulons donc pas définir aveuglément des index sur tous les

238
00:11:51,610 --> 00:11:54,110
‫champs et espérer le meilleur en gros.

239
00:11:54,110 --> 00:11:55,420
‫Et la raison

240
00:11:55,420 --> 00:11:58,380
‫en est que chaque index utilise réellement des

241
00:11:58,380 --> 00:12:01,360
‫ressources, comme vous pouvez le voir ici à droite.

242
00:12:01,360 --> 00:12:04,850
‫De plus, chaque index doit être mis à jour chaque fois

243
00:12:04,850 --> 00:12:07,670
‫que la collection sous-jacente est mise à jour.

244
00:12:07,670 --> 00:12:12,150
‫Donc, si vous avez une collection avec un rapport écriture-lecture élevé, donc une

245
00:12:12,150 --> 00:12:14,980
‫collection sur laquelle on écrit principalement, alors cela

246
00:12:14,980 --> 00:12:17,320
‫n'aurait absolument aucun sens de créer

247
00:12:17,320 --> 00:12:21,150
‫un index sur n'importe quel champ de cette collection car le

248
00:12:21,150 --> 00:12:23,800
‫coût de toujours mettre à jour l'index

249
00:12:23,800 --> 00:12:27,060
‫et de conserver il en mémoire l'emporte clairement sur

250
00:12:27,060 --> 00:12:29,550
‫l'avantage d'avoir l'index en premier lieu si

251
00:12:29,550 --> 00:12:31,750
‫nous avons rarement des

252
00:12:31,750 --> 00:12:34,240
‫recherches, donc des requêtes, pour cette collection.

253
00:12:34,240 --> 00:12:36,500
‫Donc, en résumé, lorsque nous décidons

254
00:12:36,500 --> 00:12:38,630
‫d'indexer ou non un certain champ,

255
00:12:38,630 --> 00:12:40,750
‫nous devons en quelque sorte

256
00:12:40,750 --> 00:12:43,430
‫équilibrer la fréquence des requêtes utilisant ce

257
00:12:43,430 --> 00:12:46,190
‫champ exact avec le coût de maintenance de

258
00:12:46,190 --> 00:12:49,910
‫cet index, ainsi qu'avec le modèle de lecture-écriture de la ressource.

259
00:12:49,910 --> 00:12:52,950
‫Cependant, tout comme c'est le cas avec la modélisation des données,

260
00:12:52,950 --> 00:12:55,460
‫il n'y a pas vraiment de règles strictes ici.

261
00:12:55,460 --> 00:12:57,240
‫Donc tout est un

262
00:12:57,240 --> 00:12:59,530
‫peu flou et vous avez vraiment besoin

263
00:12:59,530 --> 00:13:03,030
‫d'expérimentation et aussi d'expérience pour bien faire les choses, d'accord.

264
00:13:03,030 --> 00:13:06,570
‫Mais quoi que vous fassiez, ne vous contentez pas d'ignorer l'indexation.

265
00:13:06,570 --> 00:13:08,550
‫Car même si ce n'est

266
00:13:08,550 --> 00:13:12,660
‫pas parfait, cela aura toujours un énorme avantage pour votre application.

267
00:13:12,660 --> 00:13:14,940
‫Très bien, et c'est en fait tout ce que

268
00:13:14,940 --> 00:13:16,903
‫j'avais à vous dire sur les index.

269
00:13:18,230 --> 00:13:21,880
‫Il y a juste un autre indice que je veux en fait définir

270
00:13:21,880 --> 00:13:25,030
‫ici, qui est pour le slug de la tournée, d'accord.

271
00:13:25,030 --> 00:13:26,920
‫Parce que plus tard, nous

272
00:13:26,920 --> 00:13:30,250
‫voudrons en fait utiliser le slug unique pour rechercher des visites.

273
00:13:30,250 --> 00:13:32,680
‫Cela signifie donc que le slug deviendra alors

274
00:13:32,680 --> 00:13:34,640
‫probablement le champ le plus interrogé.

275
00:13:34,640 --> 00:13:35,950
‫Et il est

276
00:13:35,950 --> 00:13:38,780
‫donc logique d'avoir également un index pour celui-là.

277
00:13:38,780 --> 00:13:41,460
‫Donc tourschema. index

278
00:13:45,370 --> 00:13:47,380
‫et slug un.

279
00:13:47,380 --> 00:13:52,140
‫Et la plupart du temps, le un ou le moins n'est pas si important.

280
00:13:52,140 --> 00:13:54,680
‫Bon maintenant, je suis vraiment curieux d'essayer de

281
00:13:54,680 --> 00:13:56,640
‫voir cela ici dans Compass.

282
00:13:56,640 --> 00:14:00,500
‫Donc, ce que je vais faire, c'est essayer de me reconnecter à la

283
00:14:00,500 --> 00:14:02,043
‫base de données ici.

284
00:14:06,740 --> 00:14:10,083
‫Et donc je peux juste obtenir cela ici à partir des plus récents.

285
00:14:11,360 --> 00:14:14,020
‫Cliquez, connectez-vous, puis nous devrions nous connecter à la

286
00:14:14,020 --> 00:14:15,453
‫même base de données.

287
00:14:17,260 --> 00:14:21,540
‫Alors natours, tours, venons-en à nos index.

288
00:14:21,540 --> 00:14:23,380
‫Et maintenant, nous y allons.

289
00:14:23,380 --> 00:14:26,013
‫Alors maintenant, nous avons nos index ici.

290
00:14:27,070 --> 00:14:28,920
‫Alors agrandissons cette fenêtre

291
00:14:28,920 --> 00:14:31,290
‫et regardons ce que nous avons.

292
00:14:31,290 --> 00:14:33,710
‫Donc nous avons bien notre limace ici.

293
00:14:33,710 --> 00:14:36,670
‫Nous avons le prix, qui est le premier que nous fixons.

294
00:14:36,670 --> 00:14:39,940
‫Et puis nous avons aussi la moyenne des prix et des

295
00:14:39,940 --> 00:14:42,610
‫notes, qui est composée et vous voyez aussi

296
00:14:42,610 --> 00:14:45,510
‫ici que celui-ci ici est ascendant et celui-ci est

297
00:14:45,510 --> 00:14:47,740
‫descendant car il a le moins.

298
00:14:47,740 --> 00:14:49,870
‫Et une autre chose que vous remarquerez peut-être,

299
00:14:49,870 --> 00:14:50,880
‫c'est qu'en fait,

300
00:14:50,880 --> 00:14:53,680
‫nous n'avons plus cet indice de prix dans notre code.

301
00:14:53,680 --> 00:14:55,070
‫Mais c'est toujours là.

302
00:14:55,070 --> 00:14:58,630
‫Et donc il ne suffit pas de supprimer l'index

303
00:14:58,630 --> 00:15:03,430
‫de notre code, nous devons vraiment le supprimer de la base de données elle-même.

304
00:15:03,430 --> 00:15:05,870
‫Alors rappelez-vous que nous l'avions ici au

305
00:15:05,870 --> 00:15:07,460
‫début, puis nous l'avons

306
00:15:07,460 --> 00:15:09,780
‫commenté et créé ce nouvel indice composé,

307
00:15:09,780 --> 00:15:12,300
‫mais encore une fois, l'indice est immobile ici.

308
00:15:12,300 --> 00:15:14,430
‫Mais puisque nous n'en avons

309
00:15:14,430 --> 00:15:18,170
‫plus besoin, nous pouvons simplement continuer et le supprimer d'accord.

310
00:15:18,170 --> 00:15:21,070
‫Maintenant, nous devons taper le nom juste pour nous

311
00:15:21,070 --> 00:15:23,413
‫assurer de ne pas faire d'erreurs.

312
00:15:25,110 --> 00:15:27,410
‫Et donc on y va, super.

313
00:15:27,410 --> 00:15:30,050
‫Voilà donc le pouvoir des index.

314
00:15:30,050 --> 00:15:32,420
‫Ils peuvent vraiment améliorer nos performances

315
00:15:32,420 --> 00:15:34,970
‫de lecture sur les bases de données.

316
00:15:34,970 --> 00:15:36,700
‫Et donc, dans vos propres

317
00:15:36,700 --> 00:15:39,460
‫applications, vous ne devriez vraiment jamais les ignorer.

318
00:15:39,460 --> 00:15:42,680
‫Et avant de terminer, reprenons en fait cette

319
00:15:42,680 --> 00:15:45,140
‫méthode d'explication que nous avons

320
00:15:45,140 --> 00:15:47,860
‫ajoutée ici dans notre fonction de gestionnaire.

321
00:15:47,860 --> 00:15:49,430
‫Et en fait, juste à

322
00:15:49,430 --> 00:15:52,283
‫titre de référence, je vais le laisser ici comme ça d'accord.

323
00:15:54,640 --> 00:15:55,543
‫Donnez-lui une sauvegarde.

324
00:15:57,090 --> 00:15:58,133
‫Retour dans le menu des articles.

325
00:15:59,280 --> 00:16:00,773
‫Essayons ça maintenant.

326
00:16:01,670 --> 00:16:04,040
‫Et en effet, c'est de retour au travail.

327
00:16:04,040 --> 00:16:05,763
‫Bon et maintenant c'est vraiment ça.