﻿1
00:00:00,910 --> 00:00:02,310
‫Jonas: Bem-vindo de volta.

2
00:00:02,310 --> 00:00:04,110
‫Portanto, agora vamos falar

3
00:00:04,110 --> 00:00:07,540
‫um pouco sobre o desempenho de leitura no MongoDB,

4
00:00:07,540 --> 00:00:10,630
‫por que algo chamado de índices é tão

5
00:00:10,630 --> 00:00:13,053
‫importante e como podemos realmente criá-los.

6
00:00:14,560 --> 00:00:18,540
‫E eu quero começar esta demonstração sobre índices disparando uma

7
00:00:18,540 --> 00:00:21,873
‫consulta simples em todos os nossos tours.

8
00:00:23,500 --> 00:00:26,550
‫Então, vamos vir aqui para obter

9
00:00:26,550 --> 00:00:28,820
‫todos os passeios e

10
00:00:30,190 --> 00:00:33,803
‫também filtrarei por um preço inferior a 1.000.

11
00:00:35,400 --> 00:00:39,393
‫Ok e então vamos ver.

12
00:00:40,900 --> 00:00:43,970
‫Sim, obtemos três resultados de volta, certo.

13
00:00:43,970 --> 00:00:45,950
‫E isso é importante ter em

14
00:00:45,950 --> 00:00:48,230
‫mente para o que vou mostrar a

15
00:00:48,230 --> 00:00:51,200
‫seguir, que é que também podemos obter algumas estatísticas

16
00:00:51,200 --> 00:00:53,070
‫sobre a consulta em si.

17
00:00:53,070 --> 00:00:56,770
‫Então, vamos basicamente para a função de manipulador.

18
00:00:56,770 --> 00:01:01,523
‫E então, lembre-se disso agora mesmo na fábrica de manipuladores.

19
00:01:02,620 --> 00:01:06,033
‫Certo, então é isso, eu acho que está

20
00:01:08,100 --> 00:01:09,410
‫no fundo.

21
00:01:09,410 --> 00:01:12,000
‫Sim, é isso, pegue todas as funções de

22
00:01:12,000 --> 00:01:14,290
‫fábrica que irão criar este manipulador que

23
00:01:14,290 --> 00:01:16,940
‫é chamado para a consulta que acabamos de executar.

24
00:01:16,940 --> 00:01:18,360
‫E aqui na consulta,

25
00:01:18,360 --> 00:01:21,053
‫na verdade, agora adicionarei um método de explicação.

26
00:01:23,640 --> 00:01:28,300
‫Ok, então após a consulta iremos então chamar o explain all right.

27
00:01:28,300 --> 00:01:30,603
‫E então vamos dar uma olhada nisso.

28
00:01:33,710 --> 00:01:36,770
‫E agora obtemos um resultado completamente diferente,

29
00:01:36,770 --> 00:01:39,490
‫que são basicamente essas estatísticas.

30
00:01:39,490 --> 00:01:41,920
‫Agora, há um monte de coisas aqui.

31
00:01:41,920 --> 00:01:43,030
‫Mas

32
00:01:43,030 --> 00:01:48,030
‫estou realmente interessado nessas estatísticas de execução, certo.

33
00:01:48,110 --> 00:01:50,230
‫Você pode ver aqui que

34
00:01:50,230 --> 00:01:52,420
‫o número de documentos devolvidos foi três.

35
00:01:52,420 --> 00:01:55,130
‫E esse é exatamente o resultado que obtivemos antes.

36
00:01:55,130 --> 00:01:58,030
‫Então, antes de fazer a explicação certa.

37
00:01:58,030 --> 00:02:00,230
‫Mas o que é realmente importante

38
00:02:00,230 --> 00:02:01,460
‫notar aqui

39
00:02:01,460 --> 00:02:05,180
‫é que o número de documentos examinados é nove, certo.

40
00:02:05,180 --> 00:02:07,970
‫E isso significa que o MongoDB teve

41
00:02:07,970 --> 00:02:11,200
‫que examinar, basicamente, digitalizar todos os nove documentos

42
00:02:11,200 --> 00:02:13,780
‫para encontrar os três corretos.

