MongoDBに挿入が多すぎるとどうなりますか？すべてのデータが保存されていることを確認する方法は？

MongoDBを使用して、定期的に測定された値を保存します。〜100ミリ秒ごとに、一連の値がドキュメントとして挿入されます。正常に動作しますが、パフォーマンスの問題が心配です。（私は安全な挿入を使用しますが、PyMongoではこれがデフォルトです。）

mongodがハードディスクに保存できるよりも多くの挿入が毎秒ある場合はどうなりますか？警告はありますか、それとも単に黙って失敗しますか？

書き込み負荷を監視する方法はありますか？db.serverStatus().writeBacksQueued呼び出したときに常にfalseに設定されているものだけが見つかりました。書き込みキューを満たすために挿入する必要があるデータの量をどのようにテストできますか？

mongostatロックを表示します。これは私が心配すべきことですか？

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

書き込みロックについて心配する必要はありますか？書き込みロック期間中に挿入はどうなりますか？後でキューに入れられて保存されますか？

1つのマスターと1つのスレーブを使用した簡単なレプリケーションセットアップについて考えています。初期同期または再同期プロセスはデータベースをロックしますか？

（バージョン2.4.3を使用しています。）

更新： 私自身の質問に部分的に答えたと思う。小さなテストドキュメントを挿入する単純なwhileループを使用して、1秒あたり最大12.000の挿入を処理しました。ただし、qr | qwは、読み取りおよび書き込みキューがまだ空であることを示しています。

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

これは、挿入だけでは多くの問題が発生しないことを意味すると思います。「広範囲の削除など、他の書き込みの重い操作と並行して多くの書き込み操作を行うと、キューが急増する傾向があります。」（ここにあります）

私の未解決の質問：書き込みキューが長期間増加すると、データはどうなりますか？

ここであなた自身の質問のいくつかに答えました。具体的には、方程式の書き込みロックの側面についてまともな考えがあります-12,000挿入/秒で書き込みロックが最大60％になります。それは一貫したパフォーマンスを得るための合理的なレベルです-あなたはいくつかの競合を取得し、いくつかの操作は少し遅くなりますが、あなたは本当に80％を超えると心配するようになります頻繁に問題にぶつかる可能性があります。

他のボトルネック、特にディスクへの書き込みの速さに関しては、これが問題を引き起こす可能性がありますが、時間の経過とともに関連する統計を確認するには、munin-nodeプラグインでMMSをインストールして、ハードウェアとIOの統計を取得することをお勧めしますMongoDB統計に加えて。

それがあるとき、あなたが注目したいと思うメトリックは次のとおりです：

• 平均フラッシュ時間（これは、MongoDBのディスクへの定期的な同期にかかっている時間です）
• [ハードウェア]タブのIOStats（特にIOWait）
• ページフォールト（ディスクが書き込みでビジーであり、データを読み取る必要がある場合、それらは希少なリソースを奪い合います）

それは少し複雑ですが、ここに基本的な考えがあります：

• 平均フラッシュ時間が増加し始めたら、心配する
• 数秒の範囲に入る場合、おそらく限界に達しているでしょう（ただし、これは書き込まれたデータの量とディスクの速度に依存します）
• 60秒に近づくと、パフォーマンスが大幅に低下します（フラッシュは60秒ごとに発生するため、本質的にキューイングされます）。
• 特にIOWaitが高いとパフォーマンスが低下します。特にディスクからの読み取りが必要な場合
• したがって、ページフォールトレベルを確認することも重要です。

このパズルのもう1つのピースは、まだ言及していませんが、ジャーナルです。これはデータもディスクに永続化するため（デフォルトでは100ミリ秒ごと）、同じボリューム上にある場合はディスクの負荷が増加します。したがって、ディスク使用率が高い場合は、ジャーナルを別のディスクに移動することをお勧めします。

実際の「魔法の数字」はありません。ほとんどの場合、すべてが相対的なので、通常のトラフィックの良いベースラインを取得し、物事が上昇しているかどうかを確認し、制限が何であるかを確認するために負荷テストを行います悪化し始め、あなたは良い状態になります。

すべての前文の後、いくつかの質問に進みます。

mongodがハードディスクに保存できるよりも1秒あたりの挿入数が多い場合はどうなりますか？警告はありますか、それとも単に黙って失敗しますか？

上記のレベルまでディスクに負荷をかけ始めると、最終的にすべてが遅くなり、ある時点で（そしてこれはタイムアウト、ハードウェアの性能、例外の処理方法に依存します）書き込みが失敗します- pymongoの最新バージョンを使用している場合、デフォルトで安全な書き込みを使用し、それらは失敗します。もう少し妄想的になりたい場合は、j：trueの書き込み懸念をときどき行うことができます。これは、書き込みがジャーナル（ディスク上）に到達するまでOKを返すのを待ちます。もちろん、これは通常の安全な書き込みよりも遅くなりますが、ディスク容量に関連する問題を即座に示し、他の操作をブロック/キューに入れて、データベースが停止するのを防ぐスロットルとして機能します圧倒された。

1つのマスターと1つのスレーブを使用した簡単なレプリケーションセットアップについて考えています。初期同期または再同期プロセスはデータベースをロックしますか？

最初は全体的なロックについて説明しましたが、この部分に具体的に答えるには、まず、マスター/スレーブではなくレプリカセットを使用していることを確認します。マスター/スレーブ実装は非推奨であり、一般的な使用は推奨されていません。最初の同期に関しては、読み取りに関してプライマリにある程度の負荷が追加されますが、書き込みに関しては追加されないため、ロックに関しては問題ないはずです。

書き込みキューが長期的に増加すると、データはどうなりますか？

おそらく上記の説明からわかるように、答えはアプリケーションの作成方法、書き込みを承認する方法、および使用可能な容量に大きく依存します。基本的に、MongoDB上のディスクへの書き込みに関しては、希望どおりに安全にできますが、j:true上記の説明で述べたように、パフォーマンスのトレードオフがあります。

通常、ロック、ディスク速度などの制限要因を把握し、ハードリミットに達してパフォーマンスの問題を確認する前に、時間の経過に応じてレベルを追跡し、スケールアウト（シャーディング）またはアップ（より良いハードウェア）します。

最後に、db.serverStatus().writeBacksQueued実際にシャード環境でゼロ以外になるメトリックは、移行中のチャンクへの書き込みが適切に処理されるようにすること（ライトバックリスナーによって処理される）に関係しています。したがって、ここでは本質的に赤いニシンです-一般的な書き込みボリュームとは関係ありません。