1
00:00:00,910 --> 00:00:02,310
‫Welcome back.

2
00:00:02,310 --> 00:00:04,110
‫So let's now talk a little bit

3
00:00:04,110 --> 00:00:07,540
‫about read performance in MongoDB,

4
00:00:07,540 --> 00:00:10,630
‫why something called indexes are so important,

5
00:00:10,630 --> 00:00:13,053
‫and how we can actually create them ourselves.

6
00:00:14,560 --> 00:00:18,540
‫And I want to start this demonstration about indexes

7
00:00:18,540 --> 00:00:21,873
‫by firing off a simple query on all our tours.

8
00:00:23,500 --> 00:00:26,550
‫So let's come here to get all tours

9
00:00:26,550 --> 00:00:28,820
‫and I will also filter

10
00:00:30,190 --> 00:00:33,803
‫for a price less than 1,000.

11
00:00:35,400 --> 00:00:39,393
‫Okay and so let's see.

12
00:00:40,900 --> 00:00:43,970
‫Yeah, so we get three results back, all right.

13
00:00:43,970 --> 00:00:45,950
‫And that's important to keep in mind

14
00:00:45,950 --> 00:00:48,230
‫for what I'm gonna show you next which is

15
00:00:48,230 --> 00:00:51,200
‫that we can actually also get a couple of statistics

16
00:00:51,200 --> 00:00:53,070
‫about the query itself.

17
00:00:53,070 --> 00:00:56,770
‫So let's go here basically to the handler function.

18
00:00:56,770 --> 00:01:01,523
‫And so this remember right now in the handler factory.

19
00:01:02,620 --> 00:01:06,033
‫Right, so it's this,

20
00:01:08,100 --> 00:01:09,410
‫I think it's at the bottom.

21
00:01:09,410 --> 00:01:12,000
‫Yeah so it's this, get all factory function

22
00:01:12,000 --> 00:01:14,290
‫that will create this handler that is called

23
00:01:14,290 --> 00:01:16,940
‫for the query that we just performed.

24
00:01:16,940 --> 00:01:18,360
‫And so here on the query,

25
00:01:18,360 --> 00:01:21,053
‫I'll actually now add an explain method.

26
00:01:23,640 --> 00:01:28,300
‫Okay so after the query we will then call explain all right.

27
00:01:28,300 --> 00:01:30,603
‫And so let's take a look at that.

28
00:01:33,710 --> 00:01:36,770
‫And so we now get a completely different result,

29
00:01:36,770 --> 00:01:39,490
‫which is basically these statistics.

30
00:01:39,490 --> 00:01:41,920
‫Now there's a lot of stuff in here.

31
00:01:41,920 --> 00:01:43,030
‫But what I'm really interested

32
00:01:43,030 --> 00:01:48,030
‫in is these execution statistics, okay.

33
00:01:48,110 --> 00:01:50,230
‫So you can see here that the number of documents

34
00:01:50,230 --> 00:01:52,420
‫that were returned were three.

35
00:01:52,420 --> 00:01:55,130
‫And so that's exactly the result that we got before.

36
00:01:55,130 --> 00:01:58,030
‫So before doing the explain right.

37
00:01:58,030 --> 00:02:00,230
‫But what's really important to note here is

38
00:02:00,230 --> 00:02:01,460
‫that the number of documents

39
00:02:01,460 --> 00:02:05,180
‫that were examined is nine, okay.

40
00:02:05,180 --> 00:02:07,970
‫And so this means that MongoDB had to examine,

41
00:02:07,970 --> 00:02:11,200
‫so basically to scan all of the nine documents

42
00:02:11,200 --> 00:02:13,780
‫in order to find the correct three ones.

43
00:02:13,780 --> 00:02:17,260
‫So the three ones that match the query okay.

44
00:02:17,260 --> 00:02:20,320
‫And so that's not efficient at all right?

45
00:02:20,320 --> 00:02:21,900
‫Now of course at this scale

46
00:02:21,900 --> 00:02:25,670
‫with only nine documents it makes absolutely no difference.

47
00:02:25,670 --> 00:02:27,740
‫But if we had hundreds of thousands,

