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

2
00:00:02,310 --> 00:00:04,110
‫Quindi ora parliamo

3
00:00:04,110 --> 00:00:07,540
‫un po' delle prestazioni di lettura in MongoDB,

4
00:00:07,540 --> 00:00:10,630
‫perché qualcosa chiamato indici è così importante e

5
00:00:10,630 --> 00:00:13,053
‫come possiamo effettivamente crearli noi stessi.

6
00:00:14,560 --> 00:00:18,540
‫E voglio iniziare questa dimostrazione sugli indici lanciando una

7
00:00:18,540 --> 00:00:21,873
‫semplice query su tutti i nostri tour.

8
00:00:23,500 --> 00:00:26,550
‫Quindi veniamo qui per ottenere tutti

9
00:00:26,550 --> 00:00:28,820
‫i tour e filtrerò

10
00:00:30,190 --> 00:00:33,803
‫anche per un prezzo inferiore a 1.000.

11
00:00:35,400 --> 00:00:39,393
‫Ok e allora vediamo.

12
00:00:40,900 --> 00:00:43,970
‫Sì, quindi otteniamo tre risultati indietro, va bene.

13
00:00:43,970 --> 00:00:45,950
‫E questo è importante da tenere

14
00:00:45,950 --> 00:00:48,230
‫a mente per ciò che ti mostrerò

15
00:00:48,230 --> 00:00:51,200
‫in seguito, ovvero che possiamo anche ottenere un paio

16
00:00:51,200 --> 00:00:53,070
‫di statistiche sulla query stessa.

17
00:00:53,070 --> 00:00:56,770
‫Quindi andiamo qui fondamentalmente alla funzione handler.

18
00:00:56,770 --> 00:01:01,523
‫E quindi questo ricordalo adesso nella fabbrica di manipolatori.

19
00:01:02,620 --> 00:01:06,033
‫Giusto, quindi è questo, penso che sia

20
00:01:08,100 --> 00:01:09,410
‫in fondo.

21
00:01:09,410 --> 00:01:12,000
‫Sì, quindi è questo, ottieni tutte le funzioni

22
00:01:12,000 --> 00:01:14,290
‫di fabbrica che creeranno questo gestore che

23
00:01:14,290 --> 00:01:16,940
‫viene chiamato per la query che abbiamo appena eseguito.

24
00:01:16,940 --> 00:01:18,360
‫E quindi qui

25
00:01:18,360 --> 00:01:21,053
‫sulla query, ora aggiungerò un metodo di spiegazione.

26
00:01:23,640 --> 00:01:28,300
‫Va bene, quindi dopo la query chiameremo spiega tutto bene.

27
00:01:28,300 --> 00:01:30,603
‫E quindi diamo un'occhiata a questo.

28
00:01:33,710 --> 00:01:36,770
‫E così ora otteniamo un risultato completamente

29
00:01:36,770 --> 00:01:39,490
‫diverso, che sostanzialmente sono queste statistiche.

30
00:01:39,490 --> 00:01:41,920
‫Ora c'è un sacco di roba qui dentro.

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

32
00:01:43,030 --> 00:01:48,030
‫che mi interessa davvero sono queste statistiche di esecuzione, ok.

33
00:01:48,110 --> 00:01:50,230
‫Quindi puoi vedere qui che il numero

34
00:01:50,230 --> 00:01:52,420
‫di documenti che sono stati restituiti era tre.

35
00:01:52,420 --> 00:01:55,130
‫E quindi questo è esattamente il risultato che abbiamo ottenuto prima.

36
00:01:55,130 --> 00:01:58,030
‫Quindi, prima di spiegare bene.

37
00:01:58,030 --> 00:02:00,230
‫Ma ciò che è veramente importante notare

38
00:02:00,230 --> 00:02:01,460
‫qui è che

39
00:02:01,460 --> 00:02:05,180
‫il numero di documenti che sono stati esaminati è nove, ok.

40
00:02:05,180 --> 00:02:07,970
‫E quindi questo significa che MongoDB ha

41
00:02:07,970 --> 00:02:11,200
‫dovuto esaminare, quindi fondamentalmente scansionare tutti e nove i

42
00:02:11,200 --> 00:02:13,780
‫documenti per trovare i tre corretti.

