‫Jonas: Bentornato.
‫Quindi ora parliamo
‫un po' delle prestazioni di lettura in MongoDB,
‫perché qualcosa chiamato indici è così importante e
‫come possiamo effettivamente crearli noi stessi.
‫E voglio iniziare questa dimostrazione sugli indici lanciando una
‫semplice query su tutti i nostri tour.
‫Quindi veniamo qui per ottenere tutti
‫i tour e filtrerò
‫anche per un prezzo inferiore a 1.000.
‫Ok e allora vediamo.
‫Sì, quindi otteniamo tre risultati indietro, va bene.
‫E questo è importante da tenere
‫a mente per ciò che ti mostrerò
‫in seguito, ovvero che possiamo anche ottenere un paio
‫di statistiche sulla query stessa.
‫Quindi andiamo qui fondamentalmente alla funzione handler.
‫E quindi questo ricordalo adesso nella fabbrica di manipolatori.
‫Giusto, quindi è questo, penso che sia
‫in fondo.
‫Sì, quindi è questo, ottieni tutte le funzioni
‫di fabbrica che creeranno questo gestore che
‫viene chiamato per la query che abbiamo appena eseguito.
‫E quindi qui
‫sulla query, ora aggiungerò un metodo di spiegazione.
‫Va bene, quindi dopo la query chiameremo spiega tutto bene.
‫E quindi diamo un'occhiata a questo.
‫E così ora otteniamo un risultato completamente
‫diverso, che sostanzialmente sono queste statistiche.
‫Ora c'è un sacco di roba qui dentro.
‫Ma quello
‫che mi interessa davvero sono queste statistiche di esecuzione, ok.
‫Quindi puoi vedere qui che il numero
‫di documenti che sono stati restituiti era tre.
‫E quindi questo è esattamente il risultato che abbiamo ottenuto prima.
‫Quindi, prima di spiegare bene.
‫Ma ciò che è veramente importante notare
‫qui è che
‫il numero di documenti che sono stati esaminati è nove, ok.
‫E quindi questo significa che MongoDB ha
‫dovuto esaminare, quindi fondamentalmente scansionare tutti e nove i
‫documenti per trovare i tre corretti.
‫Quindi i tre che corrispondono alla query vanno bene.
‫E quindi non è per niente efficiente, giusto?
‫Ora, ovviamente, a questa
‫scala con solo nove documenti non fa assolutamente alcuna differenza.
‫Ma se avessimo centinaia di migliaia
‫o addirittura milioni di documenti qui, ciò
‫influenzerebbe in modo significativo
‫le prestazioni di lettura di questa query.
‫Quindi, di nuovo, non sarà il caso in questa applicazione,
‫ma potrebbe essere in un'app che creerai un giorno.
‫E quindi hai davvero bisogno di conoscere gli indici.
‫Perché con gli indici, saremo
‫in grado di risolvere questo problema.
‫Quindi possiamo creare indici su campi specifici in una raccolta.
‫Ad esempio Mongo crea automaticamente un indice
‫sul campo ID per impostazione predefinita.
‫E vediamo davvero che in Compass va bene.
‫Ad esempio in tutti i tour, abbiamo qui la scheda degli indici.
‫Quindi fino a questo punto eravamo solo
‫qui nella scheda
‫documenti, ma come vedi qui abbiamo molte cose diverse
‫e una di queste sono gli indici.
‫E così di nuovo vedi che per impostazione predefinita abbiamo un indice ID.
‫E questo indice ID è quindi fondamentalmente un elenco ordinato di
‫tutti gli ID che vengono archiviati da qualche
‫parte al di fuori della raccolta.
‫E puoi effettivamente vedere
‫una dimensione qui, che ha 36 kilobyte, questo indice va bene.
‫E questo indice è estremamente utile.
‫Perché ogni volta che
‫i documenti vengono interrogati dall'ID MongoDB cercherà quell'indice ordinato invece di
‫cercare nell'intera raccolta e guardare tutti
‫i documenti uno per uno, il
‫che ovviamente è molto più lento.
‫Quindi, ancora una volta senza un indice, Mongo deve guardare
‫ogni documento uno per uno.
‫Ma con un indice sul campo che stiamo
‫cercando, questo processo diventa molto più efficiente.
‫Quindi è abbastanza intelligente, giusto?
‫E, naturalmente, possiamo impostare i nostri indici
‫sui campi che interroghiamo molto spesso.
‫Quindi facciamolo in realtà con il campo
‫del prezzo che abbiamo appena
‫interrogato prima perché credo che sia uno dei
‫più importanti per cui le persone interrogheranno, ok.
‫E quindi è così che funziona.
‫Quindi dobbiamo andare al modello del tour giusto.
‫E poi facciamolo qui dopo questa dichiarazione interiore
‫e diciamo tourchema. indice ok.
‫E poi un oggetto con il nome
‫del campo e ricorda come ho
‫detto che avremmo impostato l'indice sul prezzo e poi uno o uno meno.
‫E uno significa che stiamo ordinando l'indice dei
‫prezzi in ordine crescente,
‫mentre il meno uno sta per ordine decrescente, va bene.
‫E in realtà ci sono anche altri tipi di indici, come
‫per il testo o per i dati geospaziali, ma
‫lo vedremo un po' più avanti.
‫Ok, salviamolo ora
‫e riproviamo la nostra query.
‫E in realtà lo farò un paio
‫di volte qui per assicurarmi che l'indice sia davvero impostato.
‫Perché a volte non è impostato subito.
‫Ma ora diamo un'occhiata qui.
‫E così effettivamente otteniamo ancora il nostro numero di restituiti a tre ma
‫questa volta anche il numero di documenti che
‫sono stati esaminati, quindi scansionati, sono stati solo tre.
‫E questo dimostra che con
‫questo indice abbiamo sostanzialmente ottenuto esattamente ciò che volevamo.
‫Quindi, prima dovevamo scansionare tutti e nove i documenti e
‫ora il motore deve scansionare solo i tre documenti
‫che vengono effettivamente restituiti.
‫E ancora perché i loro
‫prezzi ora sono ordinati in quell'indice.
‫E così questo rende molto più facile
‫e molto più veloce per il motore MongoDB trovarli.
‫E quindi questo è ovviamente un enorme guadagno in termini di prestazioni.
‫Ora diamo un'occhiata anche a Compass qui, e
‫in realtà ricarichiamo l'intero database, e ora dovrebbe essere
‫effettivamente qui, ma
‫per qualche motivo non lo è.
‫Forse proviamo a ricaricare i documenti.
‫Forse appare allora.
‫Non proprio, analizziamo anche lo schema, ed è qualcosa
‫di cui parleremo
‫un po' più avanti.
‫Ma comunque, come vedi, abbiamo ancora solo questi due indici.
‫Ma questo non importa affatto perché
‫sappiamo già che l'indice sta effettivamente funzionando, giusto?
‫Quindi è del
‫tutto normale che a volte questo richieda del tempo per l'aggiornamento.
‫Ora un'altra cosa che potresti notare qui è
‫come questo indice ID di cui
‫abbiamo parlato in precedenza dice univoco qui va bene.
‫E così unica è anche una proprietà
‫che possiamo dare agli indici.
‫Ed è proprio questo il
‫motivo per cui gli ID devono essere sempre univoci.
‫Quindi semplicemente perché
‫l'indice dell'ID ha questa proprietà univoca.
‫Probabilmente hai anche notato che c'è un indice
‫per il nome qui, giusto?
‫Ma in realtà non l'abbiamo creato manualmente noi stessi, giusto?
‫Quindi puoi indovinare perché è qui?
‫Ebbene è perché nella nostra definizione dello schema, impostiamo il
‫campo del nome in modo che sia univoco.
‫E quindi ciò che Mongos fa
‫dietro le quinte per garantire l'unicità di questo campo
‫è creare un indice unico per esso, va bene.
‫Per questo motivo, non solo l'ID,
‫ma anche il nome devono essere sempre univoci.
‫Ok e questo è già fantastico.
‫Quindi, quando tutto ciò che facciamo è interrogare
‫solo per un singolo campo
‫da solo, allora un indice di campo singolo
‫è perfetto perché ricorda che l'indice che
‫abbiamo appena impostato prima è chiamato indice di campo singolo.
‫Non sono sicuro di averlo menzionato allora, ma penso di averlo fatto.
‫Ma comunque, se a volte interroghiamo quel campo
‫ma lo combiniamo con un altro,
‫allora è effettivamente
‫più efficiente creare un indice composto.
‫Quindi uno con due campi e non solo uno.
‫Quindi creiamo una query per questo solo per illustrarlo.
‫E quindi un altro campo che
‫penso verrà interrogato per tutto il tempo è la media delle valutazioni.
‫Quindi le valutazioni sono nella media, penso che si chiami così, e diciamo che
‫vogliamo maggiore o uguale a 4. 7 va bene.
‫Inviamo quella query.
‫E vediamo quanti risultati otteniamo.
‫Dov'è?
‫Sì qui.
‫Quindi il numero di risultati,
‫quindi il numero di documenti che vengono restituiti,
‫in modo che corrispondano a questa query è due.
‫Ma dovevamo ancora esaminare tre documenti.
‫E di nuovo, a questa scala
‫ovviamente, non fa alcuna differenza.
‫Ma come capisci, questo è solo un esempio.
‫E quindi ora vogliamo anche sistemare la situazione e
‫per questo useremo un indice composto.
‫Quindi torniamo qui.
‫Commenta questo.
‫O in realtà prima duplicalo e poi commenta.
‫E quindi è davvero molto semplice.
‫Tutto quello che dobbiamo fare è aggiungere qui l'altro campo.
‫Quindi le valutazioni sono nella media e mettiamo questa
‫in ordine crescente.
‫O in realtà, questo è l'ordine decrescente.
‫Quindi diamo a questo un salvataggio.
‫Torniamo qui.
‫E di nuovo, lo farò un paio di volte qui, okay.
‫E vediamo i nostri risultati.
‫E così ora otteniamo il risultato che volevamo.
‫Quindi sono stati scansionati solo due
‫documenti per trovare i due documenti che stavamo effettivamente cercando.
‫Perfetto e in realtà questo indice composto che abbiamo appena
‫creato funzionerà anche quando la query per uno solo
‫di questi due campi qui individualmente, quindi il prezzo
‫o la media delle valutazioni.
‫Quindi, quando creiamo un indice composto come
‫questo, non dobbiamo creare anche
‫un individuo per ciascuno dei campi, okay.
‫Voglio solo controllare come appare in Compass ora.
‫Ma beh, sembra ancora lo stesso.
‫Ma ancora una volta, non molto importante.
‫Una cosa che possiamo ancora vedere qui
‫e che è piuttosto
‫interessante è che effettivamente la dimensione di questi indici.
‫Quindi 72 kilobyte sono in realtà molto più grandi della
‫dimensione totale di tutti i documenti messi insieme,
‫che è solo 14 kilobyte giusto?
‫E quindi fondamentalmente questi indici che
‫creiamo per cercare i documenti occupano molto più
‫spazio dei documenti stessi.
‫Ma ancora una volta è solo perché
‫operiamo su una scala così piccola in questo esempio.
‫E quindi non è molto rilevante, okay.
‫Ma è ancora importante parlarne
‫perché in realtà questo mi porta alla nostra prossima domanda.
‫E la
‫domanda è: come decidiamo quale campo dobbiamo effettivamente indicizzare?
‫E perché non impostiamo indici su tutti i campi?
‫Beh, abbiamo usato la strategia che ho usato
‫io per impostare gli indici sul prezzo e sul rating medio.
‫Quindi fondamentalmente dobbiamo studiare attentamente i modelli di accesso
‫della nostra applicazione per capire quali campi
‫vengono interrogati di più e
‫quindi impostare gli indici per questi campi.
‫Ad esempio, non sto impostando un indice qui sulla dimensione del gruppo
‫perché non credo
‫davvero che molte persone interrogheranno quel parametro e quindi
‫non ho bisogno di creare un indice lì.
‫Perché non vogliamo davvero esagerare con gli indici.
‫Quindi non vogliamo impostare alla cieca indici su tutti i campi e
‫poi sperare per il meglio in pratica.
‫E il motivo
‫è che ogni indice utilizza effettivamente le
‫risorse, quindi come puoi vedere qui a destra.
‫Inoltre, ogni indice deve essere aggiornato ogni volta
‫che viene aggiornata la raccolta sottostante.
‫Quindi, se hai una raccolta con un alto rapporto scrittura-lettura, quindi
‫una raccolta in cui viene principalmente scritta,
‫non avrebbe assolutamente senso creare
‫un indice su qualsiasi campo in questa raccolta perché
‫il costo di aggiornare sempre l'indice
‫e mantenere in memoria supera chiaramente il vantaggio
‫di avere l'indice in primo luogo
‫se raramente abbiamo ricerche,
‫quindi abbiamo query, per quella raccolta.
‫Quindi, in sintesi, quando si decide
‫se indicizzare o meno un determinato
‫campo, dobbiamo bilanciare la
‫frequenza delle query utilizzando quel campo esatto
‫con il costo di mantenimento di questo
‫indice e anche con il modello di lettura-scrittura della risorsa.
‫Tuttavia, proprio come avviene con la modellazione dei dati,
‫non ci sono regole molto rigide qui.
‫Quindi è tutto un po'
‫confuso e hai davvero bisogno di un
‫po' di sperimentazione e anche di esperienza per farlo bene, va bene.
‫Ma qualunque cosa tu faccia, per favore non ignorare l'indicizzazione.
‫Perché anche se non
‫è perfetto, avrà sempre un enorme vantaggio per la tua applicazione.
‫Va bene, e questo è tutto quello
‫che avevo da dirti sugli indici.
‫C'è solo un altro indice che voglio impostare qui, che
‫va bene per la lumaca del tour.
‫Perché in seguito vorremo effettivamente
‫utilizzare lo slug univoco per eseguire query sui tour.
‫Quindi significa che la lumaca diventerà probabilmente
‫il campo più interrogato.
‫E quindi ha
‫senso avere anche un indice per quello.
‫Quindi tourschema. indice
‫e lumaca uno.
‫E la maggior parte delle volte l'uno o il meno non è così importante.
‫Ok, ora sono davvero curioso di provare
‫a vederlo qui in Compass.
‫Quindi quello che farò è provare a connettermi di nuovo
‫al database qui.
‫E quindi posso solo prenderlo qui da quelli più recenti.
‫Fare clic, connettersi e quindi dovremmo connetterci
‫allo stesso database.
‫Quindi natours, tour, veniamo ai nostri indici.
‫E ora ci siamo.
‫Quindi ora abbiamo i nostri indici proprio qui.
‫Quindi ingrandiamo questa finestra
‫e diamo un'occhiata a quello che abbiamo.
‫Quindi abbiamo la nostra lumaca qui, eccome.
‫Abbiamo il prezzo, che è il primo che fissiamo.
‫E poi abbiamo anche il prezzo e la media delle
‫valutazioni, che è composta e vedi anche qui
‫che questo qui è ascendente e questo è discendente
‫perché ha il meno uno.
‫E un'altra cosa che potresti notare è
‫che in realtà
‫non abbiamo più questo indice dei prezzi nel nostro codice.
‫Ma è ancora qui.
‫E quindi non è sufficiente rimuovere l'indice
‫dal nostro codice, abbiamo davvero bisogno di eliminarlo dal database stesso.
‫Quindi ricorda che lo avevamo qui all'inizio
‫e poi lo abbiamo
‫commentato e abbiamo creato questo nuovo indice
‫composto, ma di nuovo l'indice è fermo qui.
‫Ma dal momento che in realtà
‫non ne abbiamo più bisogno, possiamo semplicemente andare avanti ed eliminarlo bene.
‫Ora dobbiamo digitare il nome solo per
‫assicurarci di non commettere errori.
‫E quindi eccoci qui, fantastico.
‫Quindi questo è il potere degli indici.
‫Possono davvero migliorare le
‫nostre prestazioni di lettura sui database.
‫E quindi nelle
‫tue applicazioni non dovresti mai ignorarle.
‫E prima di finire riprendiamo quel metodo
‫di spiegazione che abbiamo aggiunto
‫qui nella nostra funzione di gestione.
‫E in realtà
‫solo come riferimento, lo lascerò qui così, okay.
‫Dagli un salvataggio.
‫Torna nel menu post.
‫Proviamolo ora.
‫E infatti, è tornato a funzionare.
‫Ok e ora è davvero così.