Docs Menu
Docs Home
/

MongoDB の制限としきい値

このドキュメントでは、 MongoDBのハード制限とソフト制限を示します。特に指定されていない限り、制限はMongoDB Atlasとセルフホスト型配置の両方に適用されます。

MongoDB はコレクションまたはデータベースのサイズにハード制限を課しません。最大サイズは ホストファイルシステム によって異なります。

  • 4ext:16 バイト(TiB)の最大ファイルサイズ

  • XFS:8 特権バイト(EiB)の最大ファイルサイズ

ファイルシステムまたはハードウェアの制限を超えて増やすには、Atlas 以外の配置で シャーディング を使用します。これらの制限に近い、またはパフォーマンスのボトルネックが発生しているオンプレミス コレクションの場合、 MongoDBシャーディングまたはオートスケーリングをサポートするMongoDB Atlasへの移行が推奨されます。

コレクションをシャーディングとき、 MongoDB はシャードキーに基づいて初期チャンク範囲を決定します。

  • デフォルトの chunkSize: 128 MB

  • 通常の平均シャードキーサイズ: 16 バイト

BSON ドキュメントのサイズ

BSONドキュメントの最大サイズは 16 メガバイトです。

ドキュメントの最大サイズを設定すると、単一ドキュメントが送信中に過大な量のRAMまたは過大な量の帯域幅を使用する問題が軽減します。 MongoDB、最大サイズを超えるドキュメントは、 GridFS APIを使用して保存できます。 GridFSの詳細については、mongofiles ドライバー のドキュメントを参照してください。

BSON ドキュメントのネストの深さ

MongoDB では、BSON ドキュメントで 100 レベル以下のネストがサポートされます。オブジェクトまたは配列ごとにレベルが追加されます。

データベース名での大文字と小文字の使用

データベース名は大文字と小文字を区別しません。データベースを作成 したら、そのデータベースを参照する際に一貫した大文字と小文字を使用します。

例、salesDataSalesData のような名前のデータベースを 2 つ使用することはできません。 salesDataデータベースを作成する場合は、salesdataSalesData のように大文字と小文字を入れ替えたものを使用しないよう注意してください。

Windows のデータベース名に関する制限

Windowsでは、データベース名に次の文字は使えません。

/\. "$*<>:|?
Unix および Linux システムにおけるデータベース名の制限

Unix およびLinuxシステムでは、データベース名に次の文字は使えません。

/\. "$
データベース名の Null 文字

どのプラットフォームでも、データベース名に「null」の文字を含めることはできません。

データベース名の長さ

データベース名は空にできず、 64 バイト未満である必要があります。

コレクション名の制限