43
00:02:13,780 --> 00:02:17,260
‫Quindi i tre che corrispondono alla query vanno bene.

44
00:02:17,260 --> 00:02:20,320
‫E quindi non è per niente efficiente, giusto?

45
00:02:20,320 --> 00:02:21,900
‫Ora, ovviamente, a questa

46
00:02:21,900 --> 00:02:25,670
‫scala con solo nove documenti non fa assolutamente alcuna differenza.

47
00:02:25,670 --> 00:02:27,740
‫Ma se avessimo centinaia di migliaia

48
00:02:27,740 --> 00:02:30,020
‫o addirittura milioni di documenti qui, ciò

49
00:02:30,020 --> 00:02:32,010
‫influenzerebbe in modo significativo

50
00:02:32,010 --> 00:02:34,390
‫le prestazioni di lettura di questa query.

51
00:02:34,390 --> 00:02:37,850
‫Quindi, di nuovo, non sarà il caso in questa applicazione,

52
00:02:37,850 --> 00:02:41,210
‫ma potrebbe essere in un'app che creerai un giorno.

53
00:02:41,210 --> 00:02:44,150
‫E quindi hai davvero bisogno di conoscere gli indici.

54
00:02:44,150 --> 00:02:46,290
‫Perché con gli indici, saremo

55
00:02:46,290 --> 00:02:48,530
‫in grado di risolvere questo problema.

56
00:02:48,530 --> 00:02:53,020
‫Quindi possiamo creare indici su campi specifici in una raccolta.

57
00:02:53,020 --> 00:02:55,980
‫Ad esempio Mongo crea automaticamente un indice

58
00:02:55,980 --> 00:02:58,640
‫sul campo ID per impostazione predefinita.

59
00:02:58,640 --> 00:03:02,920
‫E vediamo davvero che in Compass va bene.

60
00:03:02,920 --> 00:03:07,280
‫Ad esempio in tutti i tour, abbiamo qui la scheda degli indici.

61
00:03:07,280 --> 00:03:09,580
‫Quindi fino a questo punto eravamo solo

62
00:03:09,580 --> 00:03:10,810
‫qui nella scheda

63
00:03:10,810 --> 00:03:13,550
‫documenti, ma come vedi qui abbiamo molte cose diverse

64
00:03:13,550 --> 00:03:15,690
‫e una di queste sono gli indici.

65
00:03:15,690 --> 00:03:20,410
‫E così di nuovo vedi che per impostazione predefinita abbiamo un indice ID.

66
00:03:20,410 --> 00:03:23,860
‫E questo indice ID è quindi fondamentalmente un elenco ordinato di

67
00:03:23,860 --> 00:03:26,380
‫tutti gli ID che vengono archiviati da qualche

68
00:03:26,380 --> 00:03:28,890
‫parte al di fuori della raccolta.

69
00:03:28,890 --> 00:03:30,750
‫E puoi effettivamente vedere

70
00:03:30,750 --> 00:03:35,190
‫una dimensione qui, che ha 36 kilobyte, questo indice va bene.

71
00:03:35,190 --> 00:03:37,660
‫E questo indice è estremamente utile.

72
00:03:37,660 --> 00:03:39,830
‫Perché ogni volta che

73
00:03:39,830 --> 00:03:44,140
‫i documenti vengono interrogati dall'ID MongoDB cercherà quell'indice ordinato invece di

74
00:03:44,140 --> 00:03:46,390
‫cercare nell'intera raccolta e guardare tutti

75
00:03:46,390 --> 00:03:48,660
‫i documenti uno per uno, il

76
00:03:48,660 --> 00:03:50,890
‫che ovviamente è molto più lento.

77
00:03:50,890 --> 00:03:54,440
‫Quindi, ancora una volta senza un indice, Mongo deve guardare

78
00:03:54,440 --> 00:03:56,650
‫ogni documento uno per uno.

79
00:03:56,650 --> 00:03:59,830
‫Ma con un indice sul campo che stiamo

80
00:03:59,830 --> 00:04:02,810
‫cercando, questo processo diventa molto più efficiente.

81
00:04:02,810 --> 00:04:05,420
‫Quindi è abbastanza intelligente, giusto?

82
00:04:05,420 --> 00:04:08,230
‫E, naturalmente, possiamo impostare i nostri indici

