1
00:00:00,910 --> 00:00:02,310
‫Jonas: Bienvenido de nuevo.

2
00:00:02,310 --> 00:00:04,110
‫Así que ahora hablemos

3
00:00:04,110 --> 00:00:07,540
‫un poco sobre el rendimiento de lectura en MongoDB,

4
00:00:07,540 --> 00:00:10,630
‫por qué algo llamado índices es tan importante

5
00:00:10,630 --> 00:00:13,053
‫y cómo podemos crearlos nosotros mismos.

6
00:00:14,560 --> 00:00:18,540
‫Y quiero comenzar esta demostración sobre índices lanzando una

7
00:00:18,540 --> 00:00:21,873
‫consulta simple en todos nuestros recorridos.

8
00:00:23,500 --> 00:00:26,550
‫Así que vengamos aquí para obtener

9
00:00:26,550 --> 00:00:28,820
‫todos los recorridos y

10
00:00:30,190 --> 00:00:33,803
‫también filtraré por un precio inferior a 1,000.

11
00:00:35,400 --> 00:00:39,393
‫Bien y veamos.

12
00:00:40,900 --> 00:00:43,970
‫Sí, obtenemos tres resultados, de acuerdo.

13
00:00:43,970 --> 00:00:45,950
‫Y eso es importante tenerlo en cuenta

14
00:00:45,950 --> 00:00:48,230
‫para lo que les mostraré a continuación, que

15
00:00:48,230 --> 00:00:51,200
‫es que en realidad también podemos obtener un par de estadísticas

16
00:00:51,200 --> 00:00:53,070
‫sobre la consulta en sí.

17
00:00:53,070 --> 00:00:56,770
‫Vayamos aquí básicamente a la función del controlador.

18
00:00:56,770 --> 00:01:01,523
‫Y entonces esto recuerda ahora mismo en la fábrica de manipuladores.

19
00:01:02,620 --> 00:01:06,033
‫Bien, es esto, creo que está en la

20
00:01:08,100 --> 00:01:09,410
‫parte inferior.

21
00:01:09,410 --> 00:01:12,000
‫Sí, es esto, obtenga todas las funciones de

22
00:01:12,000 --> 00:01:14,290
‫fábrica que crearán este controlador que

23
00:01:14,290 --> 00:01:16,940
‫se llama para la consulta que acabamos de realizar.

24
00:01:16,940 --> 00:01:18,360
‫Y aquí en

25
00:01:18,360 --> 00:01:21,053
‫la consulta, ahora agregaré un método de explicación.

26
00:01:23,640 --> 00:01:28,300
‫De acuerdo, después de la consulta, llamaremos a explicar, de acuerdo.

27
00:01:28,300 --> 00:01:30,603
‫Entonces, echemos un vistazo a eso.

28
00:01:33,710 --> 00:01:36,770
‫Y ahora obtenemos un resultado completamente diferente,

29
00:01:36,770 --> 00:01:39,490
‫que son básicamente estas estadísticas.

30
00:01:39,490 --> 00:01:41,920
‫Ahora hay muchas cosas aquí.

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

32
00:01:43,030 --> 00:01:48,030
‫que realmente me interesa son estas estadísticas de ejecución, está bien.

33
00:01:48,110 --> 00:01:50,230
‫Entonces puede ver aquí que la

34
00:01:50,230 --> 00:01:52,420
‫cantidad de documentos que se devolvieron fueron tres.

35
00:01:52,420 --> 00:01:55,130
‫Y ese es exactamente el resultado que obtuvimos antes.

36
00:01:55,130 --> 00:01:58,030
‫Entonces, antes de hacer la explicación correcta.

37
00:01:58,030 --> 00:02:00,230
‫Pero lo que es realmente importante tener en

38
00:02:00,230 --> 00:02:01,460
‫cuenta aquí es

39
00:02:01,460 --> 00:02:05,180
‫que la cantidad de documentos que se examinaron es nueve, está bien.

40
00:02:05,180 --> 00:02:07,970
‫Y esto significa que MongoDB tuvo que

41
00:02:07,970 --> 00:02:11,200
‫examinar, así que básicamente escanear los nueve documentos