43
00:02:13,780 --> 00:02:17,260
‫Portanto, os três que correspondem à consulta estão bem.

44
00:02:17,260 --> 00:02:20,320
‫E isso não é nem um pouco eficiente, certo?

45
00:02:20,320 --> 00:02:21,900
‫Agora, é claro, nessa

46
00:02:21,900 --> 00:02:25,670
‫escala, com apenas nove documentos, não faz absolutamente nenhuma diferença.

47
00:02:25,670 --> 00:02:27,740
‫Mas se tivéssemos centenas de

48
00:02:27,740 --> 00:02:30,020
‫milhares, ou mesmo milhões de documentos

49
00:02:30,020 --> 00:02:32,010
‫aqui, isso afetaria significativamente

50
00:02:32,010 --> 00:02:34,390
‫o desempenho de leitura desta consulta.

51
00:02:34,390 --> 00:02:37,850
‫Então, novamente, não será o caso neste aplicativo, mas pode

52
00:02:37,850 --> 00:02:41,210
‫ser em um aplicativo que você criará algum dia.

53
00:02:41,210 --> 00:02:44,150
‫E então você realmente precisa aprender sobre índices.

54
00:02:44,150 --> 00:02:46,290
‫Porque com os índices,

55
00:02:46,290 --> 00:02:48,530
‫poderemos meio que resolver esse problema.

56
00:02:48,530 --> 00:02:53,020
‫Portanto, podemos criar índices em campos específicos em uma coleção.

57
00:02:53,020 --> 00:02:55,980
‫Por exemplo, o Mongo cria automaticamente um

58
00:02:55,980 --> 00:02:58,640
‫índice no campo ID por padrão.

59
00:02:58,640 --> 00:03:02,920
‫E vamos realmente ver que no Compass está bem.

60
00:03:02,920 --> 00:03:07,280
‫Por exemplo, em todos os passeios, temos aqui a guia de índices.

61
00:03:07,280 --> 00:03:09,580
‫Então, até este ponto, nós só estivemos aqui

62
00:03:09,580 --> 00:03:10,810
‫na guia de

63
00:03:10,810 --> 00:03:13,550
‫documentos, mas como você pode ver, temos muitas coisas diferentes

64
00:03:13,550 --> 00:03:15,690
‫aqui e uma delas são os índices.

65
00:03:15,690 --> 00:03:20,410
‫E, novamente, você vê que, por padrão, temos um índice de ID.

66
00:03:20,410 --> 00:03:23,860
‫E esse índice de ID é basicamente uma lista ordenada

67
00:03:23,860 --> 00:03:26,380
‫de todos os IDs que são armazenados

68
00:03:26,380 --> 00:03:28,890
‫em algum lugar fora da coleção.

69
00:03:28,890 --> 00:03:30,750
‫E você pode ver

70
00:03:30,750 --> 00:03:35,190
‫um tamanho aqui, que tem 36 kilobytes, esse índice certo.

71
00:03:35,190 --> 00:03:37,660
‫E este índice é extremamente útil.

72
00:03:37,660 --> 00:03:39,830
‫Porque sempre que os documentos

73
00:03:39,830 --> 00:03:44,140
‫são consultados pelo ID, o MongoDB pesquisa aquele índice ordenado em vez de

74
00:03:44,140 --> 00:03:46,390
‫pesquisar por toda a coleção e olhar

75
00:03:46,390 --> 00:03:48,660
‫todos os documentos um por um, o

76
00:03:48,660 --> 00:03:50,890
‫que é obviamente muito mais lento.

77
00:03:50,890 --> 00:03:54,440
‫Então, novamente, sem um índice, o Mongo precisa olhar

78
00:03:54,440 --> 00:03:56,650
‫cada documento um por um.

79
00:03:56,650 --> 00:03:59,830
‫Mas com um índice no campo que estamos consultando,

80
00:03:59,830 --> 00:04:02,810
‫esse processo se torna muito mais eficiente.

81
00:04:02,810 --> 00:04:05,420
‫Então isso é muito inteligente, certo?