コレクション名はアンダースコアまたは文字で始める必要があり、次のことはできません

  • 次を含む: $

  • 空の文字列である(例:""

  • 「null」の文字が含まれる

  • system. プレフィックスで始まる(内部で使用するため利用できません)

  • include .system.

コレクション名にアンダースコアなどの特殊文字が含まれている場合、または数字で始まる場合は、コレクションにアクセスするために、mongoshdb.getCollection() メソッドまたは ドライバーの同様のメソッドを使用します。

名前空間の長さ

名前空間の長さは、シャーディングされていないコレクションとビューでは、255 バイト、シャーディングされたコレクションでは 235 バイトを上限とします。コレクションまたはビューの名前空間には、データベース名、ドット(.)セパレーター、コレクションまたはビューの名前(例: <database>.<collection>)が含まれます。

フィールド名に関する制限
  • フィールド名にnull文字を含めることはできません

  • サーバーでは、ドット(.)とドル記号($)を含むフィールド名を保存できます。

  • MongodB 5.0 では、フィールド名における($ )および(.)の使用に対するサポートが強化されました。制限事項がいくつかあります。詳細については、フィールド名の考慮事項を参照してください。

  • 各フィールド名はドキュメント内で一意である必要があります。 ドキュメントに重複フィールドがある場合、MongoDB CRUD操作が予期しない動作をする可能性があるため、重複フィールドを持つドキュメントを保存しないでください。

_idの制限

フィールド名 _id はプライマリキーとして使用するために確保されています。この値は不変であり、コレクションで一意である必要があり、配列または正規表現以外の任意の型にできます。_id にサブフィールドが含まれている場合、サブフィールド名は($)記号で始めることができません。

警告

使用に注意が必要です。このセクションの問題は、データの損失または破損につながる可能性があります。

MongoDB は重複するフィールド名をサポートしていません。

MongoDB クエリ言語では、フィールド名を作成または更新する際に以下の制限が適用されます。

  • MongoDB はフィールド名が重複するドキュメントの挿入をサポートしていません。一部の BSON ビルダはこのようなドキュメントの作成をサポートしていますが、挿入が成功した場合や成功したように見える場合でも、MongoDB ではサポートされていません。

  • アップデートが 成功したように見えても 、重複するフィールド名を持つドキュメントのアップデートはサポートされていません。

例、 MongoDBドライバーを使用して重複しているフィールド名を持つBSONドキュメントを挿入すると、挿入前にドライバーが勝手に重複値を削除したり、重複フィールドを含む無効なドキュメントが挿入されたりする可能性があります。 これらのドキュメントをクエリすると、結果が不整合になります。

MongoDB6.1 以降、ドキュメントに重複するフィールド名があるかどうかを確認するには、validate fullフィールドを に設定してtrue コマンドを使用します。いずれのMongoDBバージョンでも、ドキュメントに重複するフィールド名があるかどうかを確認するには、$objectToArray 集計子を使用します。

あいまいなフィールド名を回避

埋め込みフィールドのドット表記と同じ名フィールド名は使用しないでください。埋め込みフィールド { "a" : { "b": ... } } を持つドキュメントがある場合、そのコレクション内の他のドキュメントはトップレベルフィールド "a.b" を保持してはいけません

埋め込みフィールドと最上位フィールドを同じ方法で参照できる場合、インデックス作成とシャーディング操作は埋め込みフィールドの で行われます。同じ方法で参照埋め込みフィールドがコレクションにある間は、最上位フィールド"a.b" のインデックスやシャードはできません。

例、コレクションに埋め込みフィールド{ "a" : { "b": ... } } と最上位フィールド"a.b" の両方を持つドキュメントが含まれている場合、インデックス作成とシャーディング操作は埋め込みフィールドの で実行されます。コレクションに埋め込みフィールド{ "a" : { "b": ... } } も含まれている場合、最上位フィールド"a.b" のインデックスまたはシャードは実行できません。

ドル記号(``$``) とピリオド(``.``) に関するインポートとエクスポートの問題

MongoDB 5.0 以降、ドキュメントフィールド名に接頭辞としてドル記号($)を付けたり、ピリオド(.)を含めたりすることができます。ただし、フィールド名にこれらの記号が使用されている場合、状況によっては mongoimportmongoexport が通常どおりに動作しないことがあります。

MongoDB Extended JSON v2では、型ラッパーと、型ラッパーと同じ名前を持つフィールドを区別できません。対応する BSON 表現にドル( $)で始まるキーが含まれる可能性があるコンテキストでは、拡張 JSON 形式を使用しないでください。DBRef メカニズムは、この一般ルールの例外です。

フィールド名にピリオド(.)が含まれる状態での mongoimportmongoexport の使用にも制限があります。CSV ファイルではデータ階層を表すのにピリオド(.)が使用されるため、フィールド名のピリオド(.)はネストのレベルと誤解されます。

ドル記号(``$``) およびピリオド(``.``) の使用によるデータ損失の可能性

ドル記号($)で始まるフィールド名や、ピリオド(.)を含むフィールド名を使用し、MongoDB 5.0 以前のサーバーで未確認の書き込み(書き込み確認(write concern)w=0)と組み合わせて使用すると、頻度は低いもののデータが失われる可能性があります。

insertupdate、およびfindAndModifyコマンドを実行すると、5.0 互換のドライバーは、ドル記号($)で始まるフィールド名またはピリオド( .)を含むフィールド名を持つドキュメントの使用に対する制限を解除します。これらのフィールド名は、以前のドライバー バージョンではクライアント側のエラーを引き起こしていました。

ドライバーが接続されているサーバー バージョンに関係なく、制限は解除されます。5.0 ドライバーが古いサーバーにドキュメントを送信すると、エラーを送信することなくドキュメントは拒否されます。

コレクションあたりのインデックス数

単一コレクションには、64 個以下のインデックスを含めることができます。

複合インデックス内のインデックス付きフィールドの数

複合インデックスには、32 を超えるフィールドを含めることはできません。

クエリでは、テキスト インデックスと地理空間インデックスを併せて使用できません

特殊な テキスト インデックス を必要とする$textクエリと、異なるタイプの特殊なインデックスを必要とするクエリ演算子を組み合わせることはできません。例として、$textクエリと$near演算子を組み合わせることはできません。

2dsphere インデックスを持つフィールドにはジオメトリのみを保持できます

2dsphere インデックスを持つフィールドには、座標ペアまたは GeoJSON データの形式でジオメトリ データを格納する必要があります。2dsphereインデックス付きフィールドにジオメトリデータ以外のデータを含むドキュメントを挿入しようとしたり、インデックス付きフィールドにジオメトリ以外のデータが含まれているコレクションに 2dsphere インデックスを構築しようとしたりすると、操作は失敗します。

Tip

シャーディング操作制限におけるユニークインデックスの制限。

2dsphere インデックス キーの個数制限

2dsphere インデックスのキーを生成するために、mongodGeoJSON シェイプを内部表現にマッピングします。結果として得られる内部表現は、値の大きな配列になる可能性があります。

mongodが配列を保持するフィールドにインデックス キーを生成する場合、mongodは配列要素ごとにインデックス キーを生成します。複合インデックスの場合、mongodは各フィールドに対して生成されたキーセットの直積集合を計算します。両方のセットが大きい場合、直積集合の計算によって操作がメモリ制限を超える可能性があります。

indexMaxNumGeneratedKeysPerDocumentは、メモリ不足エラーを防ぐために、単一のドキュメントに対して生成されるキーの最大数を制限します。デフォルトは 1 ドキュメントあたり 100000 インデックス キーです。制限を引き上げることは可能ですが、indexMaxNumGeneratedKeysPerDocumentパラメーターで指定された数より多くのキーが操作に必要な場合、操作は失敗します。

WiredTiger ストレージエンジンによって対象クエリから返される NaN 値は、常に double 型です

インデックスによってカバーされているクエリから返されるフィールドの値がNaNの場合、そのNaN値の型は常にdoubleになります。

Multikey Index

マルチキー インデックスは、配列フィールドに対するクエリをサポートしていません。

地理空間インデックス

地理空間インデックスは、クエリをカバーできません。

インデックス構築におけるメモリ使用量

createIndexes は、コレクションでの 1 つ以上のインデックスの構築をサポートしています。createIndexes はメモリとディスク上の一時ファイルの組み合わせを使用してインデックスを構築します。デフォルトのメモリ制限は、createIndexes コマンドあたり 200 メガバイトで、そのコマンドでビルドされたすべてのインデックス間で均等に共有されます。例、1 つの createIndexes コマンドで 10 インデックスをビルドする場合、 MongoDB はデフォルトのメモリ制限である 200 を使用して、各インデックス20 メガバイトをインデックス構築プロセスに割り当てます。メモリ制限に達すると、 MongoDB はビルドを完了するために --dbpath 内の _tmp サブディレクトリに一時ファイルを作成します。

maxIndexBuildMemoryUsageMegabytesパラメーターを使用してメモリ制限を調整します。このパラメータを増やす必要があるのは、単一の コマンドで多数の同時インデックスビルドを実行する場合や、createIndexes 500GBより大きいデータセットをインデックス場合など、まれなケースのみです。

createIndexes コマンドには maxIndexBuildMemoryUsageMegabytes の制限があります。デフォルトの maxNumActiveUserIndexBuilds である 3 を使用する場合、すべての同時インデックスビルドの合計メモリ使用量は、maxIndexBuildMemoryUsageMegabytes の値の最大 3 倍に達します。

maxIndexBuildMemoryUsageMegabytes の制限は、createIndexes などのユーザー コマンドまたは最初の同期などの管理プロセスによって開始されるすべてのインデックスビルドに適用されます。

最初の同期では一度に 1 つのコレクションのみが取り込まれるため、メモリ制限を超えるリスクはありません。ただし、ユーザーが複数のデータベース内の複数のコレクションに対して同時にインデックスビルドを開始することも可能です。

照合順序とインデックスの種類

次のインデックス タイプは単純なバイナリ比較のみをサポートしており、照合はサポートしていません。

Tip

単純ではない照合順序を持つコレクションに text または 2d インデックスを作成するには、インデックスの作成時、明確に {collation: {locale: "simple"} } を指定する必要があります。

Hidden Indexes
ソートキーの最大数
  • 最大 32 個のキーでソートすることができます。

  • 重複するフィールドを含むソート パターンを指定すると、エラーが発生します。

上限付きコレクション内の最大ドキュメント数

createmaxパラメーターを使用して、上限付きコレクション内のドキュメントの最大数を指定する場合、その値は 2 31ドキュメント未満である必要があります。

上限付きコレクションの作成時にドキュメントの最大数を指定しない場合、ドキュメント数の制限はありません。

レプリカセットのノード数

レプリカセットには最大 50 ノードを含めることができます。

レプリカセットの投票ノード数

レプリカセットには最大 7 つの投票ノードを含めることができます。合計ノード数が 7 を超えるレプリカセットについては、「投票権のないノード」を参照してください。

自動作成 oplog の最大サイズ

oplogサイズを明示的に指定しない場合(つまりoplogSizeMB または--oplogSize を使用する場合)、 MongoDB は ギガバイト以下のoplog50 を作成します。 []1

[1] oplog は、majority commit point が削除されるのを回避するために、設定されたサイズ制限を超えて大きくなることがあります。
シャーディングされた環境で利用できない操作

$whereは、$where関数からdbオブジェクトへの参照を許可しません。これは、シャーディングされていないコレクションでは珍しいことです。

シャーディングされたクラスターのカバーされたクエリ

mongosで実行すると、インデックスにシャードキーが含まれている場合にのみ、シャーディングされたコレクションのクエリをカバーできます。

シャーディングされたコレクションにおける単一ドキュメントの変更操作

justOneまたはmulti: falseオプションを指定するシャーディングされたコレクションに対してupdateおよびremove()操作を使用するには以下に従ってください。

  • 1つのシャードのみをターゲットにする場合は、クエリ仕様で部分的なシャードキーを使用するか、

  • クエリ仕様でシャードキーまたは _id フィールドを指定できます。

シャーディングされたコレクションにおけるユニークインデックス

MongoDB は、ユニークインデックスにインデックスのプレフィックスとして完全なシャードキーが含まれている場合を除き、シャード間のユニークインデックスをサポートしていません。このような状況では、MongoDB は単一のフィールドではなく、キー全体に対して一意性を強制します。

Tip

次を参照してください。

代替アプローチについては、任意のフィールドに対するユニークな制約を参照してください。

移行する範囲あたりのドキュメントの最大数

デフォルトでは、範囲内のドキュメント数が、構成された範囲サイズを平均ドキュメントサイズで割った結果の 2 倍を超える場合、MongoDB は範囲を移動できません。MongoDB でチャンクのサブ範囲を移動して、サイズをその結果より小さくできる場合、バランサーは範囲を移行することで移動できます。db.collection.stats() には、コレクション内の平均ドキュメント サイズを表す avgObjSize のフィールドが含まれます。

大きすぎて移行できないチャンクの場合は次のようになります。

  • バランサー設定の attemptToBalanceJumboChunks では、チャンクにjumboというラベルが付いていない限り、バランサーが大きすぎて移動できないチャンクを移行できます。詳細については、「サイズ制限を超えるバランス範囲」を参照してください。

    moveRangemoveChunk コマンドを発行するときに、移動できないほど大きい範囲の移行を可能にするために forceJumbo オプションを指定できます。その範囲にはジャンボというラベルが付いている場合と付いていない場合があります。

シャードキー インデックスの種類

シャードキー インデックスは、シャードキーの昇順インデックス、シャードキーで始まりシャードキーの昇順を指定する複合インデックス、またはハッシュインデックスにすることができます。

シャードキー インデックスは、以下のようにはできません。

シャードキー選択

シャードキーを変更するためのオプションは、実行している MongoDB のバージョンによって異なります。

単調に増加するシャードキーは挿入スループットを制限する可能性があります

挿入量が多いクラスターでは、単調に増加したり減少したりするシャードキーが挿入スループットに影響を与える可能性があります。シャードキーが_idフィールドである場合、 _idフィールドのデフォルト値は一般に増加する値を持つ ObjectId であることに注意してください。

単調に増加するシャードキーを持つドキュメントを挿入する場合、挿入されたすべてのドキュメントは単一のシャード上の同じチャンクに属します。最終的に、システムがすべての書き込み操作を受けるチャンク範囲を分割し、その内容を移行してデータをより均等に分散させます。ただし、クラスターは常に挿入操作を単一のシャードにのみ指示するため、挿入スループットのボトルネックが生じます。

クラスターでの操作が主に読み取り操作と更新である場合、この制限はクラスターに影響しない可能性があります。

この制約を回避するには、ハッシュされたシャードキーを使用するか、単調に増加または減少しないフィールドを選択します。

ハッシュされたシャードキーハッシュされたインデックスには、昇順の値を持つキーのハッシュが格納されます。

ソート操作

MongoDB は、 インデックスまたは複数のインデックスを使用してソート順序を取得できない場合、データに対してMongoDB内ソート操作を実行する必要があります。

ソートとインデックスの使用の詳細については、「ソートとインデックスの使用」を参照してください。

集計パイプライン ステージ

MongoDBは、単一のパイプラインで許可される集計パイプラインステージの数を 1000 に制限します。

集計パイプラインが解析される前または解析された後に ステージの制限を超えると、エラーが発生します。

集計パイプライン メモリ

MongoDB 6.0 以降のバージョンでは、実行に 100 MB を超えるメモリを必要とするパイプライン ステージが、デフォルトで一時ファイルをディスクに書き込むかどうかをallowDiskUseByDefaultパラメーターが制御します。

  • allowDiskUseByDefaulttrueに設定されている場合、実行に 100 MB を超えるメモリを必要とするパイプライン ステージは、デフォルトで一時ファイルをディスクに書き込みます。{ allowDiskUse: false }オプションを使用して、特定のfindまたはaggregateコマンドの一時ファイルのディスクへの書き込みを無効にすることができます。

  • allowDiskUseByDefaultfalseに設定されている場合、実行に 100 MB を超えるメモリを必要とするパイプライン ステージでは、デフォルトでエラーが発生します。{ allowDiskUse: true }オプションを使用して、特定のfindまたはaggregateの一時ファイルのディスクへの書き込みを有効にすることができます。

$search 集計ステージは別のプロセスで実行されるため、 RAM の 100 メガバイトに制限されません。

allowDiskUsetrue の場合に一時ファイルをディスクに書き込むことができるステージの例は次のとおりです。

注意

パイプライン ステージはドキュメントのストリームに対して動作し、各パイプライン ステージはドキュメントを取り込んで処理し、その結果となるドキュメントを出力します。

一部のステージでは、受信したドキュメントをすべて処理するまでドキュメントを出力できません。これらのパイプライン ステージは、すべての受信ドキュメントが処理されるまで、ステージ出力を RAM に保持する必要があります。その結果、これらのパイプライン ステージでは 100 MB の制限を超えるスペースが必要になる場合があります。

$sortパイプライン ステージのいずれかの結果が制限を超える場合は、$limit ステージの追加を検討してください。

プロファイラー ログ メッセージ診断ログ メッセージには、メモリ制限のために集計ステージで一時ファイルにデータが書込まれた場合、usedDisk インジケーターが含められます。

集計と読み取り保証
  • $out ステージは読み取り保証 (read concern) "linearizable" と組み合わせて使用することはできません。db.collection.aggregate() に対して "linearizable" 読み取り保証 (read concern) を指定した場合、パイプライン内に $out ステージを含めることはできません。

  • $mergeステージは読み取り保証(read concern)"linearizable"と組み合わせて使用することはできません。つまり、db.collection.aggregate()に対して読み取り保証(read concern)"linearizable"を指定した場合、パイプラインに$mergeステージを含めることはできません。

2d 地理空間クエリでは $or 演算子を使用できません。

Tip

次を参照してください。

地理空間クエリ

球状データのクエリに 2d インデックスを使用すると、誤った結果やエラーが返されることがあります。たとえば、2d インデックスでは、北極と南極が入っている球面クエリはサポートされていません。

地理空間座標
  • 有効な経度の値は、-180 以上、180 以下です。

  • 有効な緯度の値は-90 以上、90 以下です。

GeoJSON ポリゴンの面積

$geoIntersectsまたは$geoWithinの場合、単一の半球よりも大きい面積を持つ単一リングのポリゴンを指定する場合は、$geometry式にカスタム MongoDB 座標参照システムを含めます。それ以外の場合、補完ジオメトリに対して $geoIntersectsまたは$geoWithinクエリを実行します。半球より大きい面積を持つその他すべての GeoJSON ポリゴンの場合、$geoIntersectsまたは$geoWithinで補完ジオメトリを照会します。

マルチ ドキュメント トランザクション

マルチドキュメントトランザクションの場合は次のとおりです。

  • コレクションとインデックスはトランザクション内で作成できます。詳細については、「トランザクション内でのコレクションとインデックスの作成」を参照してください。

  • トランザクションで使用されるコレクションは、異なるデータベースにある可能性があります。

    注意

    クロスシャードの書き込みトランザクションでは新しいコレクションを作成できません。たとえば、あるシャードで既存コレクションに書き込み、別のシャードで暗示的にコレクションを作成する場合、MongoDB では同じトランザクションで両方の操作を実行できません。

  • Capped コレクションには書き込めません。

  • Capped コレクションから読み取る場合、読み取り保証(read concern)"snapshot" は使用できません。(MongoDB 5.0 以降)

  • config データベース、 admin データベース、または local データベース内のコレクションの読み取りと書き込みはできません。

  • system.* コレクションに書き込み (write) はできません。

  • explain または類似コマンドを使用して、サポートされている操作のクエリプランを返すことはできません。

  • トランザクションの外部で作成されたカーソルの場合、トランザクション内で getMore を呼び出せません。

  • トランザクション内で作成されたカーソルの場合、トランザクション外で getMore を呼び出せません。

次の操作はトランザクションでは許可されません。

  • クロスシャードの書き込みトランザクションで新しいコレクションを作成します。たとえば、あるシャードで既存コレクションに書き込み、別のシャードで暗示的にコレクションを作成する場合、MongoDB では同じトランザクションで両方の操作を実行できません。

  • コレクションの明示的な作成db.createCollection()メソッドやインデックスの明示的な作成(db.collection.createIndexes() および db.collection.createIndex() メソッドなど)で、"local" 以外の読み取り保証(read concern)レベルを使用する場合

  • listCollections コマンドと listIndexes コマンド、およびそのヘルパー メソッド。

  • その他の CRUD 操作や情報操作以外の操作、例えば createUsergetParametercount などおよびその補助ツール。

  • 並列操作。複数の名前空間を同時に更新するには、bulkWrite コマンドの使用を検討してください。

トランザクションには、transactionLifetimeLimitSecondsで指定された有効期間の制限があります。デフォルトでは 60 秒です。

書き込み (write) コマンドのバッチ制限サイズ

ドライバーが処理できる書込み操作の量に制限はありません。ドライバーは maxWriteBatchSize 100000に従ってデータをバッチにグループ化します。これは 、100 であり、変更できません。バッチするに,000 を超える操作が含まれている場合、ドライバーはバッチするを maxWriteBatchSize250 以下の小さなグループに分割します。例、操作に,000 操作が含まれている場合、ドライバーは 3 つのバッチを作成します。2100 つは,000 50操作で、1 つは,000 操作です。

ビュー

ビュー定義pipelineには、$outまたは$mergeステージを含めることはできません。この制限は、$lookupステージまたは$facetステージで使用されるパイプラインなどの埋め込みパイプラインにも適用されます。

ビューには、次の操作制限があります。

プロジェクションの制限
``$`` プレフィックスが付いたフィールドパス制限

およびfind() findAndModify()$プロジェクションでは、DBRef フィールドを除き、 で始まるフィールドをプロジェクトできません。

たとえば、次の操作は無効です。

db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )
``$`` 位置演算子の配置制限

