Przychodzi mi na myśl kilka strategii:
1) Użyj odrębnej kolekcji/bazy danych dla „gorących” dokumentów.
Jeśli wiesz, które dokumenty znajdują się w gorącym zestawie, to tak, przeniesienie ich do osobnej kolekcji pomoże. Zapewni to, że gorące dokumenty będą współistnieć na tych samych zakresach/stronach. Spowoduje to również, że indeks tych dokumentów z większym prawdopodobieństwem znajdzie się w całości w pamięci. Wynika to z tego, że jest mniejszy i jest (całkowicie?) używany częściej.
Jeśli gorące dokumenty są losowo mieszane z innymi dokumentami, prawdopodobnie będziesz musiał popełnić błąd w większej liczbie elementów liścia indeksu B-Tree podczas ładowania dokumentu, ponieważ prawdopodobieństwo, że inny dokument został niedawno załadowany lub uzyskał dostęp do bloku indeksu, jest małe.
2) Skróć indeksowane wartości .
Im krótsza wartość indeksu, tym więcej wartości mieści się w pojedynczym bloku B-Tree. (Uwaga:klucze nie są uwzględniane w indeksie.) Im więcej wpisów w pojedynczym zasobniku oznacza mniej zasobników i mniej pamięci potrzebnej na indeks. Przekłada się to na większe prawdopodobieństwo/dłuższe czasy życia bloków, które pozostaną w pamięci. W twoim przykładzie redukcja 20->8 znaków jest lepsza niż 50% oszczędności. Jeśli możesz przekonwertować te 8 bajtów na długie, jest to trochę więcej oszczędności, ponieważ długie nie mają przedrostka długości (4 bajty) i końcowej wartości null (łącznie 5 bajtów).
3) Skróć nazwy klawiszy.
Im krótsze nazwy pól, tym mniej miejsca zajmuje każdy dokument. Ma to niefortunny efekt uboczny w postaci zmniejszenia czytelności.
4) Odłamek
Jest to naprawdę jedyny sposób na utrzymanie wysokiej wydajności w obliczu odczytów w całym korpusie, który wyczerpuje pamięć i ostateczną przepustowość dysku. Jeśli zrobisz shard, nadal będziesz chciał shardować „gorącą” kolekcję.
5) Dostosuj odczyt z wyprzedzeniem na dysku do małej wartości.
Ponieważ „niegorące” odczyty ładują losowy dokument z dysku, tak naprawdę chcemy tylko odczytać/usterkę w pamięci tego dokumentu i jak najmniejszej liczby dokumentów wokół niego. Większość systemów próbuje odczytać z wyprzedzeniem duży blok danych, gdy użytkownik odczyta fragment pliku. To jest dokładnie przeciwieństwo tego, czego chcemy.
Jeśli zauważysz, że twój system często ulega błędom, ale pamięć rezydentna dla procesu mongod nie zbliża się do dostępnej pamięci systemowej, prawdopodobnie widzisz efekt odczytu bezużytecznych danych przez system operacyjny.
6) Spróbuj użyć monotonicznie rosnących wartości dla klawiszy.
Spowoduje to wyzwolenie optymalizacji (dla indeksów opartych na ObjectId), która po podzieleniu bloku indeksu dokona tego przy 90/10 zamiast 50/50. W rezultacie większość bloków w twoim indeksie będzie bliska pojemności i będziesz potrzebować ich mniej.
Jeśli po fakcie znasz tylko „gorące” 50 000 dokumentów, dodanie ich do oddzielnego zbioru w kolejności indeksowania również uruchomi tę optymalizację.
Rob.