48
00:02:27,740 --> 00:02:30,020
‫or even millions of documents here,

49
00:02:30,020 --> 00:02:32,010
‫then this would significantly affect

50
00:02:32,010 --> 00:02:34,390
‫the read performance of this query.

51
00:02:34,390 --> 00:02:37,850
‫So again, it's not going to be the case in this application,

52
00:02:37,850 --> 00:02:41,210
‫but it might be in an app that you will build someday.

53
00:02:41,210 --> 00:02:44,150
‫And so you really need to learn about indexes.

54
00:02:44,150 --> 00:02:46,290
‫Because with indexes, we will be able

55
00:02:46,290 --> 00:02:48,530
‫to kind of solve this problem.

56
00:02:48,530 --> 00:02:53,020
‫So we can create indexes on specific fields in a collection.

57
00:02:53,020 --> 00:02:55,980
‫For example Mongo automatically creates an index

58
00:02:55,980 --> 00:02:58,640
‫on the ID field by default.

59
00:02:58,640 --> 00:03:02,920
‫And let's actually see that in Compass okay.

60
00:03:02,920 --> 00:03:07,280
‫For example in all tours, we have here the indexes tab.

61
00:03:07,280 --> 00:03:09,580
‫So up until this point we only ever were here

62
00:03:09,580 --> 00:03:10,810
‫in the documents tab,

63
00:03:10,810 --> 00:03:13,550
‫but as you see we have a lot of different stuff here

64
00:03:13,550 --> 00:03:15,690
‫and one of them is the indexes.

65
00:03:15,690 --> 00:03:20,410
‫And so again you see that by default we have an ID index.

66
00:03:20,410 --> 00:03:23,860
‫And this ID index is then basically an ordered list

67
00:03:23,860 --> 00:03:26,380
‫of all the IDs that get stored somewhere

68
00:03:26,380 --> 00:03:28,890
‫outside of the collection okay.

69
00:03:28,890 --> 00:03:30,750
‫And you can actually see a size here,

70
00:03:30,750 --> 00:03:35,190
‫that it has 36 kilobytes, this index all right.

71
00:03:35,190 --> 00:03:37,660
‫And this index is extremely useful.

72
00:03:37,660 --> 00:03:39,830
‫Because whenever documents are queried

73
00:03:39,830 --> 00:03:44,140
‫by the ID MongoDB will search that ordered index

74
00:03:44,140 --> 00:03:46,390
‫instead of searching through the whole collection

75
00:03:46,390 --> 00:03:48,660
‫and look at all the documents one by one,

76
00:03:48,660 --> 00:03:50,890
‫which is of course much slower.

77
00:03:50,890 --> 00:03:54,440
‫So again without an index Mongo has to look

78
00:03:54,440 --> 00:03:56,650
‫at each document one by one.

79
00:03:56,650 --> 00:03:59,830
‫But with an index on the field that we are querying for,

80
00:03:59,830 --> 00:04:02,810
‫this process becomes much more efficient.

81
00:04:02,810 --> 00:04:05,420
‫So that is pretty smart, right?

82
00:04:05,420 --> 00:04:08,230
‫And of course, we can set our own indexes

83
00:04:08,230 --> 00:04:10,890
‫on fields that we query very often.

84
00:04:10,890 --> 00:04:13,430
‫So let's actually do that with the price field

85
00:04:13,430 --> 00:04:15,830
‫that we just queried for before

86
00:04:15,830 --> 00:04:18,800
‫because I believe that it is one of the most important

87
00:04:18,800 --> 00:04:21,770
‫that people will query for, okay.

88
00:04:21,770 --> 00:04:25,100
‫And so this is how it works.

89
00:04:25,100 --> 00:04:30,030
‫So we need to go to the tour model right.

90
00:04:30,030 --> 00:04:33,290
‫And then let's do it right here after this inner declaration

91
00:04:34,370 --> 00:04:37,097
‫and we say tourschema.index okay.

92
00:04:42,960 --> 00:04:45,600
‫And then an object with the name of the field

93
00:04:47,070 --> 00:04:49,470
‫and remember how I said we were gonna set the index