42
00:02:11,200 --> 00:02:13,780
‫para encontrar los tres correctos.

43
00:02:13,780 --> 00:02:17,260
‫Entonces, los tres que coinciden con la consulta están bien.

44
00:02:17,260 --> 00:02:20,320
‫Y eso no es eficiente en absoluto, ¿verdad?

45
00:02:20,320 --> 00:02:21,900
‫Ahora, por supuesto, a

46
00:02:21,900 --> 00:02:25,670
‫esta escala con solo nueve documentos, no hay absolutamente ninguna diferencia.

47
00:02:25,670 --> 00:02:27,740
‫Pero si tuviéramos cientos de

48
00:02:27,740 --> 00:02:30,020
‫miles, o incluso millones de documentos

49
00:02:30,020 --> 00:02:32,010
‫aquí, esto afectaría significativamente

50
00:02:32,010 --> 00:02:34,390
‫el rendimiento de lectura de esta consulta.

51
00:02:34,390 --> 00:02:37,850
‫Entonces, nuevamente, no será el caso en esta aplicación, pero

52
00:02:37,850 --> 00:02:41,210
‫podría ser en una aplicación que creará algún día.

53
00:02:41,210 --> 00:02:44,150
‫Entonces, realmente necesitas aprender acerca de los índices.

54
00:02:44,150 --> 00:02:46,290
‫Porque con los

55
00:02:46,290 --> 00:02:48,530
‫índices podremos resolver este problema.

56
00:02:48,530 --> 00:02:53,020
‫Entonces podemos crear índices en campos específicos en una colección.

57
00:02:53,020 --> 00:02:55,980
‫Por ejemplo, Mongo crea automáticamente un índice en

58
00:02:55,980 --> 00:02:58,640
‫el campo ID de forma predeterminada.

59
00:02:58,640 --> 00:03:02,920
‫Y veamos eso en Compass.

60
00:03:02,920 --> 00:03:07,280
‫Por ejemplo, en todos los recorridos, tenemos aquí la pestaña de índices.

61
00:03:07,280 --> 00:03:09,580
‫Así que hasta este punto solo estuvimos aquí

62
00:03:09,580 --> 00:03:10,810
‫en la pestaña

63
00:03:10,810 --> 00:03:13,550
‫de documentos, pero como ves, tenemos muchas cosas diferentes aquí

64
00:03:13,550 --> 00:03:15,690
‫y una de ellas son los índices.

65
00:03:15,690 --> 00:03:20,410
‫Y de nuevo ves que por defecto tenemos un índice de ID.

66
00:03:20,410 --> 00:03:23,860
‫Y este índice de ID es básicamente una lista ordenada

67
00:03:23,860 --> 00:03:26,380
‫de todas las ID que se almacenan en

68
00:03:26,380 --> 00:03:28,890
‫algún lugar fuera de la colección.

69
00:03:28,890 --> 00:03:30,750
‫Y realmente puede ver

70
00:03:30,750 --> 00:03:35,190
‫un tamaño aquí, que tiene 36 kilobytes, este índice está bien.

71
00:03:35,190 --> 00:03:37,660
‫Y este índice es extremadamente útil.

72
00:03:37,660 --> 00:03:39,830
‫Porque cada vez que los

73
00:03:39,830 --> 00:03:44,140
‫documentos son consultados por el ID, MongoDB buscará ese índice ordenado en lugar de

74
00:03:44,140 --> 00:03:46,390
‫buscar en toda la colección y observará

75
00:03:46,390 --> 00:03:48,660
‫todos los documentos uno por uno, lo

76
00:03:48,660 --> 00:03:50,890
‫que por supuesto es mucho más lento.

77
00:03:50,890 --> 00:03:54,440
‫Entonces, nuevamente, sin un índice, Mongo tiene que mirar

78
00:03:54,440 --> 00:03:56,650
‫cada documento uno por uno.

79
00:03:56,650 --> 00:03:59,830
‫Pero con un índice en el campo que estamos

80
00:03:59,830 --> 00:04:02,810
‫consultando, este proceso se vuelve mucho más eficiente.

81
00:04:02,810 --> 00:04:05,420
‫Entonces eso es bastante inteligente, ¿verdad?