$プロジェクション演算子は、フィールドパスの末尾にのみ使用できます(例: "field.$"または"fieldA.fieldB.$"

たとえば、次の操作は無効です。

db.inventory.find( { }, { "instock.$.qty": 1 } )

解決するには、$ プロジェクション演算子の後に続くフィールドパスのコンポーネントを削除してください。

空のフィールド名に対するプロジェクション制限

find()およびfindAndModify() プロジェクションには、空のフィールド名のプロジェクションを含めることはできません。

たとえば、次の操作は無効です。

db.inventory.find( { }, { "": 0 } )

以前のバージョンでは、MongoDB は空のフィールドの包含/除外を、存在しないフィールドのプロジェクションと同様に扱っていました。

パスの不一致:埋め込みドキュメントとそのフィールド

埋め込みドキュメントのフィールドを使用して、埋め込みドキュメントをプロジェクトすることはできません。

たとえば、size フィールドを含むドキュメントを含むコレクション inventory を考えます。

{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }

次の操作は、sizeドキュメントと size.uom フィールドの両方をプロジェクトしようとするためPath collision エラーで失敗します。

db.inventory.find( {}, { size: 1, "size.uom": 1 } )

以前のバージョンでは、埋め込まれたドキュメントとそのフィールドの間で、最後に指定されたプロジェクションが適用されていました。

  • 埋め込みドキュメントのプロジェクションが、そのフィールドの任意のプロジェクションよりも後の場合、MongoDB は埋め込みドキュメントをプロジェクトします。たとえば、プロジェクション ドキュメント { "size.uom": 1, size: 1 } はプロジェクション ドキュメント { size: 1 } と同じ結果を生成します。

  • 埋め込みドキュメントのプロジェクションが、そのフィールドのいずれかのプロジェクションよりも前の場合、MongoDB は指定されたフィールドをプロジェクションします。たとえば、プロジェクション ドキュメント { "size.uom": 1, size: 1, "size.h": 1 } はプロジェクション ドキュメント { "size.uom": 1, "size.h": 1 } と同じ結果を生成します。

パスの不一致:配列と埋め込みフィールドの ``$slice``

find()およびfindAndModify() プロジェクションには、配列の$slice と配列に埋め込まれたフィールドの両方を含めることはできません。

たとえば、配列フィールド instock を含むコレクション inventory を考えます。

{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }

次の操作はPath collisionエラーで失敗します。

db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )

