Gegeven een eenvoudige standaardquery (zonder limit() of sort() of iets bijzonders toegepast) dat een filtervoorwaarde heeft op twee velden (zoals in name en age in uw voorbeeld), om de resulterende documenten te vinden, zal MongoDB ofwel:
- doe een volledige inzamelingsscan (lees elk document in de hele collectie, ontleden de BSON, vind de betreffende waarden, test ze tegen de invoer en retourneer/gooi elk document weg):Dit is super I/O intens en dus traag.
- gebruik één index die een van de velden bevat (gebruik de indexstructuur om de relevante subset van documenten te lokaliseren, gevolgd door een scan ervan):Afhankelijk van uw gegevensdistributie/indexselectiviteit kan dit erg snel zijn of nauwelijks enig voordeel opleveren (denk aan een index op
agein een dataset van miljoenen mensen tussen de 30 en 40 jaar --> elke zoekopdracht zou nog steeds een eindeloos aantal documenten opleveren). - gebruik twee indexen die samen beide velden in kwestie bevatten (laad beide indexen, voer sleutelzoekopdrachten uit en bereken vervolgens het snijpunt van de resultaten):Nogmaals, afhankelijk van uw gegevensdistributie, kan dit u al dan niet geweldige(re) prestaties opleveren. Het zou echter in de meeste gevallen sneller moeten zijn dan #2. Het zou me echter verbazen als het echt 10x langzamer was dan #4 (zoals je al zei).
- gebruik een samengestelde index (twee opeenvolgende sleutelzoekopdrachten leiden onmiddellijk naar de vereiste documenten):Dit is de snelste optie van allemaal, aangezien het de minste en goedkoopste handelingen vereist om bij de juiste documenten te komen. Om het hoogste niveau van hergebruik te garanderen (niet de prestaties die hierdoor niet worden beïnvloed), moet u over het algemeen eerst beginnen met het meest selectieve veld, dus in uw geval waarschijnlijk
nameen nietageaangezien veel mensen dezelfdeagezullen hebben (dus lage selectiviteit) vergeleken metname(hogere selectiviteit). Maar die keuze hangt ook af van uw concrete scenario en de query's die u op uw database wilt uitvoeren. Er is een redelijk goed artikel op internet over hoe u het beste een samengestelde index kunt definiëren, rekening houdend met verschillende aspecten van uw specifieke situatie:https://emptysqua.re/blog/optimizing-mongodb-compound-indexes
Andere aspecten om te overwegen zijn:Index-updates hebben een bepaalde prijs. Als je echter alleen maar om onbewerkte leessnelheid geeft en je slechts af en toe een paar updates hebt, dan zou je voor meer/grotere indexen moeten gaan.
En last but not least (!) het veelgebruikte bottom line-advies:maak een profiel van uw systeem met behulp van echte gegevens en misschien zelfs realistische belastingscenario's. En blijf ook meten terwijl uw gegevens/systeem in de loop van de tijd veranderen.
Aanvullende informatie: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
Indexkruising versus samengestelde index?
mongodb samengestelde index vs. index snijden
Hoe is de volgorde van samengestelde indexen van belang in MongoDB qua prestaties?
In MongoDB gebruik ik een grote vraag, hoe ik een samengestelde index of een enkele index zal maken, dus mijn responstijd wordt verhoogd