82
00:04:05,420 --> 00:04:08,230
‫Y, por supuesto, podemos establecer nuestros propios índices

83
00:04:08,230 --> 00:04:10,890
‫en campos que consultamos con mucha frecuencia.

84
00:04:10,890 --> 00:04:13,430
‫Entonces, hagamos eso con el campo de

85
00:04:13,430 --> 00:04:15,830
‫precio que acabamos de consultar antes

86
00:04:15,830 --> 00:04:18,800
‫porque creo que es uno de los más importantes

87
00:04:18,800 --> 00:04:21,770
‫por los que la gente consultará, de acuerdo.

88
00:04:21,770 --> 00:04:25,100
‫Y así es como funciona.

89
00:04:25,100 --> 00:04:30,030
‫Así que tenemos que ir al modelo de gira a la derecha.

90
00:04:30,030 --> 00:04:33,290
‫Y luego hagámoslo aquí mismo después de esta declaración interna

91
00:04:34,370 --> 00:04:37,097
‫y decimos tourchema. índice bien.

92
00:04:42,960 --> 00:04:45,600
‫Y luego un objeto con el nombre del

93
00:04:47,070 --> 00:04:49,470
‫campo y recuerda cómo dije que

94
00:04:49,470 --> 00:04:54,470
‫íbamos a establecer el índice en el precio y luego uno o menos uno.

95
00:04:54,500 --> 00:04:57,100
‫Y uno significa que estamos clasificando el

96
00:04:57,100 --> 00:04:58,660
‫índice de precios en

97
00:04:58,660 --> 00:05:02,120
‫orden ascendente, mientras que el menos uno significa orden descendente.

98
00:05:02,120 --> 00:05:05,520
‫Y en realidad también hay otros tipos de índices, como

99
00:05:05,520 --> 00:05:08,280
‫para texto o para datos geoespaciales, pero lo

100
00:05:08,280 --> 00:05:10,260
‫veremos un poco más adelante.

101
00:05:10,260 --> 00:05:13,360
‫Bien, guardemos ahora

102
00:05:13,360 --> 00:05:16,633
‫e intentemos nuestra consulta nuevamente.

103
00:05:17,820 --> 00:05:20,190
‫Y de hecho lo haré un par de

104
00:05:20,190 --> 00:05:22,860
‫veces aquí para asegurarme de que el índice esté realmente configurado.

105
00:05:22,860 --> 00:05:26,950
‫Porque a veces no se configura de inmediato.

106
00:05:26,950 --> 00:05:28,860
‫Pero ahora echemos un vistazo aquí.

107
00:05:28,860 --> 00:05:33,140
‫Y así, de hecho, tenemos todavía nuestro número de devueltos en tres, pero

108
00:05:33,140 --> 00:05:36,260
‫esta vez el número de documentos que se

109
00:05:36,260 --> 00:05:39,490
‫examinaron, por lo que se escanearon, también fueron solo tres.

110
00:05:39,490 --> 00:05:41,540
‫Y eso prueba que con

111
00:05:41,540 --> 00:05:44,310
‫este índice, básicamente logramos exactamente lo que queríamos.

112
00:05:44,310 --> 00:05:47,370
‫Entonces, antes teníamos que escanear los nueve documentos y ahora

113
00:05:47,370 --> 00:05:50,230
‫el motor solo necesita escanear los tres documentos que

114
00:05:50,230 --> 00:05:51,870
‫en realidad también se devuelven.

115
00:05:51,870 --> 00:05:54,080
‫Y nuevamente porque sus precios

116
00:05:54,080 --> 00:05:56,330
‫ahora están ordenados en ese índice.

117
00:05:56,330 --> 00:05:58,890
‫Y eso hace que sea mucho más

118
00:05:58,890 --> 00:06:01,870
‫fácil y mucho más rápido para el motor MongoDB encontrarlos.

119
00:06:01,870 --> 00:06:04,883
‫Y esto es, por supuesto, una gran ganancia de rendimiento.

120
00:06:05,930 --> 00:06:09,300
‫Ahora también echemos un vistazo a Compass aquí,

121
00:06:09,300 --> 00:06:13,060
‫y de hecho recarguemos toda la base de datos, y