以前のバージョンでは、プロジェクションは両方のプロジェクションを適用し、instock 配列の最初の要素($slice: 1)を返しますが、プロジェクションされた要素の warehouse フィールドは非表示にされていました。MongoDB 4.4 以降で同じ結果を得るには、2 つの個別の $project ステージで db.collection.aggregate() メソッドを使用します。

``$`` 位置演算子と ``$slice`` の制限

find()およびfindAndModify() プロジェクションには、$slice プロジェクション式の一部として$ プロジェクション式を含めることはできません。

たとえば、次の操作は無効です。

db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )

以前のバージョンでは、MongoDB はクエリ条件に一致する instock 配列の最初の要素(instock.$)を返します。つまり、位置プロジェクション"instock.$" が優先され、$slice:1 の処理はありません。"instock.$": { $slice: 1 } は他のドキュメント フィールドを除外しません。

セッションと $external ユーザー名の制限

$external認証ユーザー(Kerberos、LDAP、または X.509 ユーザー)でクライアント セッションと因果整合性の保証を使用するには、ユーザー名を 10 k バイトより大きくすることはできません。

セッション アイドル タイムアウト

30 分間、読み取りまたは書き込み操作が行われなかったセッション、 または refreshSessions を使用して更新されなかったセッションは期限切れとしてマークされ、 MongoDBサーバーは閉じることができます。セッションを閉じると、noCursorTimeout() または 30 分より大きい maxTimeMS() で構成されたものを含む、進行中の操作と開いているカーソルがすべて終了されます。