94
00:04:49,470 --> 00:04:54,470
‫on the price and then either a one or a minus one.

95
00:04:54,500 --> 00:04:57,100
‫And a one means that we're sorting the price index

96
00:04:57,100 --> 00:04:58,660
‫in an ascending order,

97
00:04:58,660 --> 00:05:02,120
‫while the minus one stands for descending order okay.

98
00:05:02,120 --> 00:05:05,520
‫And there are actually other types of indexes as well,

99
00:05:05,520 --> 00:05:08,280
‫like for text or for geospatial data,

100
00:05:08,280 --> 00:05:10,260
‫but we will see that a bit later.

101
00:05:10,260 --> 00:05:13,360
‫Okay so let's give it a save now

102
00:05:13,360 --> 00:05:16,633
‫and try our query again.

103
00:05:17,820 --> 00:05:20,190
‫And actually I will do it a couple of times here

104
00:05:20,190 --> 00:05:22,860
‫to make sure that the index is really set.

105
00:05:22,860 --> 00:05:26,950
‫Because sometimes it is not set right away.

106
00:05:26,950 --> 00:05:28,860
‫But let's now take a look here.

107
00:05:28,860 --> 00:05:33,140
‫And so indeed we get still our number of returned at three

108
00:05:33,140 --> 00:05:36,260
‫but this time the number of documents that were examined,

109
00:05:36,260 --> 00:05:39,490
‫so that were scanned, were also only three.

110
00:05:39,490 --> 00:05:41,540
‫And so that proves that with this index,

111
00:05:41,540 --> 00:05:44,310
‫we basically achieved exactly what we wanted.

112
00:05:44,310 --> 00:05:47,370
‫So before we had to scan through all of the nine documents

113
00:05:47,370 --> 00:05:50,230
‫and now the engine only needs to scan the three documents

114
00:05:50,230 --> 00:05:51,870
‫that are actually also returned.

115
00:05:51,870 --> 00:05:54,080
‫And again because their prices

116
00:05:54,080 --> 00:05:56,330
‫are now ordered in that index.

117
00:05:56,330 --> 00:05:58,890
‫And so that makes it much easier and much faster

118
00:05:58,890 --> 00:06:01,870
‫for the MongoDB engine to find them.

119
00:06:01,870 --> 00:06:04,883
‫And so this is of course a huge performance gain.

120
00:06:05,930 --> 00:06:09,300
‫Let's now also check out Compass here,

121
00:06:09,300 --> 00:06:13,060
‫and actually let's reload the entire database,

122
00:06:13,060 --> 00:06:14,890
‫and now it should actually be here

123
00:06:14,890 --> 00:06:17,750
‫but for some reason it's not.

124
00:06:17,750 --> 00:06:19,823
‫Let's maybe try to reload the documents.

125
00:06:21,040 --> 00:06:22,433
‫Maybe it appears then.

126
00:06:23,910 --> 00:06:26,963
‫Not really, let's also analyze the schema,

127
00:06:28,080 --> 00:06:29,260
‫and that's something that we're gonna talk

128
00:06:29,260 --> 00:06:30,583
‫about a bit later.

129
00:06:31,420 --> 00:06:34,970
‫But still as you see we still only have these two indexes.

130
00:06:34,970 --> 00:06:37,760
‫But that doesn't matter at all because we already know

131
00:06:37,760 --> 00:06:40,760
‫that the index is actually working right?

132
00:06:40,760 --> 00:06:41,830
‫So it's completely normal

133
00:06:41,830 --> 00:06:45,450
‫that sometimes this takes some time to update.

134
00:06:45,450 --> 00:06:48,330
‫Now another thing that you might notice here is

135
00:06:48,330 --> 00:06:50,690
‫how this ID index that we talked

136
00:06:50,690 --> 00:06:53,830
‫about earlier says unique here okay.

137
00:06:53,830 --> 00:06:56,030
‫And so unique is also a property

138
00:06:56,030 --> 00:06:58,220
‫that we can give to indexes.

139
00:06:58,220 --> 00:06:59,950
‫And this is actually the reason