82
00:04:05,420 --> 00:04:08,230
‫E, claro, podemos definir nossos próprios índices

83
00:04:08,230 --> 00:04:10,890
‫em campos que consultamos com frequência.

84
00:04:10,890 --> 00:04:13,430
‫Então, vamos realmente fazer isso com o

85
00:04:13,430 --> 00:04:15,830
‫campo de preço que acabamos

86
00:04:15,830 --> 00:04:18,800
‫de consultar antes, porque acredito que é um

87
00:04:18,800 --> 00:04:21,770
‫dos mais importantes que as pessoas consultarão, certo.

88
00:04:21,770 --> 00:04:25,100
‫E é assim que funciona.

89
00:04:25,100 --> 00:04:30,030
‫Portanto, precisamos ir para o modelo de passeio certo.

90
00:04:30,030 --> 00:04:33,290
‫E então vamos fazer isso bem aqui após esta declaração

91
00:04:34,370 --> 00:04:37,097
‫interna e dizemos tourschema. índice ok.

92
00:04:42,960 --> 00:04:45,600
‫E então um objeto com o nome do

93
00:04:47,070 --> 00:04:49,470
‫campo e lembre-se de como eu

94
00:04:49,470 --> 00:04:54,470
‫disse que iríamos definir o índice do preço e então um ou um menos.

95
00:04:54,500 --> 00:04:57,100
‫E um significa que estamos classificando o

96
00:04:57,100 --> 00:04:58,660
‫índice de preços

97
00:04:58,660 --> 00:05:02,120
‫em ordem crescente, enquanto o menos significa ordem decrescente.

98
00:05:02,120 --> 00:05:05,520
‫Na verdade, também existem outros tipos de índices, como para

99
00:05:05,520 --> 00:05:08,280
‫texto ou para dados geoespaciais, mas veremos

100
00:05:08,280 --> 00:05:10,260
‫isso um pouco mais tarde.

101
00:05:10,260 --> 00:05:13,360
‫Ok, então vamos salvá-lo

102
00:05:13,360 --> 00:05:16,633
‫agora e tentar nossa consulta novamente.

103
00:05:17,820 --> 00:05:20,190
‫E, na verdade, vou fazer isso algumas vezes

104
00:05:20,190 --> 00:05:22,860
‫aqui para ter certeza de que o índice está realmente definido.

105
00:05:22,860 --> 00:05:26,950
‫Porque às vezes não é definido imediatamente.

106
00:05:26,950 --> 00:05:28,860
‫Mas agora vamos dar uma olhada aqui.

107
00:05:28,860 --> 00:05:33,140
‫E assim, de fato, ainda temos nosso número de devolvidos em três, mas

108
00:05:33,140 --> 00:05:36,260
‫desta vez o número de documentos que foram examinados,

109
00:05:36,260 --> 00:05:39,490
‫de modo que foram digitalizados, também foi de apenas três.

110
00:05:39,490 --> 00:05:41,540
‫E isso prova que com

111
00:05:41,540 --> 00:05:44,310
‫esse índice basicamente conseguimos exatamente o que queríamos.

112
00:05:44,310 --> 00:05:47,370
‫Portanto, antes tínhamos que digitalizar todos os nove documentos e

113
00:05:47,370 --> 00:05:50,230
‫agora o mecanismo só precisa digitalizar os três documentos

114
00:05:50,230 --> 00:05:51,870
‫que também foram devolvidos.

115
00:05:51,870 --> 00:05:54,080
‫E novamente porque seus

116
00:05:54,080 --> 00:05:56,330
‫preços agora estão ordenados nesse índice.

117
00:05:56,330 --> 00:05:58,890
‫E isso torna muito mais fácil

118
00:05:58,890 --> 00:06:01,870
‫e rápido para o mecanismo do MongoDB localizá-los.

119
00:06:01,870 --> 00:06:04,883
‫E, portanto, é claro que é um grande ganho de desempenho.

120
00:06:05,930 --> 00:06:09,300
‫Vamos agora também verificar o Compass aqui e, na

121
00:06:09,300 --> 00:06:13,060
‫verdade, vamos recarregar todo o banco de dados, e agora

