Няколко стратегии идват на ум:
1) Използвайте отделна колекция/база данни за „горещите“ документи.
Ако знаете кои документи са в горещия комплект, тогава, да, преместването им в отделна колекция ще помогне. Това ще гарантира, че горещите документи са сърезидентни на едни и същи екстенти/страници. Това също ще направи индекса за тези документи по-вероятно да бъде изцяло в паметта. Това се дължи на това, че е по-малък и (напълно?) се използва по-често.
Ако горещите документи са произволно смесени с други документи, тогава вероятно ще трябва да се сблъскате с повече от листовите елементи на индекса B-Tree, когато зареждате документ, тъй като вероятността друг документ наскоро да е заредил или да има достъп до индексния блок е малка.
2) Съкратете индексираните стойности .
Колкото по-къса е стойността на индекса, толкова повече стойности се побират в един блок B-Tree. (Забележка:Ключовете не са включени в индекса.) Колкото повече записи в една кофа означава по-малко кофи и по-малко обща памет, необходима за индекса. Това означава по-голяма вероятност/по-дълъг живот блоковете да останат в паметта. Във вашия пример намаляването на 20->8 символа е по-добро от 50% спестяване. Ако можете да преобразувате тези 8 байта в long, има малко повече спестявания, тъй като longs нямат префикс за дължина (4 байта) и нула в края (общо 5 байта).
3) Съкратете имената на ключовете.
Колкото по-кратки са имената на полетата, толкова по-малко място заема всеки документ. Това има неприятния страничен ефект от намаляване на четливостта.
4) Shard
Това наистина е единственият начин да поддържате висока производителност при четене в цял корпус, което изчерпва паметта и евентуалната честотна лента на диска. Ако направите разделяне, пак ще искате да разделите „горещата“ колекция.
5) Коригирайте предварителното четене на диска на малка стойност.
Тъй като „не-горещите“ четения зареждат случаен документ от диска, ние наистина искаме само да прочетем/повредим в паметта този документ и възможно най-малко от документите около него. Повечето системи ще се опитат да прочетат напред голям блок от данни, след като потребителят прочете от част от файл. Това е точно обратното на това, което искаме.
Ако видите, че системата ви има много грешки, но резидентната памет за процеса mongod не се доближава до наличната памет на системата, вероятно виждате ефекта от това, че операционната система чете безполезни данни.
6) Опитайте се да използвате монотонно нарастващи стойности за ключовете.
Това ще задейства оптимизация (за индекси, базирани на ObjectId), така че когато индексният блок се раздели, той ще го направи при 90/10 вместо 50/50. Резултатът е, че повечето от блоковете във вашия индекс ще бъдат близо до капацитета и ще имате нужда от по-малко от тях.
Ако познавате само „горещите“ 50 000 документа след факта, тогава добавянето им към отделната колекция в индексен ред също ще задейства тази оптимизация.
Роб.