83
00:04:08,230 --> 00:04:10,890
‫sui campi che interroghiamo molto spesso.

84
00:04:10,890 --> 00:04:13,430
‫Quindi facciamolo in realtà con il campo

85
00:04:13,430 --> 00:04:15,830
‫del prezzo che abbiamo appena

86
00:04:15,830 --> 00:04:18,800
‫interrogato prima perché credo che sia uno dei

87
00:04:18,800 --> 00:04:21,770
‫più importanti per cui le persone interrogheranno, ok.

88
00:04:21,770 --> 00:04:25,100
‫E quindi è così che funziona.

89
00:04:25,100 --> 00:04:30,030
‫Quindi dobbiamo andare al modello del tour giusto.

90
00:04:30,030 --> 00:04:33,290
‫E poi facciamolo qui dopo questa dichiarazione interiore

91
00:04:34,370 --> 00:04:37,097
‫e diciamo tourchema. indice ok.

92
00:04:42,960 --> 00:04:45,600
‫E poi un oggetto con il nome

93
00:04:47,070 --> 00:04:49,470
‫del campo e ricorda come ho

94
00:04:49,470 --> 00:04:54,470
‫detto che avremmo impostato l'indice sul prezzo e poi uno o uno meno.

95
00:04:54,500 --> 00:04:57,100
‫E uno significa che stiamo ordinando l'indice dei

96
00:04:57,100 --> 00:04:58,660
‫prezzi in ordine crescente,

97
00:04:58,660 --> 00:05:02,120
‫mentre il meno uno sta per ordine decrescente, va bene.

98
00:05:02,120 --> 00:05:05,520
‫E in realtà ci sono anche altri tipi di indici, come

99
00:05:05,520 --> 00:05:08,280
‫per il testo o per i dati geospaziali, ma

100
00:05:08,280 --> 00:05:10,260
‫lo vedremo un po' più avanti.

101
00:05:10,260 --> 00:05:13,360
‫Ok, salviamolo ora

102
00:05:13,360 --> 00:05:16,633
‫e riproviamo la nostra query.

103
00:05:17,820 --> 00:05:20,190
‫E in realtà lo farò un paio

104
00:05:20,190 --> 00:05:22,860
‫di volte qui per assicurarmi che l'indice sia davvero impostato.

105
00:05:22,860 --> 00:05:26,950
‫Perché a volte non è impostato subito.

106
00:05:26,950 --> 00:05:28,860
‫Ma ora diamo un'occhiata qui.

107
00:05:28,860 --> 00:05:33,140
‫E così effettivamente otteniamo ancora il nostro numero di restituiti a tre ma

108
00:05:33,140 --> 00:05:36,260
‫questa volta anche il numero di documenti che

109
00:05:36,260 --> 00:05:39,490
‫sono stati esaminati, quindi scansionati, sono stati solo tre.

110
00:05:39,490 --> 00:05:41,540
‫E questo dimostra che con

111
00:05:41,540 --> 00:05:44,310
‫questo indice abbiamo sostanzialmente ottenuto esattamente ciò che volevamo.

112
00:05:44,310 --> 00:05:47,370
‫Quindi, prima dovevamo scansionare tutti e nove i documenti e

113
00:05:47,370 --> 00:05:50,230
‫ora il motore deve scansionare solo i tre documenti

114
00:05:50,230 --> 00:05:51,870
‫che vengono effettivamente restituiti.

115
00:05:51,870 --> 00:05:54,080
‫E ancora perché i loro

116
00:05:54,080 --> 00:05:56,330
‫prezzi ora sono ordinati in quell'indice.

117
00:05:56,330 --> 00:05:58,890
‫E così questo rende molto più facile

118
00:05:58,890 --> 00:06:01,870
‫e molto più veloce per il motore MongoDB trovarli.

119
00:06:01,870 --> 00:06:04,883
‫E quindi questo è ovviamente un enorme guadagno in termini di prestazioni.

120
00:06:05,930 --> 00:06:09,300
‫Ora diamo un'occhiata anche a Compass qui, e

121
00:06:09,300 --> 00:06:13,060
‫in realtà ricarichiamo l'intero database, e ora dovrebbe essere