122
00:06:13,060 --> 00:06:14,890
‫ahora debería estar aquí,

123
00:06:14,890 --> 00:06:17,750
‫pero por alguna razón no lo está.

124
00:06:17,750 --> 00:06:19,823
‫Quizás intentemos recargar los documentos.

125
00:06:21,040 --> 00:06:22,433
‫Quizás aparezca entonces.

126
00:06:23,910 --> 00:06:26,963
‫En realidad no, analicemos también el esquema, y eso es algo

127
00:06:28,080 --> 00:06:29,260
‫de lo que

128
00:06:29,260 --> 00:06:30,583
‫hablaremos un poco más tarde.

129
00:06:31,420 --> 00:06:34,970
‫Pero aún así, como puede ver, solo tenemos estos dos índices.

130
00:06:34,970 --> 00:06:37,760
‫Pero eso no importa en absoluto porque

131
00:06:37,760 --> 00:06:40,760
‫ya sabemos que el índice realmente funciona, ¿no?

132
00:06:40,760 --> 00:06:41,830
‫Por lo tanto,

133
00:06:41,830 --> 00:06:45,450
‫es completamente normal que a veces esto tarde un poco en actualizarse.

134
00:06:45,450 --> 00:06:48,330
‫Ahora, otra cosa que puede notar aquí es

135
00:06:48,330 --> 00:06:50,690
‫cómo este índice de ID

136
00:06:50,690 --> 00:06:53,830
‫del que hablamos anteriormente dice único aquí, está bien.

137
00:06:53,830 --> 00:06:56,030
‫Y tan único es también una propiedad

138
00:06:56,030 --> 00:06:58,220
‫que podemos dar a los índices.

139
00:06:58,220 --> 00:06:59,950
‫Y esta es realmente la

140
00:06:59,950 --> 00:07:02,550
‫razón por la que los ID siempre deben ser únicos.

141
00:07:02,550 --> 00:07:04,290
‫Así que simplemente porque

142
00:07:04,290 --> 00:07:07,180
‫el índice del ID tiene esta propiedad única.

143
00:07:07,180 --> 00:07:09,970
‫Probablemente también hayas notado que hay un índice

144
00:07:09,970 --> 00:07:11,760
‫para el nombre aquí, ¿verdad?

145
00:07:11,760 --> 00:07:15,600
‫Pero en realidad no lo creamos manualmente nosotros mismos, ¿verdad?

146
00:07:15,600 --> 00:07:17,970
‫Entonces, ¿puedes adivinar por qué está aquí?

147
00:07:17,970 --> 00:07:20,790
‫Bueno, es porque en nuestra definición de esquema, configuramos el

148
00:07:20,790 --> 00:07:23,140
‫campo de nombre para que sea único.

149
00:07:23,140 --> 00:07:25,580
‫Entonces, lo que Mongos hace detrás

150
00:07:25,580 --> 00:07:28,900
‫de escena para garantizar la singularidad de este campo

151
00:07:28,900 --> 00:07:32,170
‫es crear un índice único para él, de acuerdo.

152
00:07:32,170 --> 00:07:34,630
‫Y por eso, no solo la identificación,

153
00:07:34,630 --> 00:07:37,410
‫sino también el nombre siempre deben ser únicos.

154
00:07:37,410 --> 00:07:40,520
‫Está bien y esto ya es genial.

155
00:07:40,520 --> 00:07:42,970
‫Entonces, cuando todo lo que hacemos es solo

156
00:07:42,970 --> 00:07:45,050
‫consultar un solo campo, entonces

157
00:07:45,050 --> 00:07:47,700
‫un índice de un solo campo es perfecto

158
00:07:47,700 --> 00:07:50,010
‫porque recuerde que el índice que acabamos

159
00:07:50,010 --> 00:07:53,200
‫de establecer antes se llama índice de un solo campo.

160
00:07:53,200 --> 00:07:56,770
‫No estoy seguro de si lo mencioné en ese entonces, pero creo que lo hice.

161
00:07:56,770 --> 00:07:59,716
‫Pero de todos modos, si a veces consultamos

162
00:07:59,716 --> 00:08:02,020
‫ese campo pero lo combinamos con

