Mi vengono in mente alcune strategie:
1) Utilizzare una raccolta/database distinto per i documenti "caldi".
Se sai quali documenti sono nell'hot set, sì, sarà utile spostarli in una raccolta separata. Ciò garantirà che i documenti caldi risiedano nelle stesse estensioni/pagine. Renderà anche più probabile che l'indice di quei documenti sia completamente in memoria. Ciò è dovuto al fatto che è più piccolo e viene utilizzato (completamente?) più spesso.
Se i documenti caldi vengono mescolati casualmente con altri documenti, è probabile che tu debba incolpare più elementi foglia dell'indice B-Tree durante il caricamento di un documento poiché la probabilità che un altro documento abbia recentemente caricato o effettuato l'accesso al blocco dell'indice è piccola.
2) Riduci i valori indicizzati .
Più breve è il valore dell'indice, più valori si adattano a un singolo blocco B-Tree. (Nota:le chiavi non sono incluse nell'indice.) Più voci in un singolo bucket significano meno bucket e meno memoria totale necessaria per l'indice. Ciò si traduce in una maggiore probabilità/durata più lunga che i blocchi rimarranno in memoria. Nel tuo esempio una riduzione di 20->8 caratteri è un risparmio migliore del 50%. Se riesci a convertire quegli 8 byte in un long c'è un po' più di risparmio poiché i long non hanno un prefisso di lunghezza (4 byte) e un null finale (5 byte in totale).
3) Accorciare i nomi delle chiavi.
Più brevi sono i nomi dei campi, meno spazio occupa ogni documento. Ciò ha lo sfortunato effetto collaterale di diminuire la leggibilità.
4) Frammento
Questo è davvero l'unico modo per mantenere alte le prestazioni di fronte alle letture su un intero corpus che esaurisce la memoria e l'eventuale larghezza di banda del disco. Se esegui lo shard, vorrai comunque eseguire lo shard della raccolta "calda".
5) Regola il read-ahead su disco su un valore piccolo.
Poiché le letture "non calde" stanno caricando un documento casuale dal disco, vogliamo solo leggere/incidere in memoria quel documento e il minor numero possibile di documenti intorno ad esso. La maggior parte dei sistemi proverà a leggere in anticipo un blocco di dati di grandi dimensioni una volta che un utente legge da una parte di un file. Questo è esattamente l'opposto di ciò che vogliamo.
Se vedi che il tuo sistema ha molti errori ma la memoria residente per il processo mongod non si avvicina alla memoria disponibile del sistema, probabilmente vedrai l'effetto del sistema operativo che legge dati inutili.
6) Prova a usare valori monotonicamente crescenti per le chiavi.
Ciò attiverà un'ottimizzazione (per indici basati su ObjectId) che quando il blocco dell'indice si divide, lo farà a 90/10 anziché 50/50. Il risultato è che la maggior parte dei blocchi nel tuo indice sarà prossima alla capacità e ne avrai bisogno di meno.
Se conosci solo i 50.000 documenti "caldi" dopo il fatto, anche l'aggiunta alla raccolta differenziata in ordine di indice attiverà questa ottimizzazione.
Rob.
