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 はキャッシュを
mongodインスタンス全体に割り当てます。WiredTiger は、データベースごとまたはコレクションごとのレベルでキャッシュを割り当てません。
トランザクション（読み取りと書込み）の同時実行性
バージョン 7.0 以降、MongoDB は、デフォルトのアルゴリズムを使用して、ストレージストレージエンジンの同時トランザクションの最大数、または読み取りチケットと書き込みチケットを動的に調整します。ストレージエンジンの同時トランザクションの動的なアルゴリズムは、クラスターの過負荷時にデータベースのスループットを最適化します。
注意
動的アルゴリズムでは、使用可能なチケットのベースライン数がはるかに少ない状態でアルゴリズムが開始されるため、通常の条件下でも、チケット全体の使用量が少なくなります。その結果、 MongoDB 7.0 にアップグレードすると、チケット使用量が大幅に減少する可能性があり、これは期待どおりの動作です。
ストレージエンジントランザクション、または読み取りチケットと書き込みチケットの最大数は、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 圧縮ライブラリによるブロック圧縮を使用し、すべてのインデックスに対して接頭辞圧縮を使用します。ただし、時系列コレクションのデフォルトのブロック圧縮は zstd です。
コレクションに対しては、以下のブロック圧縮ライブラリも利用できます。
代替の圧縮アルゴリズムを指定するか、または圧縮なしを指定するには、 storage.wiredTiger.collectionConfig.blockCompressor設定を使用します。
インデックスの場合、接頭辞圧縮を無効にするには、 storage.wiredTiger.indexConfig.prefixCompression設定を使用します。
圧縮設定は、コレクションおよびインデックスの作成時に、コレクションごとおよびインデックスごとに構成することもできます。「ストレージ エンジン オプションの指定」とdb.collection.createIndex() の storageEngine オプションを参照してください。
ほとんどのワークロードでは、デフォルトの圧縮設定でストレージ効率と処理要件のバランスが保たれます。
WiredTiger ジャーナルもデフォルトで圧縮されます。ジャーナル圧縮の詳細については、「ジャーナル」を参照してください。
メモリの使用
WiredTiger を使用する MongoDB では WiredTiger 内部キャッシュとファイルシステム キャッシュの両方を利用します。
キャッシュ構成設定
デフォルトの WiredTiger 内部キャッシュ サイズは、次のいずれか大きい方です。
（RAM - 1 GB）の 50%、または
0.256 GB.
例、合計が4 GBのRAMを備えたシステムでは、 WiredTigerキャッシュは1.5 GBのRAM （0.5 * (4GB - 1GB) =
1.5 GB ）を使用します。特定のキャッシュサイズを指定する場合は、 RAM が0.256 GBから10000 GBの範囲を超えないようにします。
WiredTiger の内部キャッシュサイズをデフォルト値より大きくしないようにしてください。ケースでそのような必要がある場合は、--wiredTigerCacheSizePct を使用して垂直によるメモリの変更を考慮できます。使用可能なメモリの 80% までの割合を指定する必要があります。計算値の範囲は 0.256 GBから 10000 GBです。例、2 GBのRAMを使用するシステムでは、--wiredTigerCacheSizePct を 10 に設定することはできません。これは、2 GBの 10% が 0.2 GB であり、これは 0 より小さいためです: }.256 GB。
注意
ホストにプロビジョニングされたメモリの量よりも少ないRAMを使用するように構成されたコンテナで実行中場合など、場合によっては、 制限を考慮する必要があります。 WiredTiger は特定のコンテナのメモリ制限を考慮しない場合があるため、 WiredTigerキャッシュを適切な値に構成する必要がある場合があります。
memory limitWiredTiger が使用可能な最大RAM量として使用する値 を表示するには、hostInfo コマンドを使用します。
デフォルトでは、WiredTiger はすべてのコレクションに Snappy ブロック圧縮を使用し、すべてのインデックスに接頭辞圧縮を使用します。圧縮のデフォルトはグローバルレベルで構成可能で、コレクションおよびインデックスの作成時にコレクションごとおよびインデックスごとに設定することもできます。
WiredTiger 内部キャッシュのデータには、ディスク上の形式とは異なる表現が使用されます。
ファイルシステムキャッシュ内のデータは、データファイルを圧縮する利点も含め、ディスク上のフォーマットと同じです。ファイルシステム キャッシュは、ディスク I/O を削減するためにオペレーティング システムによって使用されます。
WiredTiger 内部キャッシュに読み込まれたインデックスのデータ表現は、ディスク上の形式とは異なりますが、インデックスの接頭辞圧縮を利用して RAM の使用量を減らすことができます。インデックスの接頭辞圧縮は、インデックスのあるフィールドから一般的な接頭辞の重複を排除します。
WiredTiger 内部キャッシュ内のコレクション データは非圧縮で、ディスク上の形式とは異なる表現を使用します。ブロック圧縮によりディスク上のストレージを大幅に節約できますが、サーバーで操作するにはデータを解凍する必要があります。
ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。
WiredTiger内部キャッシュのサイズを調整するには、--wiredTigerCacheSizeGB と storage.wiredTiger.engineConfig.cacheSizeGB を参照してください。WiredTiger の内部キャッシュサイズをデフォルト値より大きくしないようにしてください。ユースケースで内部キャッシュサイズを増やす必要がある場合は、--wiredTigerCacheSizePct と storage.wiredTiger.engineConfig.cacheSizePct を参照してください。
ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。
注意
--wiredTigerCacheSizeGB は WiredTiger の内部キャッシュのサイズを制限します。オペレーティング システムは、使用可能な空きメモリをファイルシステム キャッシュに使用するため、圧縮されたMongoDBデータファイルをメモリに保持できます。さらに、オペレーティング システムは、空き RAM を使用して、ファイル システム ブロックとファイル システム キャッシュをバッファリングします。
RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュ サイズを減らす必要がある場合があります。
デフォルトのWiredTiger内部キャッシュサイズの値は、マシンごとに 1 つの mongod インスタンスがあることを前提としています。1 台のマシンに複数のMongoDBインスタンスが存在する場合は、設定値を減らして他の mongod インスタンスに対応できるようにしてください。
システムで使用可能なすべてのRAMにアクセス mongodできないコンテナ（lxc cgroups、--wiredTigerCacheSizeGB 、 Dockerなど）で を実行する場合は、 または--wiredTigerCacheSizePct を設定する必要があります}を、コンテナで使用可能なRAMの量より小さい値に設定します。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。詳しくは、memLimitMB を参照してください。
--wiredTigerCacheSizeGB または --wiredTigerCacheSizePct のいずれか 1 つだけを提供できます。