Over het algemeen wilt u een index plaatsen op de velden die het meest worden gebruikt als filtercriteria in uw belangrijkste/frequente zoekopdrachten, te beginnen met de meest selectieve velden eerst. Er is behoorlijk wat fatsoenlijke richtlijnen over het onderwerp als onderdeel van de MongoDB-documentatie
. Een verklaring die daar voor uw geval van bijzonder belang is, is waarschijnlijk deze omdat u veel $or . hebt s:
Het belangrijkste hier is echter het meten, meten, meten en bekijken van uitvoeringsplannen voor query's met behulp van explain() . De reden hiervoor is dat u hoogstwaarschijnlijk verschillende soorten vragen zult hebben die uw toepassing moet ondersteunen en dat u op een gegeven moment een afweging moet maken waarbij u moet kiezen tussen indexonderhoudskosten (bijv. schrijfvergrendelingen tijdens indexupdates en schijfruimtevereisten) en de theoretisch snelste oplossing waarbij alle velden die in een enkele zoekopdracht worden gebruikt, worden gedekt door een enkele index.
Dat hele indexeringsonderwerp is een beetje een vaag onderwerp dat sterk afhangt van uw precieze scenario:
- Zijn uw gegevens sterk bijgewerkt en moeten schrijfbewerkingen supersnel zijn (u wilt minder/kleinere indexen) of zijn uw gegevens redelijk stabiel met frequente leesbewerkingen die snel moeten zijn (ga met meer/grotere indexen)?
- Wat voor soort vragen heb je nodig om te ondersteunen? Hoe vergelijkbaar zijn ze in termen van hun filters? Zullen bepaalde combinaties van filters waarschijnlijker zijn dan andere? Welke zoekopdrachten moeten goed presteren, welke kunnen wat langzamer zijn?
- Hoe worden de gegevens in uw potentieel geïndexeerde velden verdeeld?
- en ga zo maar door...
U zult niet de enkele index vinden die al uw zoekopdrachten helpt om het beste te presteren. En ook, wanneer meer indexen worden toegevoegd of bestaande worden gewijzigd, kan dit ertoe leiden dat de query-optimizer stopt met het gebruik van een index voor sommige query's en in plaats daarvan een ander uitvoeringsplan kiest dat al dan niet gewenst is. Meet dus alles wat belangrijk is bij elke wijziging in uw indexering of fysieke gegevenslay-out (hardwareconfiguratie, sharding...). Ten slotte moet u de prestaties van uw zoekopdrachten regelmatig meten naarmate uw hoeveelheid gegevens groeit, tenzij de distributie voorspelbaar uniform is.
Om een lang verhaal kort te maken:ga voor een iteratieve aanpak en begin met het toevoegen van een index (ik zou willen voorstellen om er een toe te voegen op isBlockedByAdmin , isDelete en information.shares.userId ) meet vervolgens uw zoekopdrachtprestaties en verfijn vervolgens uw index op basis van uw bevindingen (en opnieuw, en opnieuw, ...).