163
00:08:02,020 --> 00:08:03,650
‫otro, entonces es

164
00:08:03,650 --> 00:08:05,930
‫más eficiente crear un índice compuesto.

165
00:08:05,930 --> 00:08:09,210
‫Entonces uno con dos campos y no solo uno.

166
00:08:09,210 --> 00:08:12,883
‫Así que creemos una consulta para eso solo para ilustrarlo.

167
00:08:14,100 --> 00:08:16,000
‫Entonces, otro campo que creo que

168
00:08:16,000 --> 00:08:19,713
‫se va a consultar todo el tiempo es el promedio de calificaciones.

169
00:08:22,470 --> 00:08:27,470
‫Entonces, las calificaciones promedio, creo que así se llama, y digamos que

170
00:08:27,610 --> 00:08:32,610
‫queremos mayor o igual que 4. 7 bien.

171
00:08:35,370 --> 00:08:36,673
‫Enviemos esa consulta.

172
00:08:38,230 --> 00:08:42,163
‫Y veamos cuántos resultados obtenemos.

173
00:08:43,050 --> 00:08:44,440
‫¿Donde es eso?

174
00:08:44,440 --> 00:08:45,400
‫Si aqui.

175
00:08:45,400 --> 00:08:47,010
‫Entonces, el número de

176
00:08:47,010 --> 00:08:49,290
‫resultados, entonces el número de documentos que se

177
00:08:49,290 --> 00:08:51,960
‫devuelven, para que coincidan con esta consulta es dos.

178
00:08:51,960 --> 00:08:55,390
‫Pero todavía teníamos que examinar tres documentos.

179
00:08:55,390 --> 00:08:57,480
‫Y nuevamente, a esta escala, por supuesto,

180
00:08:57,480 --> 00:08:59,250
‫eso no hace ninguna diferencia.

181
00:08:59,250 --> 00:09:01,920
‫Pero como comprenderá, esto es solo un ejemplo.

182
00:09:01,920 --> 00:09:05,150
‫Y ahora queremos arreglar la situación también y

183
00:09:05,150 --> 00:09:07,853
‫para eso usaremos un índice compuesto.

184
00:09:09,010 --> 00:09:10,870
‫Así que volvamos aquí.

185
00:09:10,870 --> 00:09:12,360
‫Comenta este.

186
00:09:12,360 --> 00:09:15,890
‫O en realidad, primero duplíquelo y luego comente.

187
00:09:15,890 --> 00:09:17,500
‫Entonces, en realidad, es muy simple.

188
00:09:17,500 --> 00:09:20,103
‫Todo lo que tenemos que hacer es agregar aquí el otro campo.

189
00:09:21,530 --> 00:09:25,270
‫Así que las calificaciones promedian y pongamos este en

190
00:09:25,270 --> 00:09:26,633
‫orden ascendente.

191
00:09:29,150 --> 00:09:33,160
‫O en realidad, ese es el orden descendente.

192
00:09:33,160 --> 00:09:35,290
‫Así que salvemos esto.

193
00:09:35,290 --> 00:09:37,060
‫Regresemos aquí.

194
00:09:37,060 --> 00:09:41,720
‫Y de nuevo, lo haré un par de veces aquí, de acuerdo.

195
00:09:41,720 --> 00:09:43,970
‫Y veamos nuestros resultados.

196
00:09:43,970 --> 00:09:47,080
‫Y ahora obtenemos el resultado que queríamos.

197
00:09:47,080 --> 00:09:49,880
‫Así que solo se escanearon dos

198
00:09:49,880 --> 00:09:54,010
‫documentos para encontrar los dos documentos que estábamos buscando.

199
00:09:54,010 --> 00:09:57,420
‫Perfecto y, de hecho, este índice compuesto que acabamos de

200
00:09:57,420 --> 00:10:00,700
‫crear también funcionará cuando la consulta para solo uno

201
00:10:00,700 --> 00:10:04,020
‫de estos dos campos aquí individualmente, por lo que

202
00:10:04,020 --> 00:10:06,330
‫el precio o las calificaciones promedian.

203
00:10:06,330 --> 00:10:09,000
‫Entonces, cuando creamos un índice compuesto como