122
00:06:13,060 --> 00:06:14,890
‫effettivamente qui, ma

123
00:06:14,890 --> 00:06:17,750
‫per qualche motivo non lo è.

124
00:06:17,750 --> 00:06:19,823
‫Forse proviamo a ricaricare i documenti.

125
00:06:21,040 --> 00:06:22,433
‫Forse appare allora.

126
00:06:23,910 --> 00:06:26,963
‫Non proprio, analizziamo anche lo schema, ed è qualcosa

127
00:06:28,080 --> 00:06:29,260
‫di cui parleremo

128
00:06:29,260 --> 00:06:30,583
‫un po' più avanti.

129
00:06:31,420 --> 00:06:34,970
‫Ma comunque, come vedi, abbiamo ancora solo questi due indici.

130
00:06:34,970 --> 00:06:37,760
‫Ma questo non importa affatto perché

131
00:06:37,760 --> 00:06:40,760
‫sappiamo già che l'indice sta effettivamente funzionando, giusto?

132
00:06:40,760 --> 00:06:41,830
‫Quindi è del

133
00:06:41,830 --> 00:06:45,450
‫tutto normale che a volte questo richieda del tempo per l'aggiornamento.

134
00:06:45,450 --> 00:06:48,330
‫Ora un'altra cosa che potresti notare qui è

135
00:06:48,330 --> 00:06:50,690
‫come questo indice ID di cui

136
00:06:50,690 --> 00:06:53,830
‫abbiamo parlato in precedenza dice univoco qui va bene.

137
00:06:53,830 --> 00:06:56,030
‫E così unica è anche una proprietà

138
00:06:56,030 --> 00:06:58,220
‫che possiamo dare agli indici.

139
00:06:58,220 --> 00:06:59,950
‫Ed è proprio questo il

140
00:06:59,950 --> 00:07:02,550
‫motivo per cui gli ID devono essere sempre univoci.

141
00:07:02,550 --> 00:07:04,290
‫Quindi semplicemente perché

142
00:07:04,290 --> 00:07:07,180
‫l'indice dell'ID ha questa proprietà univoca.

143
00:07:07,180 --> 00:07:09,970
‫Probabilmente hai anche notato che c'è un indice

144
00:07:09,970 --> 00:07:11,760
‫per il nome qui, giusto?

145
00:07:11,760 --> 00:07:15,600
‫Ma in realtà non l'abbiamo creato manualmente noi stessi, giusto?

146
00:07:15,600 --> 00:07:17,970
‫Quindi puoi indovinare perché è qui?

147
00:07:17,970 --> 00:07:20,790
‫Ebbene è perché nella nostra definizione dello schema, impostiamo il

148
00:07:20,790 --> 00:07:23,140
‫campo del nome in modo che sia univoco.

149
00:07:23,140 --> 00:07:25,580
‫E quindi ciò che Mongos fa

150
00:07:25,580 --> 00:07:28,900
‫dietro le quinte per garantire l'unicità di questo campo

151
00:07:28,900 --> 00:07:32,170
‫è creare un indice unico per esso, va bene.

152
00:07:32,170 --> 00:07:34,630
‫Per questo motivo, non solo l'ID,

153
00:07:34,630 --> 00:07:37,410
‫ma anche il nome devono essere sempre univoci.

154
00:07:37,410 --> 00:07:40,520
‫Ok e questo è già fantastico.

155
00:07:40,520 --> 00:07:42,970
‫Quindi, quando tutto ciò che facciamo è interrogare

156
00:07:42,970 --> 00:07:45,050
‫solo per un singolo campo

157
00:07:45,050 --> 00:07:47,700
‫da solo, allora un indice di campo singolo

158
00:07:47,700 --> 00:07:50,010
‫è perfetto perché ricorda che l'indice che

159
00:07:50,010 --> 00:07:53,200
‫abbiamo appena impostato prima è chiamato indice di campo singolo.

160
00:07:53,200 --> 00:07:56,770
‫Non sono sicuro di averlo menzionato allora, ma penso di averlo fatto.

161
00:07:56,770 --> 00:07:59,716
‫Ma comunque, se a volte interroghiamo quel campo

162
00:07:59,716 --> 00:08:02,020
‫ma lo combiniamo con un altro,

163
00:08:02,020 --> 00:08:03,650
‫allora è effettivamente

