MongoDB用のMMAPV1、WiredTiger、またはIn-Memory StorageEngineの選択方法

Question

MongoDb Documentation 3.2では、3つのストレージエンジン、MMAPV1、WiredTiger、In-Memoryをサポートしていることがわかりました。どちらを選択するかは非常にわかりにくいです。

私はWiredTigerがMMAPV1より優れているという説明から感覚を持っていますが、他の情報源では、MMAPV1が重い読み取りに優れていると言います...そして、WiredTigerは重い書き込みに適しています...

どちらを選択するかについて、いくつかの制約はありますか？例えば誰かがいくつかのベストプラクティスを提案できますか

私がこのタイプのアプリケーションを持っているときは、通常これが最善です、そうでない場合は他のものを選択してください...

Tim · Accepted Answer

これは個人的な経験によるものですが、さまざまな種類のエンジンについて非常によく説明されているこのブログエントリをご覧ください。 Mongo Blog v

MongoDB WiredTigerとMMAPv1ストレージエンジンの比較：書き込みパフォーマンスが7倍から10倍のパフォーマンスと効率の向上MongoDB 3.0は、より詳細なドキュメントレベルの同時実行制御を提供し、ほとんどの書き込み集約型アプリケーションのスループットを7倍から10倍向上させ、予測可能な低遅延を維持します。

私にとって選択は非常に簡単で、ドキュメントレベルのロックが必要でした。これにより、WiredTigerが理想的な選択になります。利用不可。 MMAPv1 Btreeは、メモリをハードドライブにマップするための非常に基本的な手法であり、あまり効率的ではありません。

MMAPストレージエンジンは、「レコード割り当て」と呼ばれるプロセスを使用して、ドキュメントストレージ用のディスクスペースを取得します。すべてのレコードはディスク上で連続して配置され、ドキュメントが割り当てられたレコードよりも大きくなった場合、新しいレコードを割り当てる必要があります。新しい割り当てでは、ドキュメントを移動し、ドキュメントを参照するすべてのインデックスを更新する必要があります。これは、インプレース更新よりも時間がかかり、ストレージの断片化につながります。さらに、現在の反復でのMMAPv1は、通常、レコードスペースの過剰割り当てと圧縮のサポート不足により、ファイルシステムのスペース使用率が高くなります。前述のように、ストレージエンジンのロックスキームは、データベース全体のパフォーマンスにおいて最も重要な要素の1つです。 MMAPv1にはコレクションレベルのロックがあります。つまり、一度に1つの挿入、更新、または削除操作のみがコレクションを使用できます。このタイプのロックスキームは、同時ワークロードで非常に一般的なシナリオを作成します。このシナリオでは、更新/削除/挿入操作は常に、その前の操作の完了を待機しています。さらに、多くの場合、これらの操作は、ストレージエンジンによって順次実行されるよりも速く流れます。コンテキストに当てはめると、日曜日の午後にチェックアウトラインが1つだけ開いている巨大なスーパーマーケットを想像してください。

誰もがさまざまな要件を持っていますが、ほとんどの場合、WiredTigerはコレクションレベルではなくドキュメントレベルでアトミック操作を行うという点で理想的な選択になります。

多くの読み取りではなく、多くの書き込み

読書があなたの主な関心事である場合、ここでそれに対処する1つの方法です。

Mongoドライバーを微調整できます環境設定モードの読み取り次の方法で：

レプリカセットをセットアップします。たとえば、1つのマスターと3つのセカンダリがあります。
書き込みの懸念を majority に設定すると、書き込みが少し遅くなります（トレードオフ）。
読み取り設定をセカンダリに設定します。

この設定は、読み取りが多い場合に非常によく機能しますが、トレードオフとして書き込みが遅くなります。ただし、読み取りデータのスループットは優れています。

追加の質問がコメントとして追加されている場合にこれが役立つことを願っています。この回答で対処しようとします。

また、 MMAPv1 vs WiredTiger を確認して、MMAPv1からWiredTigerに変わったことを確認してください。売り手は、あなたが負けないパフォーマンスを文書でロックしています。

新しいプロジェクトでは、現在WiredTigerを使用しています。圧縮されたWiredTigerストレージから圧縮されていないWiredTigerストレージへの移行はかなり簡単なので、CPU使用率を高めるために圧縮から始める傾向があります（「コストを削減」）。圧縮がパフォーマンスまたはUXに顕著な影響を与える場合、非圧縮のWiredTigerに移行します。

MongoDBデータベースプロファイラー

データベースのニーズを判断する最良の方法は、テストクラスターをセットアップし、 MongoDBプロファイラーでアプリケーションを実行することです。ほとんどのデータベースプロファイラーと同様に、MongoDBプロファイラーは、与えられたしきい値。したがって、クエリが遅いとわかったら、読み取りvs書き込みまたはCPU vs ramのどちらであるかを把握して、そこから進むことができます。

Arka Ghosh · Answer

メモリ内とWiredTigerの両方ストレージエンジンで構成されるレプリカセットを使用する必要があります。また、最も頻繁に使用されるデータにインメモリストレージエンジンがアクセスし、残りがWiredTigerストレージエンジンを使用するように、MongoDBを分割する必要があります。

2014年にWiredTigerを買収した後、MongoDBはこのストレージエンジンをバージョン3.2のデフォルトのストレージエンジンとして導入しました。その後、MMAPV1に比べて次のような利点があるため、ユーザー自身がWiredTigerの使用を推奨し始めました。

WiredTigerはドキュメントレベルの同時実行を使用しますが、MMAPV1はコレクションレベルのロックを使用します。つまり、WiredTigerを使用して複数のユーザーがコレクションに同時に書き込むことができますが、MMAPV1は使用できません。
WiredTigerは独自のメモリを管理するため、圧縮を使用できますが、MMPAV1にはそのような機能はありません。
WiredTigerはインプレース更新を許可しません。したがって、最終的には、使用されなくなったスペースを回収します。

これまでに発見したWiredTigerに対するMMPAV1の利点は次のとおりです。

WiredTigerは、Solarisプラットフォームでは利用できませんが、MMPAV1は利用できます。
単一の要素のみを使用して大きなドキュメントを更新している場合でも、WiredTigerはドキュメント全体を書き直して速度を低下させます。

そのため、ストレージエンジンを選択する際にMMPAV1をいつでも省略できます。次に、インメモリストレージエンジンのポイントに行きましょう。 MongoDB Enterpriseバージョン3.2.6以降、インメモリストレージエンジンは64ビットビルドの一般的な可用性（GA）の一部です。

ストレージエンジンに対して次の利点があります。

WiredTigerと同様に、インメモリストレージエンジンではドキュメントレベルの同時実行も可能です。
インメモリストレージエンジンは他のエンジンよりも高速です。

ディスクI/Oを回避することにより、インメモリストレージエンジンは、データベース操作のより予測可能な遅延を可能にします。

しかし、このストレージエンジンにはいくつかの欠点もあります。

インメモリストレージエンジンは、プロセスのシャットダウン後にデータを保持しません。
データセットが大きすぎる場合、メモリ内エンジンは適切なオプションではありません。

インメモリストレージエンジンでは、すべてのデータ（mongodがレプリカセットの一部である場合はoplogなど）が、指定された--inMemorySizeGBコマンドラインオプションまたはstorage.inMemory.engineConfig.inMemorySizeGB設定に適合する必要があります。

たとえば、MongoDBマニュアルで Deployment Architectures インメモリストレージエンジンを使用します。