122
00:06:13,060 --> 00:06:14,890
‫ele realmente deveria estar

123
00:06:14,890 --> 00:06:17,750
‫aqui, mas por algum motivo não está.

124
00:06:17,750 --> 00:06:19,823
‫Vamos tentar recarregar os documentos.

125
00:06:21,040 --> 00:06:22,433
‫Talvez apareça então.

126
00:06:23,910 --> 00:06:26,963
‫Na verdade, não, vamos analisar também o esquema, e isso é

127
00:06:28,080 --> 00:06:29,260
‫algo sobre o qual

128
00:06:29,260 --> 00:06:30,583
‫falaremos um pouco mais tarde.

129
00:06:31,420 --> 00:06:34,970
‫Mas, como você pode ver, ainda temos apenas esses dois índices.

130
00:06:34,970 --> 00:06:37,760
‫Mas isso não importa porque já

131
00:06:37,760 --> 00:06:40,760
‫sabemos que o índice está realmente funcionando direito?

132
00:06:40,760 --> 00:06:41,830
‫Portanto, é

133
00:06:41,830 --> 00:06:45,450
‫completamente normal que às vezes leve algum tempo para atualizar.

134
00:06:45,450 --> 00:06:48,330
‫Agora, outra coisa que você pode notar aqui

135
00:06:48,330 --> 00:06:50,690
‫é como este índice de ID

136
00:06:50,690 --> 00:06:53,830
‫de que falamos anteriormente diz que é único aqui.

137
00:06:53,830 --> 00:06:56,030
‫E tão único também é uma propriedade

138
00:06:56,030 --> 00:06:58,220
‫que podemos dar aos índices.

139
00:06:58,220 --> 00:06:59,950
‫E esta é realmente a

140
00:06:59,950 --> 00:07:02,550
‫razão pela qual os IDs devem ser sempre únicos.

141
00:07:02,550 --> 00:07:04,290
‫Simplesmente porque o

142
00:07:04,290 --> 00:07:07,180
‫índice do ID tem essa propriedade única.

143
00:07:07,180 --> 00:07:09,970
‫Você provavelmente também percebeu que existe um índice

144
00:07:09,970 --> 00:07:11,760
‫para o nome aqui, certo?

145
00:07:11,760 --> 00:07:15,600
‫Mas não criamos isso manualmente, certo?

146
00:07:15,600 --> 00:07:17,970
‫Então você consegue adivinhar por que está aqui?

147
00:07:17,970 --> 00:07:20,790
‫Bem, é porque em nossa definição de esquema, definimos

148
00:07:20,790 --> 00:07:23,140
‫o campo de nome para ser único.

149
00:07:23,140 --> 00:07:25,580
‫E então o que o

150
00:07:25,580 --> 00:07:28,900
‫Mongos faz nos bastidores para garantir a exclusividade desse

151
00:07:28,900 --> 00:07:32,170
‫campo é criar um índice exclusivo para ele, certo.

152
00:07:32,170 --> 00:07:34,630
‫E por isso, não só o ID,

153
00:07:34,630 --> 00:07:37,410
‫mas também o nome sempre tem que ser único.

154
00:07:37,410 --> 00:07:40,520
‫Ok e isso já é ótimo.

155
00:07:40,520 --> 00:07:42,970
‫Portanto, quando tudo o que fazemos é

156
00:07:42,970 --> 00:07:45,050
‫consultar apenas um único campo,

157
00:07:45,050 --> 00:07:47,700
‫um índice de campo único é perfeito porque

158
00:07:47,700 --> 00:07:50,010
‫lembre-se de que o índice que

159
00:07:50,010 --> 00:07:53,200
‫acabamos de definir é chamado de índice de campo único.

160
00:07:53,200 --> 00:07:56,770
‫Não tenho certeza se mencionei isso naquela época, mas acho que sim.

161
00:07:56,770 --> 00:07:59,716
‫Mas, de qualquer forma, se às vezes consultarmos

162
00:07:59,716 --> 00:08:02,020
‫esse campo, mas combiná-lo com outro,

163
00:08:02,020 --> 00:08:03,650
‫então é realmente