164
00:08:03,650 --> 00:08:05,930
‫più efficiente creare un indice composto.

165
00:08:05,930 --> 00:08:09,210
‫Quindi uno con due campi e non solo uno.

166
00:08:09,210 --> 00:08:12,883
‫Quindi creiamo una query per questo solo per illustrarlo.

167
00:08:14,100 --> 00:08:16,000
‫E quindi un altro campo che

168
00:08:16,000 --> 00:08:19,713
‫penso verrà interrogato per tutto il tempo è la media delle valutazioni.

169
00:08:22,470 --> 00:08:27,470
‫Quindi le valutazioni sono nella media, penso che si chiami così, e diciamo che

170
00:08:27,610 --> 00:08:32,610
‫vogliamo maggiore o uguale a 4. 7 va bene.

171
00:08:35,370 --> 00:08:36,673
‫Inviamo quella query.

172
00:08:38,230 --> 00:08:42,163
‫E vediamo quanti risultati otteniamo.

173
00:08:43,050 --> 00:08:44,440
‫Dov'è?

174
00:08:44,440 --> 00:08:45,400
‫Sì qui.

175
00:08:45,400 --> 00:08:47,010
‫Quindi il numero di risultati,

176
00:08:47,010 --> 00:08:49,290
‫quindi il numero di documenti che vengono restituiti,

177
00:08:49,290 --> 00:08:51,960
‫in modo che corrispondano a questa query è due.

178
00:08:51,960 --> 00:08:55,390
‫Ma dovevamo ancora esaminare tre documenti.

179
00:08:55,390 --> 00:08:57,480
‫E di nuovo, a questa scala

180
00:08:57,480 --> 00:08:59,250
‫ovviamente, non fa alcuna differenza.

181
00:08:59,250 --> 00:09:01,920
‫Ma come capisci, questo è solo un esempio.

182
00:09:01,920 --> 00:09:05,150
‫E quindi ora vogliamo anche sistemare la situazione e

183
00:09:05,150 --> 00:09:07,853
‫per questo useremo un indice composto.

184
00:09:09,010 --> 00:09:10,870
‫Quindi torniamo qui.

185
00:09:10,870 --> 00:09:12,360
‫Commenta questo.

186
00:09:12,360 --> 00:09:15,890
‫O in realtà prima duplicalo e poi commenta.

187
00:09:15,890 --> 00:09:17,500
‫E quindi è davvero molto semplice.

188
00:09:17,500 --> 00:09:20,103
‫Tutto quello che dobbiamo fare è aggiungere qui l'altro campo.

189
00:09:21,530 --> 00:09:25,270
‫Quindi le valutazioni sono nella media e mettiamo questa

190
00:09:25,270 --> 00:09:26,633
‫in ordine crescente.

191
00:09:29,150 --> 00:09:33,160
‫O in realtà, questo è l'ordine decrescente.

192
00:09:33,160 --> 00:09:35,290
‫Quindi diamo a questo un salvataggio.

193
00:09:35,290 --> 00:09:37,060
‫Torniamo qui.

194
00:09:37,060 --> 00:09:41,720
‫E di nuovo, lo farò un paio di volte qui, okay.

195
00:09:41,720 --> 00:09:43,970
‫E vediamo i nostri risultati.

196
00:09:43,970 --> 00:09:47,080
‫E così ora otteniamo il risultato che volevamo.

197
00:09:47,080 --> 00:09:49,880
‫Quindi sono stati scansionati solo due

198
00:09:49,880 --> 00:09:54,010
‫documenti per trovare i due documenti che stavamo effettivamente cercando.

199
00:09:54,010 --> 00:09:57,420
‫Perfetto e in realtà questo indice composto che abbiamo appena

200
00:09:57,420 --> 00:10:00,700
‫creato funzionerà anche quando la query per uno solo

201
00:10:00,700 --> 00:10:04,020
‫di questi due campi qui individualmente, quindi il prezzo

202
00:10:04,020 --> 00:10:06,330
‫o la media delle valutazioni.

203
00:10:06,330 --> 00:10:09,000
‫Quindi, quando creiamo un indice composto come

204
00:10:09,000 --> 00:10:11,350
‫questo, non dobbiamo creare anche

