En général, vous souhaiterez mettre un index sur les champs les plus utilisés comme critères de filtrage dans vos requêtes les plus importantes/fréquentes, en commençant par les champs les plus sélectifs en premier. Il y a pas mal de conseils décents sur le sujet dans le cadre de la documentation MongoDB
. Une déclaration particulièrement intéressante pour votre cas est probablement celle-ci puisque vous avez beaucoup de $or s :
La chose la plus importante ici, cependant, est de mesurer, mesurer, mesurer et examiner les plans d'exécution des requêtes en utilisant explain() . La raison en est que vous aurez très probablement différents types de requêtes que votre application doit prendre en charge et que vous devrez faire un compromis à un moment donné où vous devrez choisir entre les coûts de maintenance de l'index (par exemple, verrous en écriture pendant les mises à jour d'index et les besoins en espace disque) et la solution théoriquement la plus rapide où tous les champs utilisés dans une seule requête sont couverts par un seul index.
Tout ce sujet d'indexation est un peu flou et dépend fortement de votre scénario précis :
- Vos données sont-elles fortement mises à jour et les écritures doivent-elles être ultra-rapides (vous aurez besoin d'index moins/plus petits) ou vos données sont-elles assez stables avec des lectures fréquentes qui doivent être rapides (opter pour des index plus/plus grands) ?
- Quels types de requêtes devez-vous prendre en charge ? Dans quelle mesure sont-ils similaires en termes de filtres ? Certaines combinaisons de filtres seront-elles plus probables que d'autres ? Quelles requêtes doivent être performantes, lesquelles peuvent être un peu plus lentes ?
- Comment les données de vos champs potentiellement indexés sont-elles distribuées ?
- et ainsi de suite...
Vous ne trouverez pas l'index unique qui aide toutes vos requêtes à fonctionner au mieux. De plus, lors de l'ajout d'index ou de la modification d'index existants, l'optimiseur de requêtes peut cesser d'utiliser certains index pour certaines requêtes et choisir à la place un plan d'exécution différent, ce qui peut être souhaité ou non. Mesurez donc tout ce qui est important lors de toute modification de votre indexation ou de la disposition physique des données (configuration matérielle, partitionnement...). Enfin, vous devez mesurer régulièrement les performances de vos requêtes à mesure que votre quantité de données augmente, à moins qu'elles ne soient prévisibles et uniformes dans leur distribution.
Pour faire court :optez pour une approche itérative et commencez par ajouter un index (je suggérerais d'en ajouter un sur isBlockedByAdmin , isDelete et information.shares.userId ) puis mesurez les performances de vos requêtes, puis affinez votre index en fonction de vos résultats (et encore, et encore, ...).