140
00:06:59,950 --> 00:07:02,550
‫why the IDs have always to be unique.

141
00:07:02,550 --> 00:07:04,290
‫So simply because the index

142
00:07:04,290 --> 00:07:07,180
‫of the ID has this unique property.

143
00:07:07,180 --> 00:07:09,970
‫You probably also noticed that there is an index

144
00:07:09,970 --> 00:07:11,760
‫for the name here right?

145
00:07:11,760 --> 00:07:15,600
‫But we didn't actually create that manually ourselves right?

146
00:07:15,600 --> 00:07:17,970
‫So can you guess why it is here?

147
00:07:17,970 --> 00:07:20,790
‫Well it is because in our schema definition,

148
00:07:20,790 --> 00:07:23,140
‫we set the name field to be unique.

149
00:07:23,140 --> 00:07:25,580
‫And so what Mongos then does behind the scenes

150
00:07:25,580 --> 00:07:28,900
‫in order to ensure the uniqueness of this field is

151
00:07:28,900 --> 00:07:32,170
‫to create a unique index for it, all right.

152
00:07:32,170 --> 00:07:34,630
‫And so because of that, not only the ID

153
00:07:34,630 --> 00:07:37,410
‫but also the name always have to be unique.

154
00:07:37,410 --> 00:07:40,520
‫Okay and this is great already.

155
00:07:40,520 --> 00:07:42,970
‫So when all we ever do is to just query

156
00:07:42,970 --> 00:07:45,050
‫for one single field alone,

157
00:07:45,050 --> 00:07:47,700
‫then a single field index is perfect

158
00:07:47,700 --> 00:07:50,010
‫because remember the index that we just set

159
00:07:50,010 --> 00:07:53,200
‫before is called a single field index.

160
00:07:53,200 --> 00:07:56,770
‫Not sure if I mentioned it back then but I think I did.

161
00:07:56,770 --> 00:07:59,716
‫But anyway, if we sometimes query for that field

162
00:07:59,716 --> 00:08:02,020
‫but combined with another one,

163
00:08:02,020 --> 00:08:03,650
‫then it's actually more efficient

164
00:08:03,650 --> 00:08:05,930
‫to create a compound index.

165
00:08:05,930 --> 00:08:09,210
‫So one with two fields and not just one.

166
00:08:09,210 --> 00:08:12,883
‫So let's create a query for that just to illustrate it.

167
00:08:14,100 --> 00:08:16,000
‫And so another field that I think is going

168
00:08:16,000 --> 00:08:19,713
‫to be queried for all the time is the ratings average.

169
00:08:22,470 --> 00:08:27,470
‫So ratings average, I think that's how it's called,

170
00:08:27,610 --> 00:08:32,610
‫and let's say that we want greater or equal than 4.7 okay.

171
00:08:35,370 --> 00:08:36,673
‫Let's send that query.

172
00:08:38,230 --> 00:08:42,163
‫And let's see how many results we get.

173
00:08:43,050 --> 00:08:44,440
‫Where is that?

174
00:08:44,440 --> 00:08:45,400
‫Yeah here.

175
00:08:45,400 --> 00:08:47,010
‫So the number of results,

176
00:08:47,010 --> 00:08:49,290
‫so the number of documents that are returned,

177
00:08:49,290 --> 00:08:51,960
‫so that match this query is two.

178
00:08:51,960 --> 00:08:55,390
‫But we still had to examine three documents.

179
00:08:55,390 --> 00:08:57,480
‫And again, at this scale of course,

180
00:08:57,480 --> 00:08:59,250
‫that doesn't make any difference.

181
00:08:59,250 --> 00:09:01,920
‫But as you understand, this is just an example.

182
00:09:01,920 --> 00:09:05,150
‫And so now we want to fix the situation as well

183
00:09:05,150 --> 00:09:07,853
‫and for that we're gonna use a compound index.

184
00:09:09,010 --> 00:09:10,870
‫So let's go back here.

185
00:09:10,870 --> 00:09:12,360
‫Comment this one out.

186
00:09:12,360 --> 00:09:15,890
‫Or actually first duplicate it and then comment.

