問題タブ [wiredtiger]

現在、Vert.x を使用してアプリケーションでいくつかのベンチマークを実行しており、mongo Java 同期または非同期ドライバーを使用したときの結果を比較しようとしています。

驚いたことに、同期ドライバーを使用した方が結果がはるかに優れているようです。これは、非同期ドライバーに比べて mongodb 接続をほとんど使用しないためです。その結果、mongo リクエストは遅くなり、mongo は常に async ドライバーでクラッシュして終了します。

非同期ドライバーが同期ドライバーと比較して非常に多くの接続を開くのは正常ですか? はいの場合、非同期ドライバーでより適切にスケーリングするために、mongo をレプリカ セットとしてインストールする必要がありますか?

たとえば、これは 16 スレッドで 30 秒間に 200 接続した wrk でのテスト結果です。

同期ドライバーを使用する場合:

非同期ドライバーを使用する (mongodb がクラッシュする) :

• MongoDB 3.2.7 ワイヤードタイガー
• モンゴ Java ドライバー 3.2.2
• 頂点 3.3.1
• Mac OS X El Capitan 2.5 Ghz I7 16 Go RAM

更新 1 : ファイルとプロセスの制限を構成することで、ローカル マシンでの mongodb クラッシュの問題を解決しました: https://unix.stackexchange.com/questions/108174/how-to-persist-ulimit-settings-in-osx-mavericks ただし、 、非同期ドライバーとの接続をまだ多く開いているため、アプリケーションが遅くなります。

更新 2 : async ドライバーを使用したコードを次に示します。バーティクル : http://pastebin.com/SygKuDhg

設定：

更新 3 : 同期ドライバーのコードは次のとおりです。

http://pastebin.com/FJ7JeSPU

Jongo を Java 同期ドライバーのラッパーとして使用し、vertx-hk2 を REST バーティクルへの依存性注入に使用しています。

MMAPv1ドキュメントが言ったように

すべてのレコードはディスク上で連続して配置され、割り当てられたレコードよりもドキュメントが大きくなると、MongoDB は新しいレコードを割り当てる必要があります。新しい割り当てでは、MongoDB がドキュメントを移動し、ドキュメントを参照するすべてのインデックスを更新する必要があります。これは、インプレース更新よりも時間がかかり、ストレージの断片化につながります。バージョン 3.0.0 で変更されました。
デフォルトでは、MongoDB は 2 の累乗サイズの割り当てを使用するため、MongoDB 内のすべてのドキュメントは、ドキュメント自体と余分なスペースまたはパディングを含むレコードに格納されます。パディングにより、再割り当ての可能性を最小限に抑えながら、更新の結果としてドキュメントを大きくすることができます。

しかし、WiredTiger ドキュメントはこれについて何も述べていません。したがって、レコードサイズが変更されたときに問題がないか、パフォーマンスの問題があるがドキュメントには記載されていないかを知りたいだけです。

1 つのドキュメント (レベル 1) がN(k)サブドキュメント配列 (レベル 2) としてさまざまな種類のアイテムを持つことになっているとします。これらは、深くネストされた配列サブドキュメントのクエリ最適化がないため、別のコレクションに格納されます。ここで、N(d1)レベル 1 ドキュメントをフェッチすることになっています。それぞれにN(d2)いくつかのサブ ドキュメントがあります (1 つのレベル 1 ドキュメントに対するレベル 2 ドキュメントの総数は ですN(d2)) 。

単一のコレクションと各タイプのコレクションにすべてのアイテムの種類を含めることの長所と短所は何ですか。次の点を考慮してください。

• 使用するストレージエンジンはWT
  • DB は、他のドキュメントが同じコレクションに書き込まれている間に読み取ることができます。ここに。
  • 読み取り/書き込みロックはドキュメント レベルであり、以前のケースのようにコレクション レベルではありません。ここに。
• フィールドはタイプごとに異なる可能性があるため、スパース インデックスが許可されます。
• デプロイ タイプはシャード クラスターです
• クエリ可能なすべてのフィールドにインデックスが付けられます (盲目的ではありません) =>$or演算子はインデックスを使用できます
• あるアプローチを支持するポイントは、自動的に、他のアプローチのパフォーマンスの低下につながることを意味します。

ポリモーフィック コレクションの場合のクエリの動作:

• 1 回のクエリ ( を使用) 操作ですべての異なる型を取得し$or、サーバー アプリで親ドキュメントに添付できます。また、aggregate を使用$groupして、1 つのタイプのドキュメントをグループ化することもできます。したがって、
  • ネットワークによって引き起こされるクエリの待ち時間を短縮します。
  • サーバーからの接続数を減らします。
• サブドキュメントは親ドキュメントに添付されるため、サーバー側で for ループが必要です。サブドキュメントがまだグループ化されていない場合は、少なくともドキュメントをループする必要がありN(d1)ます-集約$groupがクエリレベルで使用されている場合-または 時間。N(d1) * N(d2)

各タイプに独自のコレクションがある場合のクエリの動作:

• N(k)クエリが作成され、クエリが返されるとすぐに、サブドキュメントをその親ドキュメントに添付できます。
• ここでも、集計$groupを使用して、サーバー側のループをN(d1)反復に制限できます。

単一のコレクションを支持して：

• 使用される接続数が少ない。(クエリごとに 1 で一貫)
• 一貫したレイテンシ。（以前のポイントの含意として）
• ?

複数を支持して：

• 私たちがより慣れ親しんだ組織構造。(主観)
• ?

それぞれのケースがパフォーマンスにどのように影響する可能性がありますか?

バージョン 2.6 には MMap があるのに対し、mongo はバージョン 3 でデフォルトのストレージ エンジンを WiredTiger に変更したことを知っています。これを使用して、デフォルトのストレージ エンジンを変更できます

3 にアップグレードして WiredTiger を使用する方法についての説明がありますが、バージョン 2.6 のままで WiredTiger を使用できるかどうか疑問に思っています。バージョン 2.6 用の同等のコマンドはありますか?

注: バージョン 2.6 を必要とする共有サーバーを使用しているため、現時点ではアップグレードできません。

MongoDB 2.6 データベースを MongoDB 3.2.10 + WiredTiger に移行しています。移行後、パフォーマンスが向上する代わりに、読み取り/書き込みの応答時間が低下することが観察されました。

唯一の利点は、データベースのサイズが 40% 近く縮小されたことです。

現在、2 つの異なるスタンドアロン サーバーで 2.6 と 3.2.10 + WiredTiger を実行しています。

すべてのテスト レポートは、WiredTiger に対して陰性です。

現在、3.2.10 + WiredTiger に移行する正当な理由は見つかりませんでした。

3.2.10 + WiredTiger のチューニング パラメーターはありますか?

WiredTiger は本番環境で十分に成熟していますか?

私は最近、Mongo 3.0 と 3.2.9 WiredTiger で問題に直面しているというブログ記事を読みました。