205
00:10:11,350 --> 00:10:14,193
‫un individuo per ciascuno dei campi, okay.

206
00:10:15,720 --> 00:10:19,603
‫Voglio solo controllare come appare in Compass ora.

207
00:10:21,310 --> 00:10:22,890
‫Ma beh, sembra ancora lo stesso.

208
00:10:22,890 --> 00:10:25,320
‫Ma ancora una volta, non molto importante.

209
00:10:25,320 --> 00:10:27,440
‫Una cosa che possiamo ancora vedere qui

210
00:10:27,440 --> 00:10:28,933
‫e che è piuttosto

211
00:10:28,933 --> 00:10:31,663
‫interessante è che effettivamente la dimensione di questi indici.

212
00:10:32,640 --> 00:10:36,680
‫Quindi 72 kilobyte sono in realtà molto più grandi della

213
00:10:36,680 --> 00:10:39,930
‫dimensione totale di tutti i documenti messi insieme,

214
00:10:39,930 --> 00:10:42,680
‫che è solo 14 kilobyte giusto?

215
00:10:42,680 --> 00:10:45,470
‫E quindi fondamentalmente questi indici che

216
00:10:45,470 --> 00:10:48,680
‫creiamo per cercare i documenti occupano molto più

217
00:10:48,680 --> 00:10:50,890
‫spazio dei documenti stessi.

218
00:10:50,890 --> 00:10:53,530
‫Ma ancora una volta è solo perché

219
00:10:53,530 --> 00:10:56,260
‫operiamo su una scala così piccola in questo esempio.

220
00:10:56,260 --> 00:10:59,300
‫E quindi non è molto rilevante, okay.

221
00:10:59,300 --> 00:11:01,530
‫Ma è ancora importante parlarne

222
00:11:01,530 --> 00:11:05,150
‫perché in realtà questo mi porta alla nostra prossima domanda.

223
00:11:05,150 --> 00:11:06,510
‫E la

224
00:11:06,510 --> 00:11:10,150
‫domanda è: come decidiamo quale campo dobbiamo effettivamente indicizzare?

225
00:11:10,150 --> 00:11:13,710
‫E perché non impostiamo indici su tutti i campi?

226
00:11:13,710 --> 00:11:16,720
‫Beh, abbiamo usato la strategia che ho usato

227
00:11:16,720 --> 00:11:20,640
‫io per impostare gli indici sul prezzo e sul rating medio.

228
00:11:20,640 --> 00:11:24,380
‫Quindi fondamentalmente dobbiamo studiare attentamente i modelli di accesso

229
00:11:24,380 --> 00:11:27,130
‫della nostra applicazione per capire quali campi

230
00:11:27,130 --> 00:11:29,690
‫vengono interrogati di più e

231
00:11:29,690 --> 00:11:32,530
‫quindi impostare gli indici per questi campi.

232
00:11:32,530 --> 00:11:36,640
‫Ad esempio, non sto impostando un indice qui sulla dimensione del gruppo

233
00:11:36,640 --> 00:11:38,060
‫perché non credo

234
00:11:38,060 --> 00:11:41,300
‫davvero che molte persone interrogheranno quel parametro e quindi

235
00:11:41,300 --> 00:11:43,890
‫non ho bisogno di creare un indice lì.

236
00:11:43,890 --> 00:11:47,930
‫Perché non vogliamo davvero esagerare con gli indici.

237
00:11:47,930 --> 00:11:51,610
‫Quindi non vogliamo impostare alla cieca indici su tutti i campi e

238
00:11:51,610 --> 00:11:54,110
‫poi sperare per il meglio in pratica.

239
00:11:54,110 --> 00:11:55,420
‫E il motivo

240
00:11:55,420 --> 00:11:58,380
‫è che ogni indice utilizza effettivamente le

241
00:11:58,380 --> 00:12:01,360
‫risorse, quindi come puoi vedere qui a destra.

242
00:12:01,360 --> 00:12:04,850
‫Inoltre, ogni indice deve essere aggiornato ogni volta

243
00:12:04,850 --> 00:12:07,670
‫che viene aggiornata la raccolta sottostante.

244
00:12:07,670 --> 00:12:12,150
‫Quindi, se hai una raccolta con un alto rapporto scrittura-lettura, quindi

