За да отговорите на въпроса за $in....
Направих някои тестове за производителност със следния сценарий:
~24 милиона документи в колекция
Потърсете 1 милион от тези документи въз основа на ключ (индексиран)
С помощта на драйвер на CSharp от .NET
Резултати:
Запитване по 1 наведнъж, с една нишка :109 s
Запитване с 1 по 1 наведнъж, многонишково :48 s
Запитване по 100 K наведнъж с помощта на $in, с единична нишка=20 s
Запитване 100K наведнъж, използвайки $in, multi threaded=9s
Така забележимо по-добра производителност при използване на голям $in (ограничен до максимален размер на заявката).
Актуализация: Следвайки коментарите по-долу за това как $in се представя с различни размери на парчета (многонишкови заявки):
Запитване 10 наведнъж (100 000 партиди) =8,8 s
Запитване по 100 наведнъж (10 000 партиди) =4,32 s
Запитване по 1000 наведнъж (1000 партиди) =4,31 s
000 наведнъж (100 партиди) =8,4 сек
Запитване по 100 000 наведнъж (10 партиди) =9 сек (за оригинални резултати по-горе)
Така че изглежда, че има сладко място за това колко стойности да се комбинират в клауза $in спрямо броя на двупосочните пътувания