シナリオは次のとおりです。
私はデータを照会しています（当たり前！）
正確にクエリすることは不可能/合理的ではない、つまり複雑なクエリであるため、サーバー側で一部を除外する可能性があります
データベースにかなりの負荷がかかっている可能性があります。更新を含む多数の並行リクエストが存在する場合があります。
だから、私はできました
a）クエリを limit() せず、十分になるまでデータをストリーミングし続けます。ただし、応答時間は重要であるため、目的のデータがまばらすぎる場合は、ページ全体を取得する前に部分的なセットを返す必要がある場合があります。
b) limit() を使用しますが、ページ全体のデータを取得するために、場合によっては数回再クエリを実行します。繰り返しますが、最終結果はまだ完全なセットではない可能性があります。ここでの考え方は、追加のリクエストをいくつか行うと、データベースの負荷が軽減されるということです。
これは「場合による」可能性が高いことは理解していますが、ベストプラクティスやチューニングの最適な出発点について誰かが洞察を持っているかどうか疑問に思っています。
オプション (a) は、すでにかなりの負荷がかかっていると言うデータベースに、さらに過剰な負荷をかけるのに役立ちます。その理由は、制限がない場合、nscanコマンドexplainが大きくなり、MongoDB サーバーの負荷が高くなる可能性があるためです。私の見解では、これはかなり悪い考えです。
を使用できますが、サイズが大きくなるにつれてlimit単純skipでlimit高価になることに注意してください。skipMongoDB ドキュメントから:
残念ながら、スキップは（非常に）コストがかかる可能性があり、データのページを返し始める前に、サーバーがコレクションまたはインデックスの先頭からオフセット/スキップ位置に移動する必要があります（制限）。ページ数が増えると、コレクションが大きくなると、スキップが遅くなり、CPU の負荷が高くなり、IO バウンドになる可能性があります。
範囲ベースのページングは、インデックスの使用を改善しますが、特定のページに簡単にジャンプすることはできません。
あなたが本当に探しているのは、範囲ベースのページネーション$ltです。並べ替えと使用に使用できる一意の列がある限り$gt. 範囲ベースのページングを実装する方法の別の例については、こちらを参照してください。