204
00:10:09,000 --> 00:10:11,350
‫este, no tenemos que crear también

205
00:10:11,350 --> 00:10:14,193
‫un individuo para cada uno de los campos.

206
00:10:15,720 --> 00:10:19,603
‫Solo quiero ver cómo se ve ahora en Compass.

207
00:10:21,310 --> 00:10:22,890
‫Pero bueno, todavía se ve igual.

208
00:10:22,890 --> 00:10:25,320
‫Pero de nuevo, no es realmente importante.

209
00:10:25,320 --> 00:10:27,440
‫Una cosa que todavía podemos ver aquí

210
00:10:27,440 --> 00:10:28,933
‫y que es bastante

211
00:10:28,933 --> 00:10:31,663
‫interesante es que en realidad el tamaño de estos índices.

212
00:10:32,640 --> 00:10:36,680
‫Entonces, 72 kilobytes es en realidad mucho más grande que

213
00:10:36,680 --> 00:10:39,930
‫el tamaño total de todos los documentos combinados,

214
00:10:39,930 --> 00:10:42,680
‫que son solo 14 kilobytes, ¿verdad?

215
00:10:42,680 --> 00:10:45,470
‫Básicamente, estos índices que creamos para

216
00:10:45,470 --> 00:10:48,680
‫buscar los documentos ocupan mucho más espacio

217
00:10:48,680 --> 00:10:50,890
‫que los propios documentos.

218
00:10:50,890 --> 00:10:53,530
‫Pero nuevamente, eso es solo porque estamos

219
00:10:53,530 --> 00:10:56,260
‫operando a una escala tan pequeña en este ejemplo.

220
00:10:56,260 --> 00:10:59,300
‫Y eso no es realmente relevante, de acuerdo.

221
00:10:59,300 --> 00:11:01,530
‫Pero sigue siendo importante hablar de

222
00:11:01,530 --> 00:11:05,150
‫esto porque en realidad esto me lleva a nuestra siguiente pregunta.

223
00:11:05,150 --> 00:11:06,510
‫Y esa

224
00:11:06,510 --> 00:11:10,150
‫pregunta es, ¿cómo decidimos qué campo realmente necesitamos indexar?

225
00:11:10,150 --> 00:11:13,710
‫¿Y por qué no establecemos índices en todos los campos?

226
00:11:13,710 --> 00:11:16,720
‫Bueno, usamos la estrategia que usé para

227
00:11:16,720 --> 00:11:20,640
‫establecer los índices en el precio y en la calificación promedio.

228
00:11:20,640 --> 00:11:24,380
‫Entonces, básicamente, necesitamos estudiar cuidadosamente los patrones de acceso

229
00:11:24,380 --> 00:11:27,130
‫de nuestra aplicación para averiguar qué campos

230
00:11:27,130 --> 00:11:29,690
‫son los más consultados y

231
00:11:29,690 --> 00:11:32,530
‫luego establecer los índices para estos campos.

232
00:11:32,530 --> 00:11:36,640
‫Por ejemplo, no estoy configurando un índice aquí sobre el tamaño del

233
00:11:36,640 --> 00:11:38,060
‫grupo porque realmente

234
00:11:38,060 --> 00:11:41,300
‫no creo que muchas personas consulten ese parámetro, por

235
00:11:41,300 --> 00:11:43,890
‫lo que no necesito crear un índice allí.

236
00:11:43,890 --> 00:11:47,930
‫Porque realmente no queremos exagerar con los índices.

237
00:11:47,930 --> 00:11:51,610
‫Por lo tanto, no queremos establecer índices a ciegas en todos los

238
00:11:51,610 --> 00:11:54,110
‫campos y luego esperar lo mejor básicamente.

239
00:11:54,110 --> 00:11:55,420
‫Y la razón

240
00:11:55,420 --> 00:11:58,380
‫de esto es que cada índice realmente usa

241
00:11:58,380 --> 00:12:01,360
‫recursos, como puede ver aquí a la derecha.

242
00:12:01,360 --> 00:12:04,850
‫Además, cada índice debe actualizarse cada vez que

243
00:12:04,850 --> 00:12:07,670
‫se actualiza la colección subyacente.