164
00:08:03,650 --> 00:08:05,930
‫mais eficiente criar um índice composto.

165
00:08:05,930 --> 00:08:09,210
‫Portanto, um com dois campos e não apenas um.

166
00:08:09,210 --> 00:08:12,883
‫Então, vamos criar uma consulta para isso apenas para ilustrar.

167
00:08:14,100 --> 00:08:16,000
‫E então outro campo que

168
00:08:16,000 --> 00:08:19,713
‫acho que será consultado o tempo todo é a média de avaliações.

169
00:08:22,470 --> 00:08:27,470
‫Portanto, as classificações médias, acho que é assim que se chama, e digamos que

170
00:08:27,610 --> 00:08:32,610
‫queremos maior ou igual a 4. 7 ok.

171
00:08:35,370 --> 00:08:36,673
‫Vamos enviar essa consulta.

172
00:08:38,230 --> 00:08:42,163
‫E vamos ver quantos resultados obteremos.

173
00:08:43,050 --> 00:08:44,440
‫Onde fica isso?

174
00:08:44,440 --> 00:08:45,400
‫Sim aqui.

175
00:08:45,400 --> 00:08:47,010
‫Então, o número de

176
00:08:47,010 --> 00:08:49,290
‫resultados, então o número de documentos que são

177
00:08:49,290 --> 00:08:51,960
‫retornados, para que correspondam a esta consulta, é dois.

178
00:08:51,960 --> 00:08:55,390
‫Mas ainda tivemos que examinar três documentos.

179
00:08:55,390 --> 00:08:57,480
‫E de novo, nessa escala, é claro,

180
00:08:57,480 --> 00:08:59,250
‫isso não faz nenhuma diferença.

181
00:08:59,250 --> 00:09:01,920
‫Mas, como você entende, este é apenas um exemplo.

182
00:09:01,920 --> 00:09:05,150
‫E agora queremos corrigir a situação também e,

183
00:09:05,150 --> 00:09:07,853
‫para isso, usaremos um índice composto.

184
00:09:09,010 --> 00:09:10,870
‫Então, vamos voltar aqui.

185
00:09:10,870 --> 00:09:12,360
‫Comente este aqui.

186
00:09:12,360 --> 00:09:15,890
‫Ou, na verdade, primeiro duplique-o e depois comente.

187
00:09:15,890 --> 00:09:17,500
‫E, na verdade, é muito simples.

188
00:09:17,500 --> 00:09:20,103
‫Tudo o que precisamos fazer é adicionar aqui o outro campo.

189
00:09:21,530 --> 00:09:25,270
‫Então, as avaliações são médias e vamos colocar esta

190
00:09:25,270 --> 00:09:26,633
‫em ordem crescente.

191
00:09:29,150 --> 00:09:33,160
‫Ou, na verdade, essa é a ordem decrescente, certo.

192
00:09:33,160 --> 00:09:35,290
‫Então, vamos salvar isso.

193
00:09:35,290 --> 00:09:37,060
‫Vamos voltar aqui.

194
00:09:37,060 --> 00:09:41,720
‫E, novamente, vou fazer isso algumas vezes aqui, certo.

195
00:09:41,720 --> 00:09:43,970
‫E vamos ver nossos resultados.

196
00:09:43,970 --> 00:09:47,080
‫E agora temos o resultado que queríamos.

197
00:09:47,080 --> 00:09:49,880
‫Portanto, apenas dois documentos foram digitalizados

198
00:09:49,880 --> 00:09:54,010
‫para localizar os dois documentos que estávamos realmente procurando.

199
00:09:54,010 --> 00:09:57,420
‫Perfeito e, na verdade, este índice composto que acabamos

200
00:09:57,420 --> 00:10:00,700
‫de criar também vai funcionar quando a consulta de

201
00:10:00,700 --> 00:10:04,020
‫apenas um desses dois campos aqui individualmente, ou seja,

202
00:10:04,020 --> 00:10:06,330
‫média de preço ou classificação.

203
00:10:06,330 --> 00:10:09,000
‫Portanto, quando criamos um índice composto como

204
00:10:09,000 --> 00:10:11,350
‫este, não precisamos criar um

