Givet en almindelig standardforespørgsel (uden limit() eller sort() eller noget fancy anvendt), der har en filterbetingelse på to felter (som i name og age i dit eksempel), for at finde de resulterende dokumenter, vil MongoDB enten:
- foretag en fuldstændig samlingsscanning (læs hvert dokument i hele samlingen, parse BSON, find de pågældende værdier, test dem mod input og returner/kasser hvert dokument):Dette er super I/O intenst og derfor langsomt.
- brug et indeks der rummer et af felterne (brug indekstræ til at finde relevante undersæt af dokumenter efterfulgt af en scanning af dem):Afhængigt af din datafordeling/indeksselektivitet kan dette være meget hurtigt eller næsten ikke give nogen fordel (forestil dig et indeks på
agei et datasæt med millioner af mennesker mellem 30 og 40 år --> ville hvert opslag stadig give et uendeligt antal dokumenter). - brug to indekser som tilsammen indeholder begge de pågældende felter (indlæs begge indekser, udfør nøgleopslag, og beregn derefter skæringspunktet mellem resultaterne):Igen, afhængigt af din datadistribution, kan dette give dig større(re) ydeevne. Det bør dog i de fleste tilfælde være hurtigere end #2. Jeg ville dog blive overrasket, hvis det virkelig var 10 gange langsommere end #4 (som du nævnte).
- brug et sammensat indeks (to efterfølgende nøgleopslag fører straks til de nødvendige dokumenter):Dette vil være den hurtigste mulighed af alle, da det kræver de mindste og billigste operationer at komme til de rigtige dokumenter. For at sikre det højeste niveau af genbrug (ikke ydeevne, som ikke vil blive påvirket af dette) bør du generelt starte med det mest selektive felt først, så i dit tilfælde sandsynligvis
nameog ikkeagegivet at mange mennesker vil have sammeage(så lav selektivitet) sammenlignet medname(højere selektivitet). Men det valg afhænger også af dit konkrete scenarie og de forespørgsler, du har til hensigt at køre mod din database. Der er en ret god artikel på nettet om, hvordan man bedst definerer et sammensat indeks under hensyntagen til forskellige aspekter af din specifikke situation:https://emptysqua.re/blog/optimizing-mongodb-compound-indexes
Andre aspekter at overveje er:Indeksopdateringer kommer til en bestemt pris. Men hvis alt, hvad du bekymrer dig om, er rå læsehastighed, og du kun har nogle få opdateringer i ny og næ, så bør du gå efter flere/større indekser.
Og sidst, men ikke mindst (!) det godt overbrugte bundlinjeråd:Profil helvede ud af dit system ved hjælp af rigtige data og måske endda realistiske belastningsscenarier. Og fortsæt også med at måle, efterhånden som dine data/system ændrer sig over tid.
Yderligere oplysninger:https://docs.mongodb.com/manual/core/query-optimization/index.html
https://dba.stackexchange.com/questions/158240/mongodb-index-intersection-does-not-eliminate-the-need-for-creating-compound-in
Indeks skæringspunkt vs. sammensat indeks?
mongodb compund indeks vs. indeks skærer
Hvilken betydning har rækkefølgen af sammensatte indekser i MongoDB præstationsmæssigt?
I MongoDB bruger jeg en stor forespørgsel, hvordan jeg vil oprette sammensat indeks eller enkelt indeks, så min responstid øges