Quelques stratégies me viennent à l'esprit :
1) Utilisez une collection/base de données distincte pour les documents "chauds".
Si vous savez quels documents se trouvent dans le hot set, alors, oui, les déplacer dans une collection distincte vous aidera. Cela garantira que les documents chauds sont co-résidents sur les mêmes étendues/pages. Cela rendra également l'index de ces documents plus susceptible d'être entièrement en mémoire. Cela est dû au fait qu'il est plus petit et qu'il est (complètement ?) utilisé plus souvent.
Si les documents chauds sont mélangés de manière aléatoire avec d'autres documents, vous devrez probablement vous tromper dans plus d'éléments feuille de l'index B-Tree lors du chargement d'un document car la probabilité qu'un autre document ait récemment chargé ou accédé au bloc d'index est faible.
2) Raccourcissez les valeurs indexées .
Plus la valeur de l'index est courte, plus il y a de valeurs qui tiennent dans un seul bloc B-Tree. (Remarque :les clés ne sont pas incluses dans l'index.) Plus il y a d'entrées dans un même bucket, moins il y a de buckets et moins de mémoire totale est nécessaire pour l'index. Cela se traduit par une probabilité plus élevée / des durées de vie plus longues que les blocs resteront en mémoire. Dans votre exemple, une réduction de 20 -> 8 caractères représente une économie supérieure à 50 %. Si vous pouvez convertir ces 8 octets en un long, il y a un peu plus d'économies puisque les longs n'ont pas de préfixe de longueur (4 octets) et un null final (5 octets au total).
3) Raccourcissez les noms des clés.
Plus les noms de champ sont courts, moins chaque document occupe d'espace. Cela a pour effet secondaire malheureux de réduire la lisibilité.
4) Éclat
C'est vraiment le seul moyen de maintenir les performances face aux lectures sur tout un corpus qui épuisent la mémoire et la bande passante du disque. Si vous partagez, vous voudrez quand même partager la collection « chaude ».
5) Ajustez la lecture anticipée sur le disque à une petite valeur.
Étant donné que les lectures "non chaudes" chargent un document aléatoire à partir du disque, nous ne voulons vraiment lire/défaut en mémoire que ce document et le moins possible de documents qui l'entourent. La plupart des systèmes essaieront de lire à l'avance un gros bloc de données une fois qu'un utilisateur aura lu une partie d'un fichier. C'est exactement le contraire de ce que nous voulons.
Si vous constatez que votre système présente de nombreux défauts mais que la mémoire résidente du processus mongod ne s'approche pas de la mémoire disponible du système, vous constatez probablement que le système d'exploitation lit des données inutiles.
6) Essayez d'utiliser des valeurs croissantes monotones pour les clés.
Cela déclenchera une optimisation (pour les index basés sur ObjectId) qui, lorsque le bloc d'index se divisera, le fera à 90/10 au lieu de 50/50. Le résultat est que la plupart des blocs de votre index seront proches de la capacité et vous en aurez besoin de moins.
Si vous ne connaissez les 50 000 documents "chauds" qu'après coup, leur ajout à la collection séparée dans l'ordre de l'index déclenchera également cette optimisation.
Rob.