205
00:10:11,350 --> 00:10:14,193
‫indivíduo para cada um dos campos, ok.

206
00:10:15,720 --> 00:10:19,603
‫Eu só quero verificar como fica no Compass agora.

207
00:10:21,310 --> 00:10:22,890
‫Mas bem, ainda parece o mesmo.

208
00:10:22,890 --> 00:10:25,320
‫Mas, novamente, não é realmente importante.

209
00:10:25,320 --> 00:10:27,440
‫Uma coisa que ainda podemos ver

210
00:10:27,440 --> 00:10:28,933
‫aqui e que

211
00:10:28,933 --> 00:10:31,663
‫é bem interessante é o tamanho desses índices.

212
00:10:32,640 --> 00:10:36,680
‫Portanto, 72 kilobytes é, na verdade, muito maior do que

213
00:10:36,680 --> 00:10:39,930
‫o tamanho total de todos os documentos combinados,

214
00:10:39,930 --> 00:10:42,680
‫que é apenas 14 kilobytes, certo?

215
00:10:42,680 --> 00:10:45,470
‫Basicamente, esses índices que criamos para

216
00:10:45,470 --> 00:10:48,680
‫pesquisar os documentos ocupam muito mais espaço do

217
00:10:48,680 --> 00:10:50,890
‫que os próprios documentos.

218
00:10:50,890 --> 00:10:53,530
‫Mas, novamente, isso é apenas porque estamos

219
00:10:53,530 --> 00:10:56,260
‫operando em uma escala muito pequena neste exemplo.

220
00:10:56,260 --> 00:10:59,300
‫E isso não é realmente relevante, ok.

221
00:10:59,300 --> 00:11:01,530
‫Mas ainda é importante falar sobre

222
00:11:01,530 --> 00:11:05,150
‫isso porque, na verdade, isso me leva à nossa próxima pergunta.

223
00:11:05,150 --> 00:11:06,510
‫E a

224
00:11:06,510 --> 00:11:10,150
‫questão é: como decidimos qual campo realmente precisamos indexar?

225
00:11:10,150 --> 00:11:13,710
‫E por que não definimos índices em todos os campos?

226
00:11:13,710 --> 00:11:16,720
‫Bem, meio que usamos a estratégia que

227
00:11:16,720 --> 00:11:20,640
‫usei para definir os índices de preço e avaliação média.

228
00:11:20,640 --> 00:11:24,380
‫Então, basicamente, precisamos estudar cuidadosamente os padrões de acesso

229
00:11:24,380 --> 00:11:27,130
‫de nosso aplicativo para descobrir quais campos

230
00:11:27,130 --> 00:11:29,690
‫são mais consultados e, em

231
00:11:29,690 --> 00:11:32,530
‫seguida, definir os índices para esses campos.

232
00:11:32,530 --> 00:11:36,640
‫Por exemplo, não estou definindo um índice aqui no tamanho do grupo

233
00:11:36,640 --> 00:11:38,060
‫porque não acredito

234
00:11:38,060 --> 00:11:41,300
‫realmente que muitas pessoas irão consultar esse parâmetro e,

235
00:11:41,300 --> 00:11:43,890
‫portanto, não preciso criar um índice lá.

236
00:11:43,890 --> 00:11:47,930
‫Porque realmente não queremos exagerar nos índices.

237
00:11:47,930 --> 00:11:51,610
‫Portanto, não queremos definir índices cegamente em todos os

238
00:11:51,610 --> 00:11:54,110
‫campos e, basicamente, esperar o melhor.

239
00:11:54,110 --> 00:11:55,420
‫E a razão

240
00:11:55,420 --> 00:11:58,380
‫para isso é que cada índice realmente

241
00:11:58,380 --> 00:12:01,360
‫usa recursos, como você pode ver aqui direito.

242
00:12:01,360 --> 00:12:04,850
‫Além disso, cada índice precisa ser atualizado sempre

243
00:12:04,850 --> 00:12:07,670
‫que a coleção subjacente for atualizada.

244
00:12:07,670 --> 00:12:12,150
‫Portanto, se você tem uma coleção com uma alta proporção de leitura