187
00:09:15,890 --> 00:09:17,500
‫And so it's actually very simple.

188
00:09:17,500 --> 00:09:20,103
‫All we need to do is to add here the other field.

189
00:09:21,530 --> 00:09:25,270
‫So ratings average and let's put this one

190
00:09:25,270 --> 00:09:26,633
‫in the ascending order.

191
00:09:29,150 --> 00:09:33,160
‫Or actually, that's the descending order all right.

192
00:09:33,160 --> 00:09:35,290
‫So let's give this a save.

193
00:09:35,290 --> 00:09:37,060
‫Let's go back here.

194
00:09:37,060 --> 00:09:41,720
‫And again, I'm going to do it a couple of times here okay.

195
00:09:41,720 --> 00:09:43,970
‫And let's see our results.

196
00:09:43,970 --> 00:09:47,080
‫And so now we get the result that we wanted.

197
00:09:47,080 --> 00:09:49,880
‫So only two documents were scanned in order

198
00:09:49,880 --> 00:09:54,010
‫to find the two documents that we were actually looking for.

199
00:09:54,010 --> 00:09:57,420
‫Perfect and actually this compound index

200
00:09:57,420 --> 00:10:00,700
‫that we just created is also going to work when the query

201
00:10:00,700 --> 00:10:04,020
‫for just one of these two fields here individually,

202
00:10:04,020 --> 00:10:06,330
‫so price or ratings average.

203
00:10:06,330 --> 00:10:09,000
‫So when we create a compound index like this,

204
00:10:09,000 --> 00:10:11,350
‫we do not have to then create one individual

205
00:10:11,350 --> 00:10:14,193
‫for each of the fields as well okay.

206
00:10:15,720 --> 00:10:19,603
‫I just want to check out how it looks in Compass now.

207
00:10:21,310 --> 00:10:22,890
‫But well it still looks the same.

208
00:10:22,890 --> 00:10:25,320
‫But again, not really important.

209
00:10:25,320 --> 00:10:27,440
‫One thing that we can still see here

210
00:10:27,440 --> 00:10:28,933
‫and which is pretty interesting is

211
00:10:28,933 --> 00:10:31,663
‫that actually the size of these indexes.

212
00:10:32,640 --> 00:10:36,680
‫So 72 kilobytes is actually way bigger

213
00:10:36,680 --> 00:10:39,930
‫than the total size of all the documents combined,

214
00:10:39,930 --> 00:10:42,680
‫which is only 14 kilobyte right?

215
00:10:42,680 --> 00:10:45,470
‫And so basically these indexes that we create

216
00:10:45,470 --> 00:10:48,680
‫to search the documents take up a lot more space

217
00:10:48,680 --> 00:10:50,890
‫than the documents themselves.

218
00:10:50,890 --> 00:10:53,530
‫But again that's just because we're operating

219
00:10:53,530 --> 00:10:56,260
‫on such a small scale in this example.

220
00:10:56,260 --> 00:10:59,300
‫And so that's not really relevant okay.

221
00:10:59,300 --> 00:11:01,530
‫But it's still important to talk about this

222
00:11:01,530 --> 00:11:05,150
‫because actually this leads me to our next question.

223
00:11:05,150 --> 00:11:06,510
‫And that question is,

224
00:11:06,510 --> 00:11:10,150
‫how do we decide which field we actually need to index?

225
00:11:10,150 --> 00:11:13,710
‫And why don't we set indexes on all the fields?

226
00:11:13,710 --> 00:11:16,720
‫Well we kind of used the strategy that I used

227
00:11:16,720 --> 00:11:20,640
‫to set the indexes on the price and on the average rating.

228
00:11:20,640 --> 00:11:24,380
‫So basically we need to carefully study the access patterns

229
00:11:24,380 --> 00:11:27,130
‫of our application in order to figure out

230
00:11:27,130 --> 00:11:29,690
‫which fields are queried the most

231
00:11:29,690 --> 00:11:32,530
‫and then set the indexes for these fields.

232
00:11:32,530 --> 00:11:36,640
‫For example, I'm not setting an index here on the group size

