Några strategier kommer att tänka på:
1) Använd en distinkt samling/databas för de "heta" dokumenten.
Om du vet vilka dokument som finns i den heta uppsättningen, ja, det hjälper att flytta dem till en separat samling. Detta kommer att säkerställa att de heta dokumenten är co-resident på samma omfattning/sidor. Det kommer också att göra indexet för dessa dokument mer sannolikt att vara helt i minnet. Detta beror på att den är mindre och används (helt?) oftare.
Om de heta dokumenten blandas slumpmässigt med andra dokument kommer du troligen att behöva göra fel på fler av bladelementen i B-Tree-indexet när du laddar ett dokument eftersom sannolikheten för att ett annat dokument nyligen har laddats eller öppnat indexblocket är liten.
2) Förkorta de indexerade värdena .
Ju kortare indexvärde desto fler värden passar in i ett enda B-Tree-block. (Obs:Nycklarna ingår inte i indexet.) Ju fler poster i en enda hink betyder färre hinkar och mindre totalt minne som behövs för indexet. Det översätter till den högre sannolikheten / längre livslängder att block kommer att stanna i minnet. I ditt exempel är en minskning på 20->8 tecken bättre än 50 % besparing. Om du kan konvertera dessa 8 byte till en long sparas lite mer eftersom long inte har ett längdprefix (4 byte) och en avslutande null (5 byte totalt).
3) Förkorta nyckelnamnen.
Ju kortare fältnamn desto mindre utrymme tar varje dokument. Detta har den olyckliga bieffekten att läsbarheten försämras.
4) Shard
Detta är egentligen det enda sättet att hålla prestanda uppe inför läsningar över en hel korpus som tar ut minne och eventuell skivbandbredd. Om du gör skärvor kommer du fortfarande att vilja skära den "heta" samlingen.
5) Justera framåtläsningen på disken till ett litet värde.
Eftersom de "icke-heta" läsningarna laddar ett slumpmässigt dokument från disken vill vi egentligen bara läsa/fela i minnet det dokumentet och så få av dokumenten runt det som möjligt. De flesta system kommer att försöka läsa fram ett stort datablock när en användare läser från en del av en fil. Detta är precis motsatsen till vad vi vill ha.
Om du ser att ditt system har mycket fel men det inhemska minnet för mongod-processen inte närmar sig systemets tillgängliga minne, kommer du sannolikt att se effekten av att operativsystemet läser värdelös data.
6) Försök att använda monotont ökande värden för nycklar.
Detta kommer att utlösa en optimering (för ObjectId-baserade index) att när indexblocket delas kommer det att göra det på 90/10 istället för 50/50. Resultatet är att de flesta av blocken i ditt index kommer att vara nära kapacitet och du kommer att behöva färre av dem.
Om du bara känner till de "heta" 50 000 dokumenten i efterhand kommer även denna optimering att utlösas om du lägger till dem i den separata samlingen i indexordning.
Rob.