長時間実行カーソル操作

30分以上アイドル状態になる可能性があるカーソルを返す操作の場合は、 を使用して明示的なセッション内で操作を発行し、 を使用して定期的にセッションを更新します。 (例:Mongo.startSession() refreshSessions)。

var session = db.getMongo().startSession()
var sessionId = session
sessionId // show the sessionId
var cursor = session.getDatabase("examples").getCollection("data").find().noCursorTimeout()
var refreshTimestamp = new Date() // take note of time at operation start
while (cursor.hasNext()) {
// Check if more than 5 minutes have passed since the last refresh
if ( (new Date()-refreshTimestamp)/1000 > 300 ) {
print("refreshing session")
db.adminCommand({"refreshSessions" : [sessionId]})
refreshTimestamp = new Date()
}
// process cursor normally
}

この例では、refreshSessions 5分ごとに を使用して、30 分のアイドル タイムアウトを防ぎます。カーソルは無期限に開いたままになります。

MongoDBドライバーについては、 セッションの作成 に関するドライバーのドキュメントを参照してください。

次の制限は、MongoDB Atlas でホストされている配置にのみ適用されます。 これらの制限のいずれかが組織にとって問題となる場合は、 Atlas サポートにお問い合わせください。

コンポーネント
Limit

12

単一リージョン クラスターでのシャード

