Et par strategier kommer til at tænke på:
1) Brug en særskilt samling/database til de 'varme' dokumenter.
Hvis du ved, hvilke dokumenter der er i det varme sæt, ja, det vil hjælpe at flytte dem til en separat samling. Dette vil sikre, at de varme dokumenter er co-resident på samme omfang/sider. Det vil også gøre indekset for disse dokumenter mere tilbøjelige til at være fuldstændigt i hukommelsen. Dette skyldes, at det er mindre og bliver (helt?) brugt oftere.
Hvis de varme dokumenter blandes tilfældigt med andre dokumenter, vil du sandsynligvis skulle fejle i flere af bladelementerne i B-Tree-indekset, når du indlæser et dokument, da sandsynligheden for, at et andet dokument for nylig har indlæst eller åbnet indeksblokken, er lille.
2) Forkort de indekserede værdier .
Jo kortere indeksværdien er, jo flere værdier passer ind i en enkelt B-Tree-blok. (Bemærk:Nøglerne er ikke inkluderet i indekset.) Jo flere poster i en enkelt bucket betyder færre buckets og mindre samlet hukommelse nødvendig for indekset. Det oversættes til den højere sandsynlighed / længere levetid for, at blokke forbliver i hukommelsen. I dit eksempel er en reduktion på 20->8 tegn bedre end 50 % besparelse. Hvis du kan konvertere disse 8 bytes til en long, er der lidt flere besparelser, da longs ikke har et længdepræfiks (4 bytes) og et efterfølgende nul (5 bytes i alt).
3) Forkort tastenavnene.
Jo kortere feltnavnene er, jo mindre plads tager hvert dokument. Dette har den uheldige bivirkning, at læseligheden forringes.
4) Shard
Dette er virkelig den eneste måde at holde ydeevnen oppe i forhold til læsninger på tværs af et helt korpus, der opbruger hukommelse og eventuel diskbåndbredde. Hvis du gør shard, vil du stadig ønske at sharde den 'varme' samling.
5) Juster fremlæsningen på disken til en lille værdi.
Da de 'ikke-varme' læsninger indlæser et tilfældigt dokument fra disken, ønsker vi egentlig kun at læse/fejle i hukommelsen det dokument og så få af dokumenterne omkring det som muligt. De fleste systemer vil prøve at læse en stor blok af data frem, når en bruger læser fra en del af en fil. Det er præcis det modsatte af, hvad vi ønsker.
Hvis du ser, at dit system fejler meget, men den residente hukommelse for mongod-processen ikke nærmer sig den tilgængelige systemhukommelse, vil du sandsynligvis se effekten af, at OS læser ubrugelige data.
6) Prøv at bruge monotont stigende værdier for tasterne.
Dette vil udløse en optimering (for ObjectId-baserede indekser), at når indeksblokken opdeles, vil den gøre det ved 90/10 i stedet for 50/50. Resultatet er, at de fleste af blokkene i dit indeks vil være tæt på kapacitet, og du får brug for færre af dem.
Hvis du først kender de "varme" 50.000 dokumenter bagefter, vil tilføjelse af dem til den separate samling i indeksrækkefølge også udløse denne optimering.
Rob.