245
00:12:12,150 --> 00:12:14,980
‫una raccolta in cui viene principalmente scritta,

246
00:12:14,980 --> 00:12:17,320
‫non avrebbe assolutamente senso creare

247
00:12:17,320 --> 00:12:21,150
‫un indice su qualsiasi campo in questa raccolta perché

248
00:12:21,150 --> 00:12:23,800
‫il costo di aggiornare sempre l'indice

249
00:12:23,800 --> 00:12:27,060
‫e mantenere in memoria supera chiaramente il vantaggio

250
00:12:27,060 --> 00:12:29,550
‫di avere l'indice in primo luogo

251
00:12:29,550 --> 00:12:31,750
‫se raramente abbiamo ricerche,

252
00:12:31,750 --> 00:12:34,240
‫quindi abbiamo query, per quella raccolta.

253
00:12:34,240 --> 00:12:36,500
‫Quindi, in sintesi, quando si decide

254
00:12:36,500 --> 00:12:38,630
‫se indicizzare o meno un determinato

255
00:12:38,630 --> 00:12:40,750
‫campo, dobbiamo bilanciare la

256
00:12:40,750 --> 00:12:43,430
‫frequenza delle query utilizzando quel campo esatto

257
00:12:43,430 --> 00:12:46,190
‫con il costo di mantenimento di questo

258
00:12:46,190 --> 00:12:49,910
‫indice e anche con il modello di lettura-scrittura della risorsa.

259
00:12:49,910 --> 00:12:52,950
‫Tuttavia, proprio come avviene con la modellazione dei dati,

260
00:12:52,950 --> 00:12:55,460
‫non ci sono regole molto rigide qui.

261
00:12:55,460 --> 00:12:57,240
‫Quindi è tutto un po'

262
00:12:57,240 --> 00:12:59,530
‫confuso e hai davvero bisogno di un

263
00:12:59,530 --> 00:13:03,030
‫po' di sperimentazione e anche di esperienza per farlo bene, va bene.

264
00:13:03,030 --> 00:13:06,570
‫Ma qualunque cosa tu faccia, per favore non ignorare l'indicizzazione.

265
00:13:06,570 --> 00:13:08,550
‫Perché anche se non

266
00:13:08,550 --> 00:13:12,660
‫è perfetto, avrà sempre un enorme vantaggio per la tua applicazione.

267
00:13:12,660 --> 00:13:14,940
‫Va bene, e questo è tutto quello

268
00:13:14,940 --> 00:13:16,903
‫che avevo da dirti sugli indici.

269
00:13:18,230 --> 00:13:21,880
‫C'è solo un altro indice che voglio impostare qui, che

270
00:13:21,880 --> 00:13:25,030
‫va bene per la lumaca del tour.

271
00:13:25,030 --> 00:13:26,920
‫Perché in seguito vorremo effettivamente

272
00:13:26,920 --> 00:13:30,250
‫utilizzare lo slug univoco per eseguire query sui tour.

273
00:13:30,250 --> 00:13:32,680
‫Quindi significa che la lumaca diventerà probabilmente

274
00:13:32,680 --> 00:13:34,640
‫il campo più interrogato.

275
00:13:34,640 --> 00:13:35,950
‫E quindi ha

276
00:13:35,950 --> 00:13:38,780
‫senso avere anche un indice per quello.

277
00:13:38,780 --> 00:13:41,460
‫Quindi tourschema. indice

278
00:13:45,370 --> 00:13:47,380
‫e lumaca uno.

279
00:13:47,380 --> 00:13:52,140
‫E la maggior parte delle volte l'uno o il meno non è così importante.

280
00:13:52,140 --> 00:13:54,680
‫Ok, ora sono davvero curioso di provare

281
00:13:54,680 --> 00:13:56,640
‫a vederlo qui in Compass.

282
00:13:56,640 --> 00:14:00,500
‫Quindi quello che farò è provare a connettermi di nuovo

283
00:14:00,500 --> 00:14:02,043
‫al database qui.

284
00:14:06,740 --> 00:14:10,083
‫E quindi posso solo prenderlo qui da quelli più recenti.

285
00:14:11,360 --> 00:14:14,020
‫Fare clic, connettersi e quindi dovremmo connetterci

