Algumas estratégias vêm à mente:

1) Use uma coleção/banco de dados distinta para os documentos 'quentes'.

Se você souber quais documentos estão no hot set, sim, movê-los para uma coleção separada ajudará. Isso garantirá que os documentos quentes sejam co-residentes nas mesmas extensões/páginas. Isso também tornará o índice desses documentos mais provável de estar completamente na memória. Isso se deve ao fato de ser menor e ser (completamente?) usado com mais frequência.

Se os documentos quentes forem misturados aleatoriamente com outros documentos, você provavelmente terá que falhar em mais elementos folha do índice B-Tree ao carregar um documento, pois a probabilidade de outro documento ter carregado ou acessado recentemente o bloco de índice é pequena.

2) Reduza os valores indexados .

Quanto menor o valor do índice, mais valores cabem em um único bloco B-Tree. (Observação:as chaves não estão incluídas no índice.) Quanto mais entradas em um único bucket significa menos buckets e menos memória total necessária para o índice. Isso se traduz em maior probabilidade/vida útil mais longa que os blocos permanecerão na memória. No seu exemplo, uma redução de 20 a 8 caracteres é uma economia melhor do que 50%. Se você pode converter esses 8 bytes em um longo, há um pouco mais de economia, pois os longos não têm um prefixo de comprimento (4 bytes) e um nulo à direita (5 bytes no total).

3) Encurte os nomes das teclas.

Quanto mais curtos forem os nomes dos campos, menos espaço cada documento ocupará. Isso tem o infeliz efeito colateral de diminuir a legibilidade.

4) Fragmento

Esta é realmente a única maneira de manter o desempenho em face de leituras em todo um corpus que esgota a memória e eventual largura de banda do disco. Se você fragmentar, ainda desejará fragmentar a coleção 'quente'.

5) Ajuste a leitura antecipada no disco para um valor pequeno.

Como as leituras 'não quentes' estão carregando um documento aleatório do disco, realmente queremos apenas ler/falhar na memória esse documento e o menor número possível de documentos ao redor. A maioria dos sistemas tentará ler antecipadamente um grande bloco de dados quando um usuário ler uma parte de um arquivo. Isso é exatamente o oposto do que queremos.

Se você vir seu sistema falhando muito, mas a memória residente para o processo mongod não se aproximar da memória disponível do sistema, você provavelmente verá o efeito do SO lendo dados inúteis.

6) Tente usar valores crescentes monotonicamente para as teclas.

Isso acionará uma otimização (para índices baseados em ObjectId) que, quando o bloco de índice se dividir, fará isso em 90/10 em vez de 50/50. O resultado é que a maioria dos blocos em seu índice estará próxima da capacidade e você precisará de menos deles.

Se você conhecer apenas os 50.000 documentos 'quentes' após o fato, adicioná-los à coleção separada em ordem de índice também acionará essa otimização.

Roubar.