MongoDB MMAPv1対WiredTigerストレージエンジン
MongoDB3に新しいストレージエンジンが登場しました： WiredTiger 。 ただし、 MMAPv1 は引き続きMongoのデフォルトの選択です。
一方が他方よりも優れているとは限りませんが、それは多くの場合、ユースケースとジョブに適したツールの選択の問題です。しかし、どのエンジンがどの仕事に適していますか？
実際には、 mMAPv1がデフォルトのエンジンですが、 WiredTigerはほとんどすべての分野で優れているようです。 MMAPv1 plusと同じ機能があります。
- 書き込みパフォーマンスの向上、
- ドキュメントレベルの同時実行性
- 圧縮、
- スナップショットとチェックポイントシステム。
MongoDBのブログ で比較表を見つけました：
Solarisを使用している場合を除いて、WiredTigerを選択しない理由はありますか？
編集
WiredTiger および MMAPv1 の内部を詳細に説明する2つのビデオを以下に示します。
個人的には、3つの理由から、現時点ではmmapv1ストレージエンジンを好みます。
理由1：成熟度
WiredTigerが未熟なわけではありません。しかし、mmapv1は十分に理解されており、上下、前後、およびそれ以上に至るまで、あらゆる面で戦闘テストが行われています。 WiredTigerには最近かなりの問題（詳細は http://jira.mongodb.com を参照）があり、私は顧客に次の問題を難しい方法で見つけてほしくありません。
理由2：機能
与えられた、WTにはいくつかのf ...根本的に素晴らしい機能があります。重要なのは、私はそれらから恩恵を受けている人を見たことがありません。圧縮？どちらの方法でも、かなり安いパフォーマンスを達成するためにかなり難しい犠牲を払うことです。ディスク容量。ドキュメントを展開するためのドキュメント移行の問題がない？ええと、16MBのサイズ制限があり、埋め込みドキュメントの複雑さが増しています。
他の機能もありますが、一般的には、今のところそれらの利点はあまりありません。
理由3：総所有コスト
新規プロジェクトの場合、WTで問題ない可能性があります。特に3.2以降は、以下が適用されないためです。
データの移行はexpensiveです。それは計画される必要があり、計画はすべての利害関係者によって合意される必要があり、緊急時の緊急時計画は作成され、合意される必要があり、移行は準備され、実行され、レビューされる必要があります。次に、このプロセスの一部である利害関係者との所要時間と、データ移行のコストが急増します。一方、投資収益率はかなり小さいようです。これらの要因を考慮に入れれば、移行を行う代わりにかなりの規模で拡張できます。印象を与えるために：移行が計画され、実行され、適切にレビューされる場合、私は利害関係者ごとにおよそ「1週間」と推定します。 1人あたり1時間あたり100ドルの費用がかかり、関係者は3人（マネージャー、DBA、および開発者）で、これは12.000ドルになります。これは控えめな見積もりです。
結論
上記のこれらすべての要因により、WT=まったく使用しないという結論に至りました。現時点では。
更新
この投稿は数か月前のものなので、更新する必要があります
満期に
成熟度に関する私の元のコメントは、ちょっと時代遅れです。 WiredTigerは今のところ大きな問題はなく、MongoDB 3.2のデフォルトのストレージエンジンになっています。
機能について
私の元のコメントはまだある程度の妥当性を持っています、imho.
圧縮
ただし、予算が厳しい場合、またはより一般的に言えばパフォーマンスは主要な問題ではなく、パフォーマンスのトレードオフはかなり小さく、基本的には（圧縮されていないWTと比較した場合）パフォーマンスへのわずかな影響をディスクスペースと引き換えに、アイドル状態になるものを利用します。周り：CPU。
暗号化
MongoDB 3.2 Enterpriseでは、WiredTigerストレージを暗号化する機能が導入されました。強化されたセキュリティニーズを持つデータの場合、これはキラー機能であり、技術的にも（MMAPv1は暗号化をサポートしていません）、概念的にはWTが唯一の選択可能なストレージエンジンになります。暗号化されたディスクの可能性を脇に置きます。もちろん、パーティションもありますが、環境によってはそのオプションがない場合があります。
ドキュメントレベルのロック
上記の分析でWT）の機能を基本的に省略したことを認めなければなりません。これは主に、元の回答を書いたときに私や顧客に当てはまらなかったためです。
設定によっては、主に同時書き込みクライアントが多い場合、この機能によりパフォーマンスが大幅に向上する場合があります。
総所有コストについて
移行を行うには、まだコストがかかります。ただし、成熟度の変化と機能の変更されたビューを考慮すると、次の場合、移行は投資に値する可能性があります。
- 暗号化が必要です（Enterprise Editionのみ！）
- パフォーマンスは絶対的な主な関心事ではなく、圧縮を使用して長期的に節約できます（控えめに計算）。
- パフォーマンスの向上により垂直方向または水平方向のスケーリングが節約される可能性があるため、同時に書き込む多くのプロセスがあります。
更新された結論
新しいプロジェクトの場合は、現在WiredTigerを使用しています。圧縮ストレージから非圧縮WiredTigerストレージへの移行はかなり簡単なので、CPU使用率を向上させるために圧縮から始める傾向があります（「コストを削減する」ため）。圧縮がパフォーマンスまたはUXに顕著な影響を与える場合は、非圧縮のWiredTigerに移行します。
多数の同時執筆者がいるプロジェクトの場合、移行するかどうかの答えは、プロジェクトの予算で投資が禁止されていない限り、ほとんど常に「はい」です。長期的には、展開が合理的に計画されていた場合、パフォーマンスの向上はそれだけで十分です。ただし、場合によってはドライバーを更新する必要があり、対処する必要のある問題がある可能性があるため、計算に開発時間を追加する必要があります。
予算が厳しく、現在のところディスク容量が足りないプロジェクトの場合、圧縮されたWiredTigerに移行することもできますが、圧縮によってCPUに少し負荷がかかります。これはMMAPv1にはないものです。さらに、そのようなプロジェクトでは、移行コストが法外に高くつく場合があります。
私の2セント：
WiredTiger でのジャーナリングは、ジャーナルレコードの保存にメモリ内バッファリングを使用するため、ハードシャットダウン時に更新を失う可能性があります。
書き込み操作の合間に、ジャーナルレコードがWiredTigerバッファーに残っている間、mongodのハードシャットダウン後に更新が失われる可能性があります。
MMAPv1 のジャーナリングは、ディスク上のジャーナルファイルに変更を書き込みます。
Mongodインスタンスがデータファイルへの書き込みを適用せずにクラッシュした場合、ジャーナルは、データファイルへの最終的な書き込みのために共有ビューへの書き込みを再生できます。
7倍から10倍のパフォーマンス向上の魅力で、MMAPv1からWiredTigerに移行しました。 WiredTigerキャッシュが100％に達するとMongoDBがロックするため、MMAPv1に戻す必要がありました。ここで私たちの経験を文書化しました- https://blog.clevertap.com/sleepless-nights-with-mongodb-wiredtiger-and-our-return-to-mmapv1/