245
00:12:12,150 --> 00:12:14,980
‫e gravação, ou seja, uma coleção que é

246
00:12:14,980 --> 00:12:17,320
‫principalmente gravada, então não faria absolutamente

247
00:12:17,320 --> 00:12:21,150
‫nenhum sentido criar um índice em qualquer campo desta coleção, porque

248
00:12:21,150 --> 00:12:23,800
‫o custo de sempre atualizar o índice

249
00:12:23,800 --> 00:12:27,060
‫e manter ele na memória claramente supera o benefício

250
00:12:27,060 --> 00:12:29,550
‫de ter o índice em primeiro lugar

251
00:12:29,550 --> 00:12:31,750
‫se raramente temos pesquisas,

252
00:12:31,750 --> 00:12:34,240
‫portanto, temos consultas para essa coleção.

253
00:12:34,240 --> 00:12:36,500
‫Portanto, em resumo, ao decidir se

254
00:12:36,500 --> 00:12:38,630
‫indexar um determinado campo ou não,

255
00:12:38,630 --> 00:12:40,750
‫devemos meio que equilibrar a

256
00:12:40,750 --> 00:12:43,430
‫frequência das consultas usando aquele campo exato

257
00:12:43,430 --> 00:12:46,190
‫com o custo de manutenção desse índice e

258
00:12:46,190 --> 00:12:49,910
‫também com o padrão de leitura e gravação do recurso.

259
00:12:49,910 --> 00:12:52,950
‫No entanto, assim como acontece com a modelagem de

260
00:12:52,950 --> 00:12:55,460
‫dados, não existem regras realmente rígidas aqui.

261
00:12:55,460 --> 00:12:57,240
‫Então é tudo um

262
00:12:57,240 --> 00:12:59,530
‫pouco confuso e você realmente precisa

263
00:12:59,530 --> 00:13:03,030
‫de alguma experimentação e também experiência para acertar, tudo bem.

264
00:13:03,030 --> 00:13:06,570
‫Mas faça o que fizer, não ignore apenas a indexação.

265
00:13:06,570 --> 00:13:08,550
‫Porque mesmo que não

266
00:13:08,550 --> 00:13:12,660
‫seja perfeito, sempre terá um grande benefício para sua aplicação.

267
00:13:12,660 --> 00:13:14,940
‫Tudo bem, e isso é tudo o

268
00:13:14,940 --> 00:13:16,903
‫que tenho a dizer sobre índices.

269
00:13:18,230 --> 00:13:21,880
‫Há apenas mais um índice que desejo definir aqui,

270
00:13:21,880 --> 00:13:25,030
‫que é para o tour ok.

271
00:13:25,030 --> 00:13:26,920
‫Porque mais tarde iremos realmente

272
00:13:26,920 --> 00:13:30,250
‫querer usar o slug exclusivo para consultar os passeios.

273
00:13:30,250 --> 00:13:32,680
‫Isso significa que o slug provavelmente se

274
00:13:32,680 --> 00:13:34,640
‫tornará o campo mais consultado.

275
00:13:34,640 --> 00:13:35,950
‫E, portanto, faz

276
00:13:35,950 --> 00:13:38,780
‫todo o sentido também ter um índice para aquele.

277
00:13:38,780 --> 00:13:41,460
‫Portanto, tourschema. índice

278
00:13:45,370 --> 00:13:47,380
‫e slug um.

279
00:13:47,380 --> 00:13:52,140
‫E na maioria das vezes, um ou menos não é tão importante.

280
00:13:52,140 --> 00:13:54,680
‫Ok, agora estou realmente curioso para tentar

281
00:13:54,680 --> 00:13:56,640
‫ver isso aqui no Compass.

282
00:13:56,640 --> 00:14:00,500
‫Então, o que vou fazer é tentar me conectar ao banco

283
00:14:00,500 --> 00:14:02,043
‫de dados novamente aqui.

284
00:14:06,740 --> 00:14:10,083
‫E posso pegar aqui apenas a partir dos mais recentes.

285
00:14:11,360 --> 00:14:14,020
‫Clique, conecte e então devemos nos conectar ao

