Ein paar Strategien fallen mir ein:
1) Verwenden Sie eine eigene Sammlung/Datenbank für die „heißen“ Dokumente.
Wenn Sie wissen, welche Dokumente sich im Hotset befinden, hilft es, sie in eine separate Sammlung zu verschieben. Dadurch wird sichergestellt, dass die heißen Dokumente auf den gleichen Extents/Seiten gleichzeitig vorhanden sind. Es wird auch wahrscheinlicher, dass sich der Index für diese Dokumente vollständig im Speicher befindet. Dies liegt daran, dass es kleiner ist und (vollständig?) häufiger verwendet wird.
Wenn die heißen Dokumente zufällig mit anderen Dokumenten gemischt werden, müssen Sie beim Laden eines Dokuments wahrscheinlich mehr Blattelemente des B-Tree-Index bemängeln, da die Wahrscheinlichkeit gering ist, dass ein anderes Dokument kürzlich geladen wurde oder auf den Indexblock zugegriffen hat.
2) Kürzen Sie die indizierten Werte .
Je kürzer der Indexwert ist, desto mehr Werte passen in einen einzelnen B-Baum-Block. (Hinweis:Die Schlüssel sind nicht im Index enthalten.) Je mehr Einträge in einem einzelnen Bucket vorhanden sind, desto weniger Buckets und weniger Gesamtspeicher werden für den Index benötigt. Das bedeutet eine höhere Wahrscheinlichkeit / längere Lebensdauer, dass Blöcke im Speicher bleiben. In Ihrem Beispiel ist eine Reduzierung um 20 -> 8 Zeichen besser als eine Ersparnis von 50 %. Wenn Sie diese 8 Bytes in Long umwandeln können, sparen Sie etwas mehr, da Longs kein Längenpräfix (4 Bytes) und keine abschließende Null (insgesamt 5 Bytes) haben.
3) Kürzen Sie die Schlüsselnamen.
Je kürzer die Feldnamen sind, desto weniger Platz nimmt jedes Dokument ein. Dies hat den unglücklichen Nebeneffekt, dass die Lesbarkeit abnimmt.
4) Scherbe
Dies ist wirklich die einzige Möglichkeit, die Leistung angesichts von Lesevorgängen über einen gesamten Korpus aufrechtzuerhalten, die Speicher und eventuelle Festplattenbandbreite erschöpfen. Wenn Sie Shard machen, werden Sie immer noch die "heiße" Sammlung teilen wollen.
5) Stellen Sie das Vorauslesen auf der Festplatte auf einen kleinen Wert ein.
Da die "nicht heißen" Lesevorgänge ein zufälliges Dokument von der Festplatte laden, möchten wir wirklich nur dieses Dokument und so wenige Dokumente wie möglich in den Speicher lesen/fehlern. Die meisten Systeme werden versuchen, einen großen Datenblock vorauszulesen, sobald ein Benutzer einen Teil einer Datei liest. Das ist genau das Gegenteil von dem, was wir wollen.
Wenn Sie sehen, dass Ihr System häufig fehlerhaft ist, aber der residente Speicher für den Mongod-Prozess sich nicht dem verfügbaren Speicher des Systems annähert, sehen Sie wahrscheinlich die Auswirkung, dass das Betriebssystem nutzlose Daten liest.
6) Versuchen Sie, monoton ansteigende Werte für die Tasten zu verwenden.
Dies löst eine Optimierung (für ObjectId-basierte Indizes) aus, bei der der Indexblock bei 90/10 statt 50/50 geteilt wird. Das Ergebnis ist, dass die meisten Blöcke in Ihrem Index fast ausgelastet sind und Sie weniger davon benötigen.
Wenn Sie die „heißen“ 50.000 Dokumente erst im Nachhinein kennen, wird diese Optimierung ebenfalls ausgelöst, wenn Sie sie in der Indexreihenfolge zur separaten Sammlung hinzufügen.
Rob.