70

マルチリージョン クラスターのクロスリージョン ネットワーク権限

  1. また、プロジェクト内のクラスターが 40を超えるリージョンにまたがっている場合は、このプロジェクトでマルチリージョンクラスターを作成することはできません。

レプリカセットまたはシャードごとに選挙可能なノード

7

M30

MongoDB Atlas は、クラスター層とクラスに基づいて同時着信接続数を制限します。

クラスター階層の接続制限:

注意

MongoDB Atlas では、MongoDB Atlas サービスをサポートするために、各クラスターへの接続が少数確保されます。

MongoDB Atlas のマルチクラウド配置にプライベート接続で接続する場合、クラウドプロバイダーは接続元と同じノードにのみアクセスできます。このクラウドプロバイダーは、そのリージョンに プライマリノードがない場合があります。このような場合は、接続文字列で セカンダリの読み込み設定 (read preference) ) モードを指定します。

プライベート接続を介して現在のプロバイダーのすべてのノードにアクセスするには、残りのクラウドプロバイダーごとにMongoDB Atlasへの VPN または プライベートエンドポイント を構成します。

MongoDB Atlasクラスター内のコレクションの数に厳密な制限はありません。ただし、コレクションとインデックスが多い場合はパフォーマンスが低下します。コレクションが大きいほど、影響が大きくなります。

