Data una semplice query standard (senza limit() o sort() o qualsiasi altra cosa applicata di fantasia) che ha una condizione di filtro su due campi (come in name e age nel tuo esempio), per trovare i documenti risultanti, MongoDB:
- esegui una scansione completa della raccolta (leggi tutti i documenti dell'intera raccolta, analizza il BSON, trova i valori in questione, testali rispetto all'input e restituisci/elimina ogni documento):questo è super I/O intenso e quindi lento.
- utilizza un indice che contiene uno dei campi (usa l'albero dell'indice per individuare un sottoinsieme rilevante di documenti seguito da una scansione degli stessi):a seconda della distribuzione dei dati/selettività dell'indice, questo può essere molto veloce o fornire a malapena alcun vantaggio (immagina un indice su
agein un dataset di milioni di persone tra i 30 ei 40 anni --> ogni ricerca produrrebbe comunque un numero infinito di documenti). - utilizza due indici che insieme contengono entrambi i campi in questione (carica entrambi gli indici, esegui ricerche di chiavi, quindi calcola l'intersezione dei risultati):Anche in questo caso, a seconda della distribuzione dei dati, questo potrebbe o meno offrire prestazioni eccezionali. Tuttavia, nella maggior parte dei casi dovrebbe essere più veloce di #2. Sarei, tuttavia, sorpreso se fosse davvero 10 volte più lento del numero 4 (come hai detto).
- utilizza un indice composto (due successive ricerche di chiavi portano immediatamente ai documenti richiesti):questa sarà l'opzione più veloce di tutte dato che richiede le operazioni minime ed economiche per arrivare ai documenti giusti. Per garantire il massimo livello di riutilizzo (non prestazioni che non ne risentiranno) dovresti in genere iniziare prima con il campo più selettivo, quindi nel tuo caso probabilmente
namee nonagedato che molte persone avranno la stessaage(selettività così bassa) rispetto aname(maggiore selettività). Ma quella scelta dipende anche dal tuo scenario concreto e dalle query che intendi eseguire sul tuo database. C'è un buon articolo sul web su come definire al meglio un indice composto tenendo conto di vari aspetti della tua situazione specifica:https://emptysqua.re/blog/optimizing-mongodb-compound-indexes
Altri aspetti da considerare sono:Gli aggiornamenti dell'indice hanno un certo prezzo. Tuttavia, se tutto ciò che ti interessa è la velocità di lettura grezza e hai solo pochi aggiornamenti ogni tanto, allora dovresti scegliere indici più/grandi.
E, ultimo ma non meno importante (!), il consiglio di fondo ben abusato:profila il tuo sistema usando dati reali e forse anche scenari di carico realistici. E continua anche a misurare man mano che i tuoi dati/sistema cambiano nel tempo.
Letture aggiuntive:https://docs.mongodb.com/manual/core/query-optimization/index.html
https://dba.stackexchange.com/questions/158240/mongodb-index-intersection-does-eliminate-the-need-for-creating-compound-in
Intersezione dell'indice e indice composto?
mongodb compund index vs. index interseca
In che modo l'ordine degli indici composti è importante in MongoDB dal punto di vista delle prestazioni?
In MongoDB, sto usando una query di grandi dimensioni, come creerò un indice composto o un singolo indice, quindi il mio tempo di risposta aumenta
