MMAPv1ストレージエンジンでは、ドキュメントのインデックスがファイルの場所とオフセットを直接指しているため、最適化戦略としてインプレース更新が頻繁に強調されます。ドキュメントを新しい保存場所に移動すると（特に、更新するインデックスエントリが多数ある場合）、変更されたフィールドを更新するだけでよいインプレース更新よりも、MMAPv1のオーバーヘッドが大きくなります。参照：MMAPv1のストレージ特性の記録。
WiredTigerは、データベース管理システムで一般的に使用されるMVCC（Multiversion Concurrency Control）を内部的に使用するため、インプレース更新をサポートしていません。これは、MMAPの単純なビューに比べて大幅な技術的改善であり、分離レベルやトランザクションなどのより高度な機能を構築できます。 WiredTigerのインデックスには間接的なレベルがあるため（ファイルの場所とオフセットではなく内部のRecordIDを参照）、ストレージレベルでのドキュメントの移動は重大な問題ではありません。
ただし、この記事には、「[WiredTiger]ではインプレース更新が許可されていなくても、多くのワークロードでMMAPよりもパフォーマンスが向上する可能性がある」とも記載されています。
つまり、MMAPv1にはインプレース更新のより効率的なパスがありますが、WiredTigerには、圧縮や同時実行制御の改善などの他の利点があります。 MMAPv1でパフォーマンスが向上する可能性のある、いくつかのドキュメントへのインプレース更新のみで構成されるワークロードを構築することもできますが、実際のワークロードは通常、より多様です。特定のワークロードへの影響を確認する唯一の方法は、代表的な環境でテストすることです。
ただし、将来の計画を立てる場合は、MMAPv1とWiredTigerの一般的な選択は重要ではありません。MongoDB3.2以降、WiredTigerがデフォルトのストレージエンジンであり、一部の新しい製品機能はMMAPv1でサポートされていません。たとえば、MMAPv1はMajority Read Concernをサポートしていません。つまり、レプリカセット構成サーバー（MongoDB 3.4以降のシャーディングに必要）または変更ストリーム（MongoDB 3.6以降）には使用できません。 MMAPv1は、MongoDB（4.0）の次のメジャーリリースで非推奨になり、現在、MongoDB4.2で削除される予定です。
WiredTigerを使用するときに注意しなければならない正確な影響は何ですか？たとえば、インプレース更新がないと、データベースのサイズは急速に大きくなりますか？
ストレージの結果は、スキーマの設計、ワークロード、構成、MongoDBサーバーのバージョンなどのいくつかの要因によって異なります。 MMAPv1とWiredTigerは異なるレコード割り当て戦略を使用しますが、どちらも空き/再利用可能としてマークされた事前に割り当てられたスペースを使用しようとします。一般に、WiredTigerはストレージスペースを使用する方が効率的であり、データとインデックスを圧縮できるという利点もあります。 MMAPv1は、追加のストレージスペースを割り当てて、インプレース更新を最適化し、ドキュメントの移動を回避しようとしますが、ワークロードによってドキュメントサイズが時間の経過とともに変化しないコレクションには、「パディングなし」の戦略を選択できます。
WiredTigerがMongoDB3.0で最初に導入されて以来、さまざまなワークロード向けにWiredTigerを改善および調整するために多大な投資が行われているため、最良の結果を得るには、最新の製品リリースシリーズでテストすることを強くお勧めします。スキーマの設計とストレージの拡張について具体的な質問がある場合は、DBAStackExchangeに詳細を投稿して議論することをお勧めします。
また、MongoDB 3.6のWiredTigerが、ドキュメント全体を書き直すのではなく、デルタを保存する機能を追加したことも学びました（https://jira.mongodb.org/browse/DOCS-11416）。これは正確にはどういう意味ですか？
これは、一部のユースケースでWiredTigerの内部データ構造を改善する実装の詳細です。特に、MongoDB 3.6以降のWiredTigerは、（以前のリリースと比較して）大きなドキュメントへの小さな変更をより効率的に処理できます。 WiredTigerキャッシュは、開いている内部セッション（前述のように、MVCC）で使用されている限り、複数のバージョンのドキュメントを返すことができる必要があります。したがって、更新が少ない大きなドキュメントの場合は、デルタのリストを保存する方が効率的です。ただし、蓄積されるデルタが多すぎる場合（または、デルタがドキュメント内のほとんどのフィールドを変更している場合）、このアプローチは、ドキュメント全体の複数のコピーを維持するよりもパフォーマンスが低下する可能性があります。
データがチェックポイントを介してディスクにコミットされる場合でも、ドキュメントのフルバージョンを書き込む必要があります。内部のいくつかについて詳しく知りたい場合は、MongoDB4.0でマルチドキュメントトランザクションをサポートする機能の開発に続くMongoDBPathToTransactionsシリーズのビデオがあります。
また、私が理解していないのは、最近のほとんどの（すべてではないにしても）ハードドライブのセクターサイズは4096バイトであるため、ハードドライブに書き込むことはできません（たとえば）。代わりに、4096のブロック全体を書き込む必要があります。バイト（最初にそれを読み取り、その中の4バイトを更新してから書き込みます）。ほとんどのドキュメントは4096バイト未満であることが多いため、これは、どのような場合でも（MMAPを使用する場合でも）ドキュメント全体を書き直す必要があることを意味します。何が恋しかったですか？
実装の詳細に深く入り込むことなく、関連するすべての可動部分を説明しようとせずに、（単一のドキュメントレベルではなく）多くのドキュメントが更新されるワークロードにさまざまなアプローチがどのように適用されるか、およびメモリ使用量への影響（以前ドキュメントはディスクに書き込まれます）。ドキュメントのサイズや圧縮などの要因に応じて、I / Oの単一のブロックは、ドキュメントの一部（最大サイズ16MB）から複数のドキュメントまでのどこでも表すことができます。
MongoDBの一般的なフローは、ドキュメントがメモリ内ビュー（WiredTigerキャッシュなど）で更新され、変更がデータファイルに定期的にフラッシュされる前に高速追加専用ジャーナル形式でディスクに保持されることです。 O / Sが変更されたデータのブロックのみを書き込む必要がある場合、タッチするデータのブロックが少ないほど、全体的なI/Oが少なくて済みます。