Pour répondre à la Q concernant $in...
J'ai effectué des tests de performances avec le scénario suivant :
~24 millions de documents dans une collection
Recherchez 1 million de ces documents en fonction d'une clé (indexée)
Utilisation du pilote CSharp de .NET
Résultats :
Interroger 1 à la fois, thread unique :109s
Interroger 1 à la fois, multithread :48s
Interroger 100K à la fois en utilisant $in, single threaded=20s
Interroger 100K à la fois en utilisant $in, multi threaded=9s
Donc, des performances nettement meilleures en utilisant un grand $in (limité à la taille maximale de la requête).
Mettre à jour : Suite aux commentaires ci-dessous sur les performances de $in avec différentes tailles de blocs (requêtes multithread) :
Interroger 10 à la fois (100 000 lots) =8,8 s
Interroger 100 à la fois (10 000 lots) =4,32 s
Interroger 1000 à la fois (1000 lots) =4,31 s
Interroger 10 000 à la fois (100 lots) =8,4 s
Interroger 100 000 à la fois (10 lots) =9 s (selon les résultats d'origine ci-dessus)
Il semble donc y avoir un compromis entre le nombre de valeurs à regrouper dans une clause $in et le nombre d'allers-retours
