I henhold til MongoDB-dokumentationen er der generelt ikke behov for rutinemæssigt at genopbygge indekser.
BEMÆRK :Ethvert råd om lagring bliver mere interessant med MongoDB 3.0+, som introducerede en tilslutbar storage engine API . Mine kommentarer nedenfor er specifikt med henvisning til standard MMAP-lagringsmotoren i MongoDB 3.0 og tidligere. WiredTiger og andre lagringsmotorer har forskellige lagringsimplementeringer til data og indekser.
Der kan være en vis fordel ved at genopbygge et indeks med MMAP-lagringsmotoren, hvis:
-
Et indeks bruger en større mængde plads end forventet i forhold til dataene. Bemærk:du skal overvåge historiske data og indeksstørrelse for at have en baseline til sammenligning.
-
Du vil migrere fra et ældre indeksformat til et nyere. Hvis en reindeks er tilrådelig, vil dette blive nævnt i opgraderingsnoterne. For eksempel introducerede MongoDB 2.0 betydelige forbedringer af indeksydelsen så udgivelsesbemærkningerne inkluderer en foreslået genindeksering til v2.0-formatet efter opgradering. På samme måde introducerede MongoDB 2.6
2dsphere(v2.0) indekser som har en anden standardadfærd (sparsom som standard). Eksisterende indekser genopbygges ikke efter indeksversionsopgraderinger; valget af hvis/hvornår der skal opgraderes er overladt til databaseadministratoren. -
Du har ændret
_idformat for en samling til eller fra en monotont stigende nøgle (f.eks. ObjectID) til en tilfældig værdi. Dette er lidt esoterisk, men der er en indeksoptimering, der deler b-tree buckets 90/10 (i stedet for 50/50), hvis du indsætter_ids, der altid er stigende (ref:SERVER-983 ). Hvis arten af dit_ids ændrer sig markant, kan det være muligt at bygge et mere effektivt b-træ med et re-indeks.
For mere information om generel B-træ-adfærd, se:Wikipedia:B-tree
Visualisering af indeksbrug
Hvis du virkelig er nysgerrig efter at grave lidt mere i indeksets interne elementer, er der nogle eksperimentelle kommandoer/værktøjer, du kan prøve. Jeg forventer, at disse kun er begrænset til MongoDB 2.4 &2.6: