0

私はすべてを a にロードするのが不思議Spring Mongo APIでした。検索結果に数十億件のレコードが含まれている場合、メモリに影響はありませんか? これをすべてメモリにロードせずに、これを達成するためのより良い方法を誰かが提案できますか。limit を使用すると役立つ場合がありますが、新しいドキュメントがコレクションに挿入されているかどうかがわからないという欠点があります。レコードを読み取った後にコレクションが変更された場合、制限による検索は同じ効果があります。findListX of billion

2つの質問：

  • すべてをメモリにロードしないことでパフォーマンスを向上させる
  • 処理中に追加されたこの未知のドキュメントをどのように解決しますか?

API からのコード

List<T> result = new ArrayList<T>();

while (cursor.hasNext()) {
    DBObject object = cursor.next();
    result.add(objectCallback.doWith(object));
}
4

1 に答える 1

1

すべてをメモリにロードしないことでパフォーマンスを向上させる

検索結果に対応するユーザー インターフェイスには、通常、表示する必要がある結果の数に制限があります (たとえば、ページごとの結果と全体的な結果)。無制限の結果セットをメモリにロードする賢明な使用例はないと思いますが、アプリケーション クエリに妥当な制限を含めることをお勧めします。

MongoDB サーバーは、最大 BSON ドキュメント サイズ(MongoDB 3.0 では 16MB .. 実際、通常は最初のバッチで 1MB、後続のバッチで 4MB) を超えることができないカーソル バッチでクエリ結果を返します。アプリケーション コードでカーソルを反復処理し続けることで、より大きな結果を構築できますが、実装は選択する必要があります。

処理中に追加されたこの未知のドキュメントをどのように解決しますか?

単調に増加する新しいドキュメントのプロパティ (デフォルトで生成された ObjectId など) で検索結果を並べ替えます。カーソル (MongoDB 3.0 など) は書き込みアクティビティから分離されていないため、処理中に挿入または更新されたドキュメントも、クエリの順序に該当する場合は含まれます。

コードが_id(昇順で) 並べ替えられた大きなクエリを反復している場合、既定の ObjectId を使用して挿入された新しいドキュメントは、最後のバッチに表示されます。

于 2015-06-24T01:06:40.187 に答える