クラスター層ごとに推奨されるコレクションとインデックスの最大合計数。

クラスター階層
推奨最大値

M10

5,000 コレクションとインデックス

M20 / M30

10,000 コレクションとインデックス

M40/+

100,000 コレクションとインデックス

MongoDB Atlas の配置では、組織とプロジェクトに次の制限が適用されます。

コンポーネント
Limit

100

プロジェクトごとの Atlas ユーザー数

500

組織あたり Atlas ユーザー数

500

組織あたりAPIキー数

500

プロジェクトごとの アクセス リスト エントリー

200

チームあたりのユーザー数

250

プロジェクト1 件あたりのチーム数

100

組織あたりチーム数

250

ユーザーあたりのチーム数

100

ユーザーあたりの組織数

250

250

プロジェクトあたりクラスター数

25

組織あたりプロジェクト数

250

100

データベース・ユーザーごとに割り当てられるロール

100

組織あたりの時間単位の課金

$50

25

プロジェクト1 件ごとのネットワーク ピアリング接続の総数

  1. さらに、 MongoDB Atlas は、 CIDR ブロックとプロジェクトに選択されたリージョン に基づいて、 ネットワークピアリング接続 ごとのノード数を制限します。

プロジェクトごとの保留中のネットワーク ピアリング接続数

