Generelt vil du gerne sætte et indeks på de felter, der bruges mest som filterkriterier i dine vigtigste/hyppige forespørgsler, begyndende med de mest selektive felter først. Der er en del anstændig vejledning om emnet som en del af MongoDB-dokumentationen
. Et udsagn af særlig interesse for din sag er sandsynligvis dette, da du har mange $or s:
Det vigtigste her er dog at måle, måle, måle og se på forespørgselsudførelsesplaner ved hjælp af explain() . Årsagen er, at du højst sandsynligt vil have forskellige slags forespørgsler, som din applikation skal understøtte, og du bliver nødt til at gå til en afvejning på et tidspunkt, hvor du skal vælge mellem indeksvedligeholdelsesomkostninger (f.eks. skrivelåse under indeksopdateringer &diskpladskrav) og den teoretisk hurtigste løsning, hvor alle felter, der bruges i en enkelt forespørgsel, er dækket af et enkelt indeks.
Hele det indekseringsemne er lidt uklart, hvilket i høj grad afhænger af dit præcise scenarie:
- Er dine data stærkt opdateret, og skal skrivninger være superhurtige (du vil have færre/mindre indekser), eller er dine data ret stabile med hyppige læsninger, der skal være hurtige (gå med flere/større indekser)?
- Hvilke slags forespørgsler har du brug for at understøtte? Hvor ens er de med hensyn til deres filtre? Vil visse kombinationer af filtre være mere sandsynlige end andre? Hvilke forespørgsler skal fungere godt, hvilke kan være lidt langsommere?
- Hvordan er dataene i dine potentielt indekserede felter fordelt?
- og så videre...
Du vil ikke finde det enkelte indeks, der hjælper alle dine forespørgsler til at yde det bedste. Og også, når du tilføjer flere indekser eller ændrer eksisterende, kan dette få forespørgselsoptimeringsværktøjet til at stoppe med at bruge et indeks til nogle forespørgsler og i stedet vælge en anden eksekveringsplan, som måske eller måske ikke er ønsket. Så mål alt, hvad der er vigtigt ved enhver ændring af din indeksering eller fysiske datalayout (hardwareopsætning, sharding...). Endelig bør du måle din forespørgsels ydeevne regelmæssigt, efterhånden som din mængde af data vokser, medmindre den er forudsigeligt ensartet i sin distribution.
For at gøre en lang historie kort:Gå efter en iterativ tilgang og start med at tilføje et indeks (jeg vil foreslå at tilføje et på isBlockedByAdmin , isDelete og information.shares.userId ) mål derefter din forespørgsels ydeevne og finjuster derefter dit indeks baseret på dine resultater (og igen, og igen, ...).