Napadá mě několik strategií:
1) Použijte samostatnou kolekci/databázi pro „horké“ dokumenty.
Pokud víte, které dokumenty jsou v horké sadě, pak ano, jejich přesunutí do samostatné sbírky pomůže. Tím zajistíte, že horké dokumenty budou na stejném rozsahu/stránkách. Také to způsobí, že index těchto dokumentů bude pravděpodobně celý v paměti. To je způsobeno tím, že je menší a je (zcela?) používán častěji.
Pokud jsou horké dokumenty náhodně smíchány s jinými dokumenty, budete pravděpodobně muset při načítání dokumentu chybovat ve více listových prvcích indexu B-Strom, protože pravděpodobnost, že jiný dokument nedávno načetl nebo přistoupil k bloku indexu, je malá.
2) Zkraťte indexované hodnoty .
Čím kratší je hodnota indexu, tím více hodnot se vejde do jednoho bloku B-stromu. (Poznámka:Klíče nejsou zahrnuty v indexu.) Čím více položek v jednom segmentu znamená méně segmentů a méně celkové paměti potřebné pro index. To znamená vyšší pravděpodobnost / delší životnost, že bloky zůstanou v paměti. Ve vašem příkladu je snížení o 20->8 znaků lepší než 50% úspora. Pokud dokážete převést těchto 8 bajtů na dlouhé, ušetříte o něco více, protože longy nemají předponu délky (4 bajty) a koncovou nulu (celkem 5 bajtů).
3) Zkraťte názvy klíčů.
Čím kratší jsou názvy polí, tím méně místa každý dokument zabere. To má neblahý vedlejší účinek snížení čitelnosti.
4) Shard
To je skutečně jediný způsob, jak udržet výkon na vysoké úrovni tváří v tvář čtením v celém korpusu, které vyčerpávají paměť a případnou šířku pásma disku. Pokud uděláte úlomky, budete chtít 'horkou' sbírku stále střepat.
5) Upravte napřed čtení na disku na malou hodnotu.
Vzhledem k tomu, že 'nehorké' čtení načítá náhodný dokument z disku, chceme opravdu číst/chybovat do paměti pouze tento dokument a co nejméně dokumentů kolem něj. Většina systémů se pokusí načíst dopředu velký blok dat, jakmile uživatel čte z části souboru. To je přesný opak toho, co chceme.
Pokud vidíte, že váš systém hodně chybuje, ale rezidentní paměť pro proces mongod se neblíží systémové dostupné paměti, pravděpodobně vidíte efekt toho, že operační systém čte zbytečná data.
6) Zkuste použít monotónně rostoucí hodnoty pro klíče.
To spustí optimalizaci (pro indexy založené na ObjectId), že když se blok indexu rozdělí, bude to dělat v poměru 90/10 namísto 50/50. Výsledkem je, že většina bloků ve vašem indexu bude mít téměř kapacitu a budete jich potřebovat méně.
Pokud znáte „žhavých“ 50 000 dokumentů až dodatečně, pak jejich přidání do samostatné kolekce v pořadí indexů také spustí tuto optimalizaci.
Rob.