mongodbクエリ内のアイテムのインデックスを取得します

subjectIDによる注文

subjectIDの場合単調に増加する値（たとえば、MongoDBのデフォルトのObjectID）である（または変更できる）場合は、通常の find（）を使用する簡単なオプションがあります。適切な並べ替え、スキップ、制限を使用します。この場合、subjectIDが $ gte> （以上）subjectID ：

 var page = 1;
var subjectID = ObjectId("515535a0760fe8735f5f6897");
db.users.find(
    { _id: { $gte : subjectID } }
).sort({'_id':1}).skip(page*20).limit(20)
 集約フレームワーク
 
 MongoDb 2.4と同様に、結果パイプライン内のドキュメントの位置に基づいて照合するような機能は、集約フレームワークにはありません。 MongoDBJiraプロジェクトのSERVER
の新機能の提案を提出できます。 キュー。
 
  $ matchfromなどの新しいパイプライン演算子が必要なようです  $ matchfromが最初に出現するまでドキュメントを無視します 基準。次に、 $ limitを追加できます 次のn個のアイテムを取得します。また、 $ matchfromの前に出力を並べ替えることもできます。 したがって、予測可能な結果があります。
 
 これは、subjectIDを増やす場合に比べて複雑すぎるように見えますが、より高度な検索条件または集計パイプラインで計算された結果に基づいてページングを実行するユースケースがある場合があります。
 代替アプローチ
 
 Aggregation Frameworkでのこのような機能の将来のサポートとは別に、コードに同じマッチングアプローチを実装するためのいくつかのオプションがあります。
   
 古い  group（）を使用します 
  finalize（）を使用した集計コマンド 関数。注： group（） しません シャーディングされたクラスターを操作します。
 
  
 MapReduce
を使用します およびfinalize（） 関数
 
  
 Aggregation Frameworkから結果セット全体をフェッチし、結果のマッチング/削減をアプリケーションコードに実装します（ただし、リクエストごとにすべてのページをフェッチする場合、これは「ページング」の概念をいくらか無効にします）。
 
 
 パフォーマンスに関する考慮事項
 
  skipを使用したクエリ それでも、介在するインデックスエントリを読み通す必要があるため、多数のドキュメントをスキップすることはあまり効率的ではありません。
 
 スキップオフセットを使用してページングする代わりに、前のページの最後のエントリから開始して、連続したページクエリを実行することを検討できます（つまり、最初のページは $ gte になります） 開始subjectIDと後続のページは$gtになります 前のページに含まれている最後のsubjectID）。これは、ユーザーインターフェースでページングをどのように表示するかによって異なります。UIに特定のページにジャンプするのではなく、メッセージの「次の」ページを表示するオプションしかない場合は、このアプローチを使用するのが最も簡単です。