WiredTiger ストレージ エンジン
WiredTiger ストレージ エンジンはデフォルトのストレージ エンジンです。 既存の配置では、--storageEngine またはstorage.engine 設定を指定しない場合、mongod インスタンスは、--dbpath または のデータファイルを作成するために使用されるストレージstorage.dbPath エンジンを自動的に決定できます。 .
次の環境でホストされている配置では、WiredTiger ストレージ エンジンを使用できます。
MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです
注意
すべての MongoDB Atlas 配置では、WiredTiger ストレージ エンジンが使用されます。
MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン
MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン
MongoDB Atlas でホストされている配置の WiredTiger メモリ使用量の詳細については、「メモリ 」を参照してください。
操作と制限
WiredTiger エンジンには、次の操作上の注意事項と制限が適用されます。
ドキュメントを WiredTiger キャッシュにピン留めすることはできません。
WiredTiger は、キャッシュの一部を読み取り用に、別の部分を書き込み用に予約しません。
書き込みの負荷が大きいとパフォーマンスに影響しますが、WiredTigerはそのような場合インデックスキャッシュを優先します。
WiredTiger はキャッシュを
mongodインスタンス全体に割り当てます。WiredTiger は、データベースごとまたはコレクションごとのレベルでキャッシュを割り当てません。
トランザクション（読み取りと書込み）の同時実行性
バージョン7.0以降、 MongoDB は、デフォルトのアルゴリズムを使用して、ストレージエンジンの同時トランザクション（読み取りチケットと書き込みチケット）の最大数を動的に調整します。 ストレージエンジンの同時トランザクションの動的なアルゴリズムは、クラスターの過負荷時にデータベースのスループットを最適化します。 ストレージエンジンの同時実行トランザクション（読み取りチケットと書き込みチケット）の最大数は128読み取りチケットと128書き込みチケットを超えることはなく、クラスター内のノードによって異なる場合があります。 1 つのノード内の読み取りチケットと書き込みチケットの最大数は常に同じです。
動的な最大値が超えることのできない読み取りおよび書込みトランザクション（読み取りおよび書込みチケット）の最大数を指定するには、 storageEngineConcurrentReadTransactionsとstorageEngineConcurrentWriteTransactions使用します。
ストレージエンジンの同時トランザクションの動的なアルゴリズムを無効にする場合は、MongoDB テクニカル サービス エンジニアと連携するためのサポートリクエストをお申し込みください。
WiredTiger ストレージエンジンで許可されている同時読み取りトランザクション（読み取りチケット）と書き込みトランザクション（書き込みチケット）の数を表示するには、serverStatus コマンドを使用して queues.execution 応答ドキュメントを確認します。
注意
queues.execution にある available の値が低い場合でも、クラスターの過負荷を示すものではありません。クラスターの過負荷の指標としては、キューに並んでいる読み取りチケットと書き込みチケットの数を使用します。
ドキュメント レベルの同時実行
WiredTigerは書き込み操作にドキュメントレベルの同時実行制御を使用します。その結果、複数のクライアントがコレクション内の異なるドキュメントを同時に変更できるようになります。
ほとんどの読み取りおよび書き込み操作で、WiredTiger はオプティミスティック同時実行制御を使用します。 WiredTiger は、グローバル、データベース、コレクション レベルで意向ロックのみを使用します。storage engineが 2 つの操作間の競合を検出すると、1 つの操作で書込み競合 (write conflict)が発生し、MongoDB はその操作を透過的に再試行します。
一部のグローバル操作（通常は複数のデータベースに関係する短時間の操作）では、依然としてグローバルな「インスタンス全体」のロックが必要です。 renameCollectionなどの他の操作では、依然として特定の状況で排他的データベース ロックが必要です。
スナップショットとチェックポイント
WiredTiger は MultiVersion Concurrency Control (MVCC) を使用します。操作の開始時に、WiredTiger はデータの点インタイムスナップショットを操作に提供します。スナップショットは、メモリ内のデータの一貫したビューを提供します。
ディスクに書き込むとき、WiredTigerはスナップショット内のすべてのデータを、すべてのデータファイルにわたって一貫した方法でディスクに書き込みます。こうして耐久性のあるデータが、データファイルのチェックポイントとして機能します。チェックポイントにより、最後のチェックポイントまでデータファイルの整合性が保たれます。つまり、チェックポイントは復元ポイントとして機能します。
MongoDB は チェックポイント を作成するように WiredTiger を構成し、具体的には60秒の間隔でスナップショット データをディスクに書き込むようにします。
新しいチェックポイントの書き込み中も、前のチェックポイントは有効です。そのため、MongoDB が新しいチェックポイントの書き込み中に終了したり、エラーが発生したりした場合でも、再起動時に MongoDB は最後の有効なチェックポイントから回復できます。
WiredTiger のメタデータテーブルが新しいチェックポイントを参照するようにアトミックにアップデートされると、新しいチェックポイントはアクセス可能で永続的になります。新しいチェックポイントにアクセスできるようになると、WiredTiger は古いチェックポイントからページを解放します。
スナップショット履歴の保持
MongoDB 5.0 以降では、 minSnapshotHistoryWindowInSecondsパラメータを使用して、WiredTiger がスナップショット履歴を保持する期間を指定できます。
minSnapshotHistoryWindowInSeconds の値を増やすと、サーバーは指定された時間枠内で古い変更値の履歴を維持する必要があるため、ディスク使用量が増加します。使用されるディスク容量はワークロードによって異なり、ワークロードのボリュームが大きいほど、より多くのディスク容量が必要になります。
MongoDB は、指定された dbPath にあるWiredTigerHS.wtファイルにスナップショット履歴を保持します
Journal
WiredTiger は、先行書き込みログ（つまり、ジャーナル）をチェックポイントと組み合わせて使用することで、データの耐久性を確保します。
WiredTiger ジャーナルは、チェックポイント間のすべてのデータ変更を保持します。MongoDB がチェックポイント間で終了する場合、ジャーナルを使用して最後のチェックポイント以降に変更されたすべてのデータを再生します。MongoDB がジャーナル データをディスクに書き込む頻度については、 「ジャーナリング プロセス」を参照してください。
WiredTiger ジャーナルは snappy 圧縮ライブラリを使用して圧縮されます。別の圧縮アルゴリズムを指定するか、圧縮を行わない場合は、 storage.wiredTiger.engineConfig.journalCompressor設定を使用します。 ジャーナルコンプレッサーの変更の詳細については、「WiredTiger ジャーナルコンプレッサーの変更」を参照してください。
注意
ログ レコードが 128 バイト（WiredTiger の最小ログ レコード サイズ）未満の場合、WiredTiger はそのレコードを圧縮しません。
圧縮
WiredTiger により、MongoDB はすべてのコレクションとインデックスの圧縮をサポートします。圧縮により、CPU の使用量増加と引き換えに、ストレージの使用を最小限に抑えます。
デフォルトでは、WiredTiger はすべてのコレクションに対して snappy 圧縮ライブラリによるブロック圧縮を使用し、すべてのインデックスに対して接頭辞圧縮を使用します。
コレクションに対しては、以下のブロック圧縮ライブラリも利用できます。
代替の圧縮アルゴリズムを指定するか、または圧縮なしを指定するには、 storage.wiredTiger.collectionConfig.blockCompressor設定を使用します。
インデックスの場合、接頭辞圧縮を無効にするには、 storage.wiredTiger.indexConfig.prefixCompression設定を使用します。
圧縮設定は、コレクションおよびインデックスの作成時に、コレクションごとおよびインデックスごとに構成することもできます。「ストレージ エンジン オプションの指定」とdb.collection.createIndex() の storageEngine オプションを参照してください。
ほとんどのワークロードでは、デフォルトの圧縮設定でストレージ効率と処理要件のバランスが保たれます。
WiredTiger ジャーナルもデフォルトで圧縮されます。ジャーナル圧縮の詳細については、「ジャーナル」を参照してください。
メモリの使用
WiredTiger を使用する MongoDB では WiredTiger 内部キャッシュとファイルシステム キャッシュの両方を利用します。
デフォルトの WiredTiger 内部キャッシュ サイズは、次のいずれか大きい方です。
（RAM-1 GB）の50%、または
256 MB.
たとえば、合計が4 GB の RAM を備えたシステムでは、WiredTiger キャッシュは1.5 GB の RAM を使用します（ 0.5 * (4 GB - 1 GB) =
1.5 GB ）。 逆に、合計が1.25のシステムでは GBのRAM WiredTigerは 256 MB をWiredTigerキャッシュに割り当てます。これはRAMの合計の半分以上で 1 ギガバイト（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）を引いた値であるためです。
注意
コンテナで実行している場合など、場合によっては、データベースのメモリが制約され、システムメモリの合計よりも少なくなることがあります。このような場合、システム メモリの合計ではなく、このメモリ上限が、使用可能な最大 RAM として使用されます。
メモリ制限を確認するには、hostInfo.system.memLimitMB を参照してください。
デフォルトでは、WiredTiger はすべてのコレクションに Snappy ブロック圧縮を使用し、すべてのインデックスに接頭辞圧縮を使用します。圧縮のデフォルトはグローバルレベルで構成可能で、コレクションおよびインデックスの作成時にコレクションごとおよびインデックスごとに設定することもできます。
WiredTiger 内部キャッシュのデータには、ディスク上の形式とは異なる表現が使用されます。
ファイルシステムキャッシュ内のデータは、データファイルを圧縮する利点も含め、ディスク上のフォーマットと同じです。ファイルシステム キャッシュは、ディスク I/O を削減するためにオペレーティング システムによって使用されます。
WiredTiger 内部キャッシュに読み込まれたインデックスのデータ表現は、ディスク上の形式とは異なりますが、インデックスの接頭辞圧縮を利用して RAM の使用量を減らすことができます。インデックスの接頭辞圧縮は、インデックスのあるフィールドから一般的な接頭辞の重複を排除します。
WiredTiger 内部キャッシュ内のコレクション データは非圧縮で、ディスク上の形式とは異なる表現を使用します。ブロック圧縮によりディスク上のストレージを大幅に節約できますが、サーバーで操作するにはデータを解凍する必要があります。
ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。
WiredTiger 内部キャッシュのサイズを調整するには、 storage.wiredTiger.engineConfig.cacheSizeGBと--wiredTigerCacheSizeGBを参照してください。WiredTiger の内部キャッシュ サイズをデフォルト値より大きくしないようにしてください。