web-dev-qa-db-ja.com

MongoDBを構成する方法Java本番用のドライバーMongoOptions？

MongoDB Javaドライバー用にMongoOptionsを構成するためのベストプラクティスを探してWebを検索してきましたが、API以外はあまり考えていません。この検索は、 「com.mongodb.DBPortPool $ SemaphoresOut：DB接続を取得するためのセマフォが不足しています」というエラーと、接続/乗数を増やすことで、この問題を解決することができました。 。

2.4ドライバーのオプションは次のとおりです。 http://api.mongodb.org/Java/2.4/com/mongodb/MongoOptions.html

  • autoConnectRetry
  • connectionsPerHost
  • connectTimeout
  • maxWaitTime
  • socketTimeout
  • threadsAllowedToBlockForConnectionMultiplier

新しいドライバーにはより多くのオプションがあり、それらについても聞いてみたいと思います。

mongodbproduction-environmentdatabase-performancedatabase-tuning
98
Dan Polites

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：データベース接続を取得するためのセマフォが不足しています」という例外を引き起こす設定です。このスレッドキューがthreadsAllowedToBlockForConnectionMultiplier値を超えると、この例外をスローします。たとえば、connectionsPerHostが10で、この値が5の場合、前述の例外がスローされる前に最大50スレッドがブロックできます。

    大きなキューを引き起こす可能性のあるスループットの大きなピークが予想される場合、この値を一時的に増やします。まさにその理由で、現時点では1500になっています。クエリの負荷が常にサーバーを上回る場合は、それに応じてハードウェア/スケーリングの状況を改善する必要があります。

  • readPreference。 （UPDATED、2.8 +）デフォルトの読み取り設定を決定するために使用され、「slaveOk」を置き換えます。クラスファクトリメソッドの1つを使用してReadPreferenceを設定します。 最も一般的な設定の完全な説明は、この投稿の最後にあります

  • w。 （UPDATED、2.6 +）この値は、書き込みの「安全性」を決定します。この値が-1の場合、ネットワークまたはデータベースのエラーに関係なく、書き込みはエラーを報告しません。 WriteConcern.NONEは、このための適切な定義済みWriteConcernです。 wが0の場合、ネットワークエラーにより書き込みは失敗しますが、mongoエラーは失敗しません。これは通常、「fire and forget」書き込みと呼ばれ、一貫性と耐久性よりもパフォーマンスが重要な場合に使用する必要があります。このモードにはWriteConcern.NORMALを使用します。

    Wを1以上に設定すると、書き込みは安全と見なされます。安全な書き込みは書き込みを実行し、サーバーへの要求によってフォローアップして書き込みが成功したことを確認するか、失敗した場合はエラー値を取得します（つまり、書き込み後にgetLastError（）コマンドを送信します）。このgetLastError（）コマンドが完了するまで、接続は予約されていることに注意してください。それと追加のコマンドの結果として、スループットは、w <= 0での書き込みよりも大幅に低くなります。wの値が正確に1の場合、MongoDBは、書き込みを送信したインスタンスで書き込みが成功（または確実に失敗）することを保証します。

    レプリカセットの場合、wに高い値を使用して、MongoDBに、レプリカセットの少なくとも「w」メンバーに書き込みを送信してから戻る（または、より正確には、「w」メンバーへの書き込みのレプリケーションを待つ） ）。 wを文字列「majority」に設定して、MongoDBに大部分のレプリカセットメンバー（WriteConcern.MAJORITY）への書き込みを実行するように指示することもできます。通常、生のパフォーマンス（-1または0）または複製された書き込み（> 1）が必要でない限り、これを1に設定する必要があります。 1より大きい値は、書き込みスループットに大きな影響を与えます。

  • fsync。有効にすると、書き込みのたびにmongoを強制的にディスクにフラッシュする耐久性オプション。書き込みバックログに関連する耐久性の問題は一度もなかったので、実稼働環境ではfalse（デフォルト）に設定しています。

  • j* （NEW 2.7 +） *。 trueに設定されている場合、MongoDBがジャーナリンググループのコミットの成功を待ってから戻ることを強制するブール値。ジャーナリングを有効にしている場合は、耐久性を高めるためにこれを有効にすることができます。 http://www.mongodb.org/display/DOCS/Journaling を参照して、ジャーナリングで何が得られるか（そしてこのフラグを有効にする理由）を確認してください。

ReadPreferenceReadPreferenceクラスを使用すると、レプリカセットを使用している場合に、mongodインスタンスのクエリをルーティングするように構成できます。次のオプションが利用可能です。

  • ReadPreference.primary（）：すべての読み取りは、repsetプライマリメンバーのみに送信されます。すべてのクエリで一貫した（最後に書き込まれた）データを返す必要がある場合に使用します。これがデフォルトです。

  • ReadPreference.primaryPreferred（）：可能な場合、すべての読み取りはrepsetプライマリメンバーに送信されますが、プライマリノードが利用できない場合はセカンダリメンバーにクエリを実行できます。そのため、プライマリが利用できなくなると、読み取りが最終的に一貫しますが、それはプライマリが利用できない場合のみです。

  • ReadPreference.secondary（）：すべての読み取りはセカンダリrepsetメンバーに送られ、プライマリメンバーは書き込みのみに使用されます。これは、最終的に一貫した読み取りで対応できる場合にのみ使用してください。追加のrepsetメンバーを使用して読み取りパフォーマンスをスケールアップできますが、repsetが持つことができる（投票）メンバーの量には制限があります。

  • ReadPreference.secondaryPreferred（）：すべての読み取りは、使用可能なセカンダリrepsetメンバーに移動します。プライマリメンバーは、すべてのセカンダリメンバーが使用できなくなるまで、書き込み専用に使用されます。読み取り用のプライマリメンバへのフォールバック以外は、これはReadPreference.secondary（）と同じです。

  • ReadPreference.nearest（）：データベースクライアントが利用できる最も近いrepsetメンバーへの読み取り。最終的に一貫した読み取りが許容される場合にのみ使用してください。最も近いメンバーは、クライアントとさまざまなrepsetメンバー間のレイテンシが最も低いメンバーです。忙しいメンバーは最終的に待ち時間が長くなるので、このshouldは読み込み負荷を自動的に分散しますが、経験上、メンバーの待ち時間が比較的一貫していればセカンダリ（優先）の方がより良いようです。

注：上記のすべてには、TaggableReadPreferenceインスタンスを返す同じメソッドのタグ対応バージョンがあります。レプリカセットタグの詳細な説明は、ここにあります。 レプリカセットタグ

158
Remon van Vliet