233
00:11:36,640 --> 00:11:38,060
‫because I don't really believe

234
00:11:38,060 --> 00:11:41,300
‫that many people will query for that parameter,

235
00:11:41,300 --> 00:11:43,890
‫and so I don't need to create an index there.

236
00:11:43,890 --> 00:11:47,930
‫Because we really do not want to overdo it with indexes.

237
00:11:47,930 --> 00:11:51,610
‫So we don't want to blindly set indexes on all the fields

238
00:11:51,610 --> 00:11:54,110
‫and then hope for the best basically.

239
00:11:54,110 --> 00:11:55,420
‫And the reason for that is

240
00:11:55,420 --> 00:11:58,380
‫that each index actually uses resources,

241
00:11:58,380 --> 00:12:01,360
‫so as you can actually see here right.

242
00:12:01,360 --> 00:12:04,850
‫And also, each index needs to be updated each time

243
00:12:04,850 --> 00:12:07,670
‫that the underlying collection is updated.

244
00:12:07,670 --> 00:12:12,150
‫So if you have a collection with a high write-read ratio,

245
00:12:12,150 --> 00:12:14,980
‫so a collection that is mostly written to,

246
00:12:14,980 --> 00:12:17,320
‫then it would make absolutely no sense

247
00:12:17,320 --> 00:12:21,150
‫to create an index on any field in this collection

248
00:12:21,150 --> 00:12:23,800
‫because the cost of always updating the index

249
00:12:23,800 --> 00:12:27,060
‫and keeping it in memory clearly outweighs the benefit

250
00:12:27,060 --> 00:12:29,550
‫of having the index in the first place

251
00:12:29,550 --> 00:12:31,750
‫if we rarely have searches,

252
00:12:31,750 --> 00:12:34,240
‫so have queries, for that collection.

253
00:12:34,240 --> 00:12:36,500
‫So in summary, when deciding whether

254
00:12:36,500 --> 00:12:38,630
‫to index a certain field or not,

255
00:12:38,630 --> 00:12:40,750
‫we must kind of balance the frequency

256
00:12:40,750 --> 00:12:43,430
‫of queries using that exact field

257
00:12:43,430 --> 00:12:46,190
‫with the cost of maintaining this index,

258
00:12:46,190 --> 00:12:49,910
‫and also with the read-write pattern of the resource.

259
00:12:49,910 --> 00:12:52,950
‫However, just like it is with data modeling,

260
00:12:52,950 --> 00:12:55,460
‫there are not really hard rules here.

261
00:12:55,460 --> 00:12:57,240
‫So it's all a bit fuzzy

262
00:12:57,240 --> 00:12:59,530
‫and you really need some experimentation

263
00:12:59,530 --> 00:13:03,030
‫and also experience to get it right, all right.

264
00:13:03,030 --> 00:13:06,570
‫But whatever you do, please don't just ignore indexing.

265
00:13:06,570 --> 00:13:08,550
‫Because even if it's not perfect,

266
00:13:08,550 --> 00:13:12,660
‫it will always have a huge benefit for your application.

267
00:13:12,660 --> 00:13:14,940
‫All right, and that's actually all I had

268
00:13:14,940 --> 00:13:16,903
‫to tell you about indexes.

269
00:13:18,230 --> 00:13:21,880
‫There's just one more index that I actually want to set here

270
00:13:21,880 --> 00:13:25,030
‫which is for the tour slug okay.

271
00:13:25,030 --> 00:13:26,920
‫Because later on we will actually want

272
00:13:26,920 --> 00:13:30,250
‫to use the unique slug to query for tours.

273
00:13:30,250 --> 00:13:32,680
‫So meaning that the slug will then probably

274
00:13:32,680 --> 00:13:34,640
‫become the most queried field.

275
00:13:34,640 --> 00:13:35,950
‫And so it makes all the sense

276
00:13:35,950 --> 00:13:38,780
‫to also have an index for that one.

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

278
00:13:45,370 --> 00:13:47,380
‫and slug one.

279
00:13:47,380 --> 00:13:52,140
‫And most times the one or minus one is not that important.

