2.9に更新：
-
autoConnectRetry 単に、予期しない切断が発生した後、ドライバーがサーバーへの再接続を自動的に試行することを意味します。実稼働環境では、通常、このセットをtrueに設定する必要があります。
-
connectionsPerHost は、単一のMongoインスタンス（シングルトンであるため、通常はアプリケーションごとに1つあります）がmongod/mongosプロセスに対して確立できる物理接続の量です。これを書いている時点では、実際のクエリスループットが低くても、Javaドライバーは最終的にこの量の接続を確立します（つまり、mongostatの「conn」統計はアプリサーバーごとにこの数に達するまで上昇します）。
ほとんどの場合、これを100より高く設定する必要はありませんが、この設定は「テストして確認する」ことの1つです。サーバーへの接続の合計数が
を超えないように、これを十分に低く設定する必要があることに注意してください。db.serverStatus().connections.available現在、本番環境では40です。
-
connectTimeout 。名前が示すように、接続の試行が中止されるまでドライバーが待機するミリ秒数。現実的な予想される可能性がない限り、タイムアウトを長い時間（15〜30秒）に設定します。そうしないと、接続の試行が成功する妨げになります。通常、接続の試行に数秒以上かかる場合、ネットワークインフラストラクチャは高スループットに対応できません。
-
maxWaitTime 。スレッドが接続プールで接続が使用可能になるのを待機するミリ秒数。これが時間内に発生しない場合は、例外が発生します。デフォルトのままにします。
-
socketTimeout 。標準のソケットタイムアウト値。 60秒（60000）に設定します。
-
threadsAllowedToBlockForConnectionMultiplier 。プールが現在使い果たされている場合に接続が使用可能になるのを待機できるスレッドの数を示すconnectionsPerHostの乗数。これは、「com.mongodb.DBPortPool $ SemaphoresOut：Out of semaphores togetdbconnection」例外を引き起こす設定です。このスレッドキューがthreadsAllowedToBlockForConnectionMultiplier値を超えると、この例外がスローされます。たとえば、connectionsPerHostが10で、この値が5の場合、前述の例外がスローされる前に、最大50のスレッドがブロックできます。
大きなキューを引き起こす可能性のあるスループットの大きなピークが予想される場合は、この値を一時的に増やします。まさにその理由で、現時点では1500になっています。クエリの負荷が常にサーバーを上回っている場合は、それに応じてハードウェア/スケーリングの状況を改善する必要があります。
-
readPreference 。 （更新、2.8以降） デフォルトの読み取り設定を決定するために使用され、「slaveOk」を置き換えます。クラスファクトリメソッドの1つを使用してReadPreferenceを設定します。 最も一般的な設定の完全な説明は、この投稿の最後にあります
-
w 。 （更新、2.6以降） この値は、書き込みの「安全性」を決定します。この値が-1の場合、ネットワークまたはデータベースのエラーに関係なく、書き込みはエラーを報告しません。 WriteConcern.NONEは、このための適切な事前定義されたWriteConcernです。 wが0の場合、ネットワークエラーは書き込みを失敗させますが、mongoエラーは失敗しません。これは通常、「ファイアアンドフォーゲット」書き込みと呼ばれ、一貫性と耐久性よりもパフォーマンスが重要な場合に使用する必要があります。このモードにはWriteConcern.NORMALを使用します。
wを1以上に設定すると、書き込みは安全であると見なされます。安全な書き込みは、書き込みを実行し、サーバーへの要求によってフォローアップして、書き込みが成功したことを確認するか、失敗した場合はエラー値を取得します（つまり、書き込み後にgetLastError（）コマンドを送信します）。このgetLastError（）コマンドが完了するまで、接続は予約されていることに注意してください。これと追加コマンドの結果として、スループットはw <=0の書き込みよりも大幅に低くなります。w値が正確に1の場合、MongoDBは、書き込みを送信したインスタンスで書き込みが成功した（または確実に失敗した）ことを保証します。
レプリカセットの場合、wに高い値を使用できます。MongoDBに、レプリカセットの少なくとも「w」メンバーに書き込みを送信してから戻るように指示します（より正確には、「w」メンバーへの書き込みの複製を待ちます）。 ）。 wを文字列"majority"に設定して、レプリカセットメンバーの大部分（WriteConcern.MAJORITY）への書き込みを実行するようにMongoDBに指示することもできます。通常、生のパフォーマンス（-1または0）またはレプリケートされた書き込み（> 1）が必要でない限り、これを1に設定する必要があります。 1より大きい値は、書き込みスループットに大きな影響を与えます。
-
fsync 。有効にすると、書き込みのたびにmongoを強制的にディスクにフラッシュする耐久性オプション。書き込みバックログに関連する耐久性の問題は一度も発生したことがないため、本番環境ではこれがfalse（デフォルト）になっています。
-
j * （NEW 2.7+） *。 trueに設定すると、MongoDBはジャーナリンググループのコミットが成功するのを待ってから戻るように強制するブール値。ジャーナリングを有効にしている場合は、これを有効にして耐久性を高めることができます。 http://www.mongodb.org/display/DOCS/Journalingを参照して、どのジャーナリングが得られるか（したがって、このフラグを有効にする理由）を確認してください。
ReadPreference ReadPreferenceクラスを使用すると、レプリカセットを操作している場合に、どのmongodインスタンスクエリがルーティングされるかを構成できます。次のオプションを使用できます：
-
ReadPreference.primary（） ：すべての読み取りは、repsetプライマリメンバーにのみ送信されます。すべてのクエリで一貫性のある（最後に書き込まれた）データを返す必要がある場合は、これを使用します。これがデフォルトです。
-
ReadPreference.primaryPreferred（） ：すべての読み取りは、可能であればrepsetプライマリメンバーに送信されますが、プライマリノードが使用できない場合はセカンダリメンバーにクエリを実行できます。そのため、プライマリが使用できなくなった場合、読み取りは結果整合性になりますが、プライマリが使用できなくなった場合に限ります。
-
ReadPreference.secondary（） ：すべての読み取りはセカンダリrepsetメンバーに送信され、プライマリメンバーは書き込みにのみ使用されます。これは、結果整合性のある読み取りで生きることができる場合にのみ使用してください。 repsetが持つことができる（投票）メンバーの数には制限がありますが、追加のrepsetメンバーを使用して読み取りパフォーマンスをスケールアップできます。
-
ReadPreference.secondaryPreferred（） ：すべての読み取りは、それらのいずれかが使用可能な場合、セカンダリrepsetメンバーに送信されます。すべてのセカンダリメンバーが使用できなくなる場合を除き、プライマリメンバーは書き込み専用に使用されます。読み取りのプライマリメンバーへのフォールバックを除いて、これはReadPreference.secondary（）と同じです。
-
ReadPreference.nearest（） ：読み取りは、データベースクライアントで使用可能な最も近いrepsetメンバーに送信されます。結果整合性のある読み取りが許容できる場合にのみ使用してください。最も近いメンバーは、クライアントとさまざまなrepsetメンバー間の待ち時間が最も短いメンバーです。忙しいメンバーは最終的に待ち時間が長くなるので、これはすべきです また、私の経験では、メンバーのレイテンシーが比較的一貫している場合、セカンダリ（推奨）の方がうまくいくようですが、読み取り負荷のバランスを自動的に調整します。
注：上記のすべてには、代わりにTaggableReadPreferenceインスタンスを返す同じメソッドのタグ対応バージョンがあります。レプリカセットタグの完全な説明はここにあります：レプリカセットタグ