244
00:12:07,670 --> 00:12:12,150
‫Entonces, si tiene una colección con una alta proporción de escritura y lectura,

245
00:12:12,150 --> 00:12:14,980
‫por lo tanto, una colección en la que

246
00:12:14,980 --> 00:12:17,320
‫se escribe principalmente, entonces no tendría

247
00:12:17,320 --> 00:12:21,150
‫ningún sentido crear un índice en cualquier campo de esta colección

248
00:12:21,150 --> 00:12:23,800
‫porque el costo de actualizar siempre el índice

249
00:12:23,800 --> 00:12:27,060
‫y mantener en la memoria, claramente supera el beneficio de

250
00:12:27,060 --> 00:12:29,550
‫tener el índice en primer lugar si

251
00:12:29,550 --> 00:12:31,750
‫rara vez tenemos búsquedas, por

252
00:12:31,750 --> 00:12:34,240
‫lo que tenemos consultas, para esa colección.

253
00:12:34,240 --> 00:12:36,500
‫Entonces, en resumen, al decidir si

254
00:12:36,500 --> 00:12:38,630
‫indexar un determinado campo o no,

255
00:12:38,630 --> 00:12:40,750
‫debemos equilibrar la frecuencia

256
00:12:40,750 --> 00:12:43,430
‫de las consultas utilizando ese campo exacto

257
00:12:43,430 --> 00:12:46,190
‫con el costo de mantener este índice, y

258
00:12:46,190 --> 00:12:49,910
‫también con el patrón de lectura y escritura del recurso.

259
00:12:49,910 --> 00:12:52,950
‫Sin embargo, al igual que ocurre con el modelado

260
00:12:52,950 --> 00:12:55,460
‫de datos, aquí no existen reglas estrictas.

261
00:12:55,460 --> 00:12:57,240
‫Así que todo es

262
00:12:57,240 --> 00:12:59,530
‫un poco confuso y realmente necesitas un

263
00:12:59,530 --> 00:13:03,030
‫poco de experimentación y también experiencia para hacerlo bien, de acuerdo.

264
00:13:03,030 --> 00:13:06,570
‫Pero hagas lo que hagas, no ignores la indexación.

265
00:13:06,570 --> 00:13:08,550
‫Porque incluso si no

266
00:13:08,550 --> 00:13:12,660
‫es perfecto, siempre tendrá un gran beneficio para su aplicación.

267
00:13:12,660 --> 00:13:14,940
‫De acuerdo, y eso es todo lo que

268
00:13:14,940 --> 00:13:16,903
‫tenía que contarte sobre los índices.

269
00:13:18,230 --> 00:13:21,880
‫Solo hay un índice más que realmente quiero establecer aquí,

270
00:13:21,880 --> 00:13:25,030
‫que es para el tour slug, está bien.

271
00:13:25,030 --> 00:13:26,920
‫Porque más adelante

272
00:13:26,920 --> 00:13:30,250
‫querremos usar la barra única para consultar recorridos.

273
00:13:30,250 --> 00:13:32,680
‫Lo que significa que la babosa probablemente se

274
00:13:32,680 --> 00:13:34,640
‫convertirá en el campo más consultado.

275
00:13:34,640 --> 00:13:35,950
‫Y por eso tiene

276
00:13:35,950 --> 00:13:38,780
‫todo el sentido tener también un índice para ese.

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

278
00:13:45,370 --> 00:13:47,380
‫y slug uno.

279
00:13:47,380 --> 00:13:52,140
‫Y la mayoría de las veces el uno o el menos uno no es tan importante.

280
00:13:52,140 --> 00:13:54,680
‫Bien, ahora tengo mucha curiosidad por intentar

281
00:13:54,680 --> 00:13:56,640
‫ver esto aquí en Compass.

282
00:13:56,640 --> 00:14:00,500
‫Entonces, lo que voy a hacer es intentar conectarme a la base

283
00:14:00,500 --> 00:14:02,043
‫de datos nuevamente aquí.

284
00:14:06,740 --> 00:14:10,083
‫Y entonces puedo obtener eso aquí de los más recientes.

285
00:14:11,360 --> 00:14:14,020
‫Haga clic, conéctese, y luego deberíamos conectarnos a la