286
00:14:14,020 --> 00:14:15,453
‫mesmo banco de dados.

287
00:14:17,260 --> 00:14:21,540
‫Então, natours, tours, vamos aos nossos índices.

288
00:14:21,540 --> 00:14:23,380
‫E agora vamos nós.

289
00:14:23,380 --> 00:14:26,013
‫Portanto, agora temos nossos índices bem aqui.

290
00:14:27,070 --> 00:14:28,920
‫Então, vamos aumentar esta janela

291
00:14:28,920 --> 00:14:31,290
‫e dar uma olhada no que temos.

292
00:14:31,290 --> 00:14:33,710
‫Portanto, temos nossa lesma aqui.

293
00:14:33,710 --> 00:14:36,670
‫Temos o preço, que é o primeiro que definimos.

294
00:14:36,670 --> 00:14:39,940
‫E também temos a média de preços e avaliações,

295
00:14:39,940 --> 00:14:42,610
‫que é composta e você também vê aqui

296
00:14:42,610 --> 00:14:45,510
‫que este aqui é crescente e este está

297
00:14:45,510 --> 00:14:47,740
‫decrescente porque tem o menos.

298
00:14:47,740 --> 00:14:49,870
‫E outra coisa que você pode notar é

299
00:14:49,870 --> 00:14:50,880
‫que, na verdade,

300
00:14:50,880 --> 00:14:53,680
‫não temos mais esse índice de preços em nosso código.

301
00:14:53,680 --> 00:14:55,070
‫Mas ainda está aqui.

302
00:14:55,070 --> 00:14:58,630
‫E, portanto, não é suficiente remover o índice

303
00:14:58,630 --> 00:15:03,430
‫do nosso código, realmente precisamos excluí-lo do próprio banco de dados direito.

304
00:15:03,430 --> 00:15:05,870
‫Portanto, lembre-se de que o tínhamos aqui

305
00:15:05,870 --> 00:15:07,460
‫no início e, em

306
00:15:07,460 --> 00:15:09,780
‫seguida, comentamos e criamos este novo índice

307
00:15:09,780 --> 00:15:12,300
‫composto, mas novamente o índice está parado aqui.

308
00:15:12,300 --> 00:15:14,430
‫Mas, como não precisamos

309
00:15:14,430 --> 00:15:18,170
‫mais dele, podemos simplesmente ir em frente e excluí-lo.

310
00:15:18,170 --> 00:15:21,070
‫Agora precisamos digitar o nome apenas para ter

311
00:15:21,070 --> 00:15:23,413
‫certeza de que não cometemos erros.

312
00:15:25,110 --> 00:15:27,410
‫E aqui vamos nós, ótimo.

313
00:15:27,410 --> 00:15:30,050
‫Então esse é o poder dos índices.

314
00:15:30,050 --> 00:15:32,420
‫Eles realmente podem tornar nosso desempenho de

315
00:15:32,420 --> 00:15:34,970
‫leitura em bancos de dados muito, muito melhor.

316
00:15:34,970 --> 00:15:36,700
‫E, portanto, em

317
00:15:36,700 --> 00:15:39,460
‫seus próprios aplicativos, você nunca deve ignorá-los.

318
00:15:39,460 --> 00:15:42,680
‫E antes de terminar, vamos retomar aquele

319
00:15:42,680 --> 00:15:45,140
‫método de explicação que adicionamos

320
00:15:45,140 --> 00:15:47,860
‫aqui em nossa função de manipulador.

321
00:15:47,860 --> 00:15:49,430
‫E, na verdade,

322
00:15:49,430 --> 00:15:52,283
‫apenas como referência, vou deixar aqui assim, ok.

323
00:15:54,640 --> 00:15:55,543
‫Dê uma chance.

324
00:15:57,090 --> 00:15:58,133
‫De volta ao menu de postagens.

325
00:15:59,280 --> 00:16:00,773
‫Vamos tentar isso agora.

326
00:16:01,670 --> 00:16:04,040
‫E, de fato, ele voltou a funcionar.

327
00:16:04,040 --> 00:16:05,763
‫Ok e agora é isso mesmo.