286
00:14:14,020 --> 00:14:15,453
‫allo stesso database.

287
00:14:17,260 --> 00:14:21,540
‫Quindi natours, tour, veniamo ai nostri indici.

288
00:14:21,540 --> 00:14:23,380
‫E ora ci siamo.

289
00:14:23,380 --> 00:14:26,013
‫Quindi ora abbiamo i nostri indici proprio qui.

290
00:14:27,070 --> 00:14:28,920
‫Quindi ingrandiamo questa finestra

291
00:14:28,920 --> 00:14:31,290
‫e diamo un'occhiata a quello che abbiamo.

292
00:14:31,290 --> 00:14:33,710
‫Quindi abbiamo la nostra lumaca qui, eccome.

293
00:14:33,710 --> 00:14:36,670
‫Abbiamo il prezzo, che è il primo che fissiamo.

294
00:14:36,670 --> 00:14:39,940
‫E poi abbiamo anche il prezzo e la media delle

295
00:14:39,940 --> 00:14:42,610
‫valutazioni, che è composta e vedi anche qui

296
00:14:42,610 --> 00:14:45,510
‫che questo qui è ascendente e questo è discendente

297
00:14:45,510 --> 00:14:47,740
‫perché ha il meno uno.

298
00:14:47,740 --> 00:14:49,870
‫E un'altra cosa che potresti notare è

299
00:14:49,870 --> 00:14:50,880
‫che in realtà

300
00:14:50,880 --> 00:14:53,680
‫non abbiamo più questo indice dei prezzi nel nostro codice.

301
00:14:53,680 --> 00:14:55,070
‫Ma è ancora qui.

302
00:14:55,070 --> 00:14:58,630
‫E quindi non è sufficiente rimuovere l'indice

303
00:14:58,630 --> 00:15:03,430
‫dal nostro codice, abbiamo davvero bisogno di eliminarlo dal database stesso.

304
00:15:03,430 --> 00:15:05,870
‫Quindi ricorda che lo avevamo qui all'inizio

305
00:15:05,870 --> 00:15:07,460
‫e poi lo abbiamo

306
00:15:07,460 --> 00:15:09,780
‫commentato e abbiamo creato questo nuovo indice

307
00:15:09,780 --> 00:15:12,300
‫composto, ma di nuovo l'indice è fermo qui.

308
00:15:12,300 --> 00:15:14,430
‫Ma dal momento che in realtà

309
00:15:14,430 --> 00:15:18,170
‫non ne abbiamo più bisogno, possiamo semplicemente andare avanti ed eliminarlo bene.

310
00:15:18,170 --> 00:15:21,070
‫Ora dobbiamo digitare il nome solo per

311
00:15:21,070 --> 00:15:23,413
‫assicurarci di non commettere errori.

312
00:15:25,110 --> 00:15:27,410
‫E quindi eccoci qui, fantastico.

313
00:15:27,410 --> 00:15:30,050
‫Quindi questo è il potere degli indici.

314
00:15:30,050 --> 00:15:32,420
‫Possono davvero migliorare le

315
00:15:32,420 --> 00:15:34,970
‫nostre prestazioni di lettura sui database.

316
00:15:34,970 --> 00:15:36,700
‫E quindi nelle

317
00:15:36,700 --> 00:15:39,460
‫tue applicazioni non dovresti mai ignorarle.

318
00:15:39,460 --> 00:15:42,680
‫E prima di finire riprendiamo quel metodo

319
00:15:42,680 --> 00:15:45,140
‫di spiegazione che abbiamo aggiunto

320
00:15:45,140 --> 00:15:47,860
‫qui nella nostra funzione di gestione.

321
00:15:47,860 --> 00:15:49,430
‫E in realtà

322
00:15:49,430 --> 00:15:52,283
‫solo come riferimento, lo lascerò qui così, okay.

323
00:15:54,640 --> 00:15:55,543
‫Dagli un salvataggio.

324
00:15:57,090 --> 00:15:58,133
‫Torna nel menu post.

325
00:15:59,280 --> 00:16:00,773
‫Proviamolo ora.

326
00:16:01,670 --> 00:16:04,040
‫E infatti, è tornato a funzionare.

327
00:16:04,040 --> 00:16:05,763
‫Ok e ora è davvero così.