FAQ: 自己管理型配置の MongoDB ストレージ

ストレージエンジンとは？

ストレージ エンジンとは、メモリ上とディスク上の両方でのデータ保存方法を管理するデータベースの一部分です。多くのデータベースは複数のストレージ エンジンをサポートしており、優れたパフォーマンスを発揮するエンジンはワークロードによって異なります。たとえば、あるストレージ エンジンは、読み取りが多いワークロードに対してより優れたパフォーマンスを提供し、別のストレージ エンジンは、書込み操作に対してより高いスループットをサポートする場合があります。

クラスター内で配置できるコレクションとインデックスの数

コレクションとインデックスの合計数が 100,000 を超えると、クラスターのパフォーマンスが低下する可能性があります。さらに大規模なコレクションが多い場合は、小規模なコレクションに比べてパフォーマンスへの影響が大きくなります。

既存の配置を WiredTiger にアップグレードできますか。

はい。以下を参照してください。

• 自己管理型スタンドアロンを WiredTiger に変更

• 自己管理型レプリカセットを WiredTiger に変更

• 自己管理型シャーディングされたクラスターを WiredTiger に変更

WiredTiger での圧縮率

圧縮データと非圧縮データの比率は、データと使用される圧縮ライブラリによって異なります。デフォルトでは、WiredTiger のコレクション データには Snappy ブロック圧縮が使用されます。 zlib および zstd 圧縮も利用可能です。インデックスデータはデフォルトで接頭辞圧縮を使用します。

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 ）です。

デフォルトでは、WiredTiger はすべてのコレクションに Snappy ブロック圧縮を使用し、すべてのインデックスに接頭辞圧縮を使用します。圧縮のデフォルトはグローバルレベルで構成可能で、コレクションおよびインデックスの作成時にコレクションごとおよびインデックスごとに設定することもできます。

WiredTiger 内部キャッシュのデータには、ディスク上の形式とは異なる表現が使用されます。

• ファイルシステムキャッシュ内のデータは、データファイルを圧縮する利点も含め、ディスク上のフォーマットと同じです。ファイルシステム キャッシュは、ディスク I/O を削減するためにオペレーティング システムによって使用されます。

• WiredTiger 内部キャッシュに読み込まれたインデックスのデータ表現は、ディスク上の形式とは異なりますが、インデックスの接頭辞圧縮を利用して RAM の使用量を減らすことができます。インデックスの接頭辞圧縮は、インデックスのあるフィールドから一般的な接頭辞の重複を排除します。

• WiredTiger 内部キャッシュ内のコレクション データは非圧縮で、ディスク上の形式とは異なる表現を使用します。ブロック圧縮によりディスク上のストレージを大幅に節約できますが、サーバーで操作するにはデータを解凍する必要があります。

ファイルシステム キャッシュを使用すると、MongoDB は WiredTiger キャッシュや他のプロセスによって使用されていないすべての空きメモリを自動的に使用します。

WiredTiger 内部キャッシュのサイズを調整するには、 storage.wiredTiger.engineConfig.cacheSizeGBと--wiredTigerCacheSizeGBを参照してください。WiredTiger の内部キャッシュ サイズをデフォルト値より大きくしないようにしてください。

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

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

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

MongoDB で接続 1 件ごとに割り当てられるメモリ

各接続は最大 1 MB の RAM を使用します。

接続に使用するメモリを最適化するには、以下を確認します。

• 配置のオープン接続の数をモニタリングします。オープンな接続が多すぎると、RAM が過剰に使用され、ワーキング セットに使用できるメモリが減ります。

• 不要になった接続プールを閉じます。接続プールはとはオープンですぐに使えるデータベース接続のキャッシュであり、ドライバーによって維持されます。不要なプールを閉じると、使用できるメモリ リソースが増えます。

• 接続プールのサイズを管理します。接続文字列オプション maxPoolSize は、プール内でオープンになる接続の最大数を指定します。デフォルトでは、プール内に最大 100 個の接続をオープンできます。maxPoolSize の値を下げると、接続に使用される RAM の上限が減ります。

  Tip

  接続プールを設定するには、「接続プールの構成設定」を参照してください。

WiredTiger からのディスクへの書込みの頻度

チェックポイント

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 ごとに新しいジャーナル ファイルが作成されます。

WiredTiger でディスク領域を再利用するには

WiredTiger のストレージ エンジンは、ドキュメントを削除する際にデータファイル内の空のレコードのリストを保持します。このスペースは WiredTiger によって再利用される場合があります。ただし、非常に特殊な状況でない限り、オペレーティング システムに返されることはありません。

WiredTiger で再利用できる空き領域の量は、見出しwiredTiger.block-manager.file bytes available for reuseの下のdb.collection.stats()の出力に反映されます。

WiredTiger のストレージ エンジンからこの空きスペースをオペレーティング システムに解放するには、データファイルのフラグメント化を解除します。これはレプリカセットのノードを再同期するか、 compactコマンドを使用して実行できます。

コレクションのサイズを確認するには

データ サイズを含むコレクションの統計情報を表示するには、mongosh 内から db.collection.stats() メソッドを使用します。次の例では orders コレクションの db.collection.stats() が発行されます。

db.orders.stats();

MongoDB には、コレクションの具体的なサイズを返すための次のメソッドも用意されています。

• db.collection.dataSize() コレクションの非圧縮データサイズをバイト数で返します。

• db.collection.storageSize() では、ディスク ストレージ上のコレクションのサイズがバイト単位で返されます。コレクション データが圧縮されている場合 ( default for WiredTiger )、ストレージ サイズは圧縮されたサイズを反映し、 db.collection.dataSize()によって返される値よりも小さくなる可能性があります。

• db.collection.totalIndexSize()コレクションのインデックス サイズをバイト単位で返します。インデックスが接頭辞圧縮 (default for WiredTiger) を使用している場合、返されるサイズは圧縮されたサイズを反映します。

次のスクリプトは、各データベースの統計値を出力します。

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

次のスクリプトは、各データベース内の各コレクションの統計値を出力します。

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

コレクションの各インデックスのサイズを確認するには

各インデックスに割り当てられたデータのサイズを表示するには、 db.collection.stats() メソッドを使用し、返されたドキュメントの indexSizes フィールドを確認します。

インデックスが接頭辞圧縮 (default for WiredTiger) を使用している場合、そのインデックスについて返されるサイズは圧縮された場合のサイズになります。

データベースのストレージ使用状況に関する情報を取得するに

mongosh 内の db.stats() メソッドで、「アクティブ」データベースの現在の状態が返されます。返されるフィールドの説明については、 dbStats 出力を参照してください。