286
00:14:14,020 --> 00:14:15,453
‫misma base de datos.

287
00:14:17,260 --> 00:14:21,540
‫Así que natours, tours, vayamos a nuestros índices.

288
00:14:21,540 --> 00:14:23,380
‫Y ahora aquí vamos.

289
00:14:23,380 --> 00:14:26,013
‫Así que ahora tenemos nuestros índices aquí.

290
00:14:27,070 --> 00:14:28,920
‫Entonces, hagamos esta ventana más grande

291
00:14:28,920 --> 00:14:31,290
‫y echemos un vistazo a lo que obtuvimos.

292
00:14:31,290 --> 00:14:33,710
‫Así que aquí tenemos nuestra babosa.

293
00:14:33,710 --> 00:14:36,670
‫Tenemos el precio, que es el primero que establecemos.

294
00:14:36,670 --> 00:14:39,940
‫Y luego también tenemos el precio y las calificaciones promedio,

295
00:14:39,940 --> 00:14:42,610
‫que es compuesto y también ves aquí que

296
00:14:42,610 --> 00:14:45,510
‫este de aquí es ascendente y este es descendente

297
00:14:45,510 --> 00:14:47,740
‫porque tiene el menos uno.

298
00:14:47,740 --> 00:14:49,870
‫Y otra cosa que puede notar es

299
00:14:49,870 --> 00:14:50,880
‫que en realidad

300
00:14:50,880 --> 00:14:53,680
‫ya no tenemos este índice de precios en nuestro código.

301
00:14:53,680 --> 00:14:55,070
‫Pero todavía está aquí.

302
00:14:55,070 --> 00:14:58,630
‫Por lo tanto, no es suficiente eliminar el índice

303
00:14:58,630 --> 00:15:03,430
‫de nuestro código, realmente necesitamos eliminarlo de la base de datos en sí.

304
00:15:03,430 --> 00:15:05,870
‫Así que recuerde que lo teníamos aquí

305
00:15:05,870 --> 00:15:07,460
‫al principio y luego

306
00:15:07,460 --> 00:15:09,780
‫lo comentamos y creamos este nuevo índice

307
00:15:09,780 --> 00:15:12,300
‫compuesto, pero nuevamente el índice está parado aquí.

308
00:15:12,300 --> 00:15:14,430
‫Pero como en realidad

309
00:15:14,430 --> 00:15:18,170
‫ya no lo necesitamos, podemos continuar y eliminarlo correctamente.

310
00:15:18,170 --> 00:15:21,070
‫Ahora tenemos que escribir el nombre solo para asegurarnos

311
00:15:21,070 --> 00:15:23,413
‫de que no cometemos ningún error.

312
00:15:25,110 --> 00:15:27,410
‫Y aquí vamos, genial.

313
00:15:27,410 --> 00:15:30,050
‫Entonces ese es el poder de los índices.

314
00:15:30,050 --> 00:15:32,420
‫Realmente pueden hacer que nuestro rendimiento de

315
00:15:32,420 --> 00:15:34,970
‫lectura en bases de datos sea mucho, mucho mejor.

316
00:15:34,970 --> 00:15:36,700
‫Por tanto, en

317
00:15:36,700 --> 00:15:39,460
‫sus propias aplicaciones, nunca debería ignorarlas.

318
00:15:39,460 --> 00:15:42,680
‫Y antes de terminar, retomemos ese método

319
00:15:42,680 --> 00:15:45,140
‫de explicación que agregamos

320
00:15:45,140 --> 00:15:47,860
‫aquí en nuestra función de controlador.

321
00:15:47,860 --> 00:15:49,430
‫Y de hecho,

322
00:15:49,430 --> 00:15:52,283
‫solo como referencia, lo dejaré aquí así.

323
00:15:54,640 --> 00:15:55,543
‫Dale una oportunidad.

324
00:15:57,090 --> 00:15:58,133
‫Volver al menú de publicaciones.

325
00:15:59,280 --> 00:16:00,773
‫Probemos eso ahora.

326
00:16:01,670 --> 00:16:04,040
‫Y de hecho, ha vuelto a funcionar.

327
00:16:04,040 --> 00:16:05,763
‫Está bien y ahora eso es realmente.