25

Amazon Web Services Private Linkのリージョンあたりのアドレス指定可能なターゲット数

50

Azure PrivateLink のリージョンあたりのアドレス指定可能なターゲット数

150

MongoDB Atlas が管理するグローバルクラスター プロジェクトあたり固有シャードキー数

  1. これは、Atlas が管理するシャーディングを持つグローバルクラスターにのみ適用されます。自己管理型シャーディングを持つグローバルクラスターのプロジェクトごとの固有のシャードキーの数に制限はありません。

Free プロジェクトあたり クラスター

1

500

コンポーネント
Limit

200

200

サービス アカウントごとのシークレット

2

サービス アカウントごとのアクティブなトークン

100

MongoDB Atlas では、次のコンポーネント ラベルで長さが制限され、正規表現要件が適用されます。

コンポーネント
文字数制限
正規表現パターン

クラスター名

64[]2

^([a-zA-Z0-9]([a-zA-Z0-9-]){0,21}(?<!-)([\w]{0,42}))$ [3]

プロジェクト名

64

^[\p{L}\p{N}\-_.(),:&@+']{1,64}$ [4]

組織名

64

^[\p{L}\p{N}\-_.(),:&@+']{1,64}$ [4]

API キーの説明

250

[2] ピアリング専用モードが有効になっている場合、クラスター名は最大 23 文字です。
[3] MongoDB Atlas ではクラスター名の最初の 23 文字が使用されます。これらの文字はクラスターのプロジェクト内で一意である必要があります。23 文字未満のクラスター名の末尾には、ハイフン(-)を使用できません。23 文字を超えるクラスター名では、23 番目の文字にはハイフンを使用できません。
[4]12 組織名とプロジェクト名には Unicode 文字または数字、および句読点(-_.(),:&@+' を含めることができます。

MongoDB Atlas の無料クラスターと Flex クラスターには、追加の制限が適用されます。詳しくは、以下を参照してください。

一部の MongoDB コマンドは MongoDB Atlas ではサポートされません。また、一部のコマンドは MongoDB Atlas の無料クラスターでのみサポートされます。詳しくは以下を参照してください。

戻る

ログ メッセージ

項目一覧