280
00:13:52,140 --> 00:13:54,680
‫Okay now I'm really curious

281
00:13:54,680 --> 00:13:56,640
‫to try to see this here in Compass.

282
00:13:56,640 --> 00:14:00,500
‫So what I'm gonna do is to try to connect

283
00:14:00,500 --> 00:14:02,043
‫to the database again here.

284
00:14:06,740 --> 00:14:10,083
‫And so I can just get that here from the most recent ones.

285
00:14:11,360 --> 00:14:14,020
‫Click, connect, and then we should get connected

286
00:14:14,020 --> 00:14:15,453
‫to the same database.

287
00:14:17,260 --> 00:14:21,540
‫So natours, tours, let's come to our indexes.

288
00:14:21,540 --> 00:14:23,380
‫And now here we go.

289
00:14:23,380 --> 00:14:26,013
‫So now we actually have our indexes right here.

290
00:14:27,070 --> 00:14:28,920
‫So let's make this window bigger

291
00:14:28,920 --> 00:14:31,290
‫and take a look at what we got.

292
00:14:31,290 --> 00:14:33,710
‫So we have our slug here all right.

293
00:14:33,710 --> 00:14:36,670
‫We have the price, which is the first one that we set.

294
00:14:36,670 --> 00:14:39,940
‫And then we also have the price and ratings average,

295
00:14:39,940 --> 00:14:42,610
‫which is compound and you also see here

296
00:14:42,610 --> 00:14:45,510
‫that this one here is ascending and this one is descending

297
00:14:45,510 --> 00:14:47,740
‫because it has the minus one.

298
00:14:47,740 --> 00:14:49,870
‫And another thing you might notice is

299
00:14:49,870 --> 00:14:50,880
‫that actually we no longer

300
00:14:50,880 --> 00:14:53,680
‫have this price index in our code.

301
00:14:53,680 --> 00:14:55,070
‫But it's still here.

302
00:14:55,070 --> 00:14:58,630
‫And so it's not enough to remove the index from our code,

303
00:14:58,630 --> 00:15:03,430
‫we really need to delete it from the database itself right.

304
00:15:03,430 --> 00:15:05,870
‫So remember we had it here in the beginning

305
00:15:05,870 --> 00:15:07,460
‫and then we commented it out

306
00:15:07,460 --> 00:15:09,780
‫and created this new compound index,

307
00:15:09,780 --> 00:15:12,300
‫but again the index is stand still here.

308
00:15:12,300 --> 00:15:14,430
‫But since we actually no longer need it,

309
00:15:14,430 --> 00:15:18,170
‫we can just go ahead and delete it okay.

310
00:15:18,170 --> 00:15:21,070
‫Now we need to type the name just to make sure

311
00:15:21,070 --> 00:15:23,413
‫that we do not do any mistakes.

312
00:15:25,110 --> 00:15:27,410
‫And so here we go, great.

313
00:15:27,410 --> 00:15:30,050
‫So that is the power of indexes.

314
00:15:30,050 --> 00:15:32,420
‫They really can make our read performance

315
00:15:32,420 --> 00:15:34,970
‫on databases much, much better.

316
00:15:34,970 --> 00:15:36,700
‫And so in your own applications

317
00:15:36,700 --> 00:15:39,460
‫you should really never ignore them.

318
00:15:39,460 --> 00:15:42,680
‫And before we finish let's actually take back

319
00:15:42,680 --> 00:15:45,140
‫that explain method that we added here

320
00:15:45,140 --> 00:15:47,860
‫in our handler function.

321
00:15:47,860 --> 00:15:49,430
‫And actually just as a reference,

322
00:15:49,430 --> 00:15:52,283
‫I will leave it here like this okay.

323
00:15:54,640 --> 00:15:55,543
‫Give it a save.

324
00:15:57,090 --> 00:15:58,133
‫Back in post menu.

325
00:15:59,280 --> 00:16:00,773
‫Let's try that now.

326
00:16:01,670 --> 00:16:04,040
‫And indeed, it's back to working.

327
00:16:04,040 --> 00:16:05,763
‫Okay and now that's really it.