Docs Menu

FAQ: MongoDB Storage for Self-Managed Deployments

This document addresses common questions regarding MongoDB's storage system.

A storage engine is the part of a database that is responsible for managing how data is stored, both in memory and on disk. Many databases support multiple storage engines, where different engines perform better for specific workloads. For example, one storage engine might offer better performance for read-heavy workloads, and another might support a higher throughput for write operations.

以下も参照してください。

Yes. You can have replica set members that use different storage engines (WiredTiger and in-memory)

Cluster performance might degrade once the combined number of collections and indexes reaches beyond 100,000. In addition, many large collections have a greater impact on performance than smaller collections.

Yes. See:

The ratio of compressed data to uncompressed data depends on your data and the compression library used. By default, collection data in WiredTiger use Snappy block compression; zlib and zstd compression is also available. Index data use prefix compression by default.

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 の内部キャッシュ サイズをデフォルト値より大きくしないようにしてください。

注意

storage.wiredTiger.engineConfig.cacheSizeGB は WiredTiger の内部キャッシュのサイズを制限します。オペレーティング システムは、使用可能な空きメモリをファイルシステム キャッシュに使用するため、圧縮されたMongoDBデータファイルをメモリに保持できます。さらに、オペレーティング システムは、空き RAM を使用して、ファイル システム ブロックとファイル システム キャッシュをバッファリングします。

RAM の利用者増加に対応するためには、WiredTiger の内部キャッシュ サイズを減らす必要がある場合があります。

デフォルトの WiredTiger 内部キャッシュ サイズ値は、マシンごとに単一の mongod インスタンスが存在することを想定しています。1 台のマシンに複数の MongoDB インスタンスがある場合は、設定値を減らして他の mongod インスタンスに対応できるようにしてください。

システムで使用可能なすべての RAM にアクセスできないコンテナ(lxccgroups、Docker など)で mongod を実行する場合は、コンテナで使用可能な RAM の量よりも小さい値に storage.wiredTiger.engineConfig.cacheSizeGB を設定する必要があります。正確な量は、コンテナ内で実行中の他のプロセスによって異なります。memLimitMB参照してください。

キャッシュと削除率の統計を表示するには、wiredTiger.cache コマンドから返されるserverStatus フィールドを参照してください。

Each connection uses up to 1 megabyte of RAM.

To optimize memory use for connections, ensure that you:

  • Monitor the number of open connections to your deployment. Too many open connections result in excessive use of RAM and reduce available memory for the working set.

  • Close connection pools when they are no longer needed. A connection pool is a cache of open, ready-to-use database connections maintained by the driver. Closing unneeded pools makes additional memory resources available.

  • Manage the size of your connection pool. The maxPoolSize connection string option specifies the maximum number of open connections in the pool. By default, you can have up to 100 open connections in the pool. Lowering the maxPoolSize reduces the maximum amount of RAM used for connections.

    Tip

    To configure your connection pool, see 接続プールの構成設定.

Checkpoints
MongoDB は チェックポイント を作成するように WiredTiger を構成し、具体的には60秒の間隔でスナップショット データをディスクに書き込むようにします。
Journal Data
WiredTiger では、次のいずれかの条件で、バッファされたジャーナル レコードがディスクに同期されます。
  • レプリカセットのノード(プライマリおよびセカンダリ)の場合

    • 書込み操作にj: trueの書込み保証が含まれているか、または暗示されている場合。

    • さらにセカンダリノードの場合は、oplog エントリの各バッチ適用後に同期されます。

    注意

    writeConcernMajorityJournalDefault が true であれば、書込み保証 "majority"j: true であることを意味します。

  • 100ミリ秒ごと( storage.journal.commitIntervalMsを参照してください)。

  • WiredTiger が新しいジャーナル ファイルを作成する場合。MongoDB ではジャーナル ファイルのサイズが 100 MB に制限されているため、WiredTiger ではデータ約 100 MB ごとに新しいジャーナル ファイルが作成されます。

The WiredTiger storage engine maintains lists of empty records in data files as it deletes documents. This space can be reused by WiredTiger, but will not be returned to the operating system unless under very specific circumstances.

The amount of empty space available for reuse by WiredTiger is reflected in the output of db.collection.stats() under the heading wiredTiger.block-manager.file bytes available for reuse.

To allow the WiredTiger storage engine to release this empty space to the operating system, you can de-fragment your data file. This can be achieved by resyncing a replica set member or using the compact command.

To view the statistics for a collection, including the data size, use the db.collection.stats() method from within mongosh. The following example issues db.collection.stats() for the orders collection:

db.orders.stats();

MongoDB also provides the following methods to return specific sizes for the collection:

The following script prints the statistics for each database:

db.adminCommand("listDatabases").databases.forEach(function (d) {
mdb = db.getSiblingDB(d.name);
printjson(mdb.stats());
})

The following script prints the statistics for each collection in each database:

db.adminCommand("listDatabases").databases.forEach(function (d) {
mdb = db.getSiblingDB(d.name);
mdb.getCollectionNames().forEach(function(c) {
s = mdb[c].stats();
printjson(s);
})
})

To view the size of the data allocated for each index, use the db.collection.stats() method and check the indexSizes field in the returned document.

If an index uses prefix compression (which is the default for WiredTiger), the returned size for that index reflects the compressed size.

The db.stats() method in mongosh returns the current state of the "active" database. For the description of the returned fields, see dbStats Output.