このドキュメントでは、 MongoDBのハード制限とソフト制限を示します。特に指定されていない限り、制限はMongoDB Atlasとセルフホスト型配置の両方に適用されます。
一般的なMongoDB の制限
コレクションとデータベースのサイズ
MongoDB はコレクションまたはデータベースのサイズにハード制限を課しません。最大サイズは ホストファイルシステム によって異なります。
4ext:16 バイト(TiB)の最大ファイルサイズ
XFS:8 特権バイト(EiB)の最大ファイルサイズ
ファイルシステムまたはハードウェアの制限を超えて増やすには、Atlas 以外の配置で シャーディング を使用します。これらの制限に近い、またはパフォーマンスのボトルネックが発生しているオンプレミス コレクションの場合、 MongoDBシャーディングまたはオートスケーリングをサポートするMongoDB Atlasへの移行が推奨されます。
コレクションをシャーディングとき、 MongoDB はシャードキーに基づいて初期チャンク範囲を決定します。
デフォルトの
chunkSize: 128 MB通常の平均シャードキーサイズ: 16 バイト
BSON ドキュメント
- BSON ドキュメントのサイズ
BSONドキュメントの最大サイズは 16 メガバイトです。
ドキュメントの最大サイズを設定すると、単一ドキュメントが送信中に過大な量のRAMまたは過大な量の帯域幅を使用する問題が軽減します。 MongoDB、最大サイズを超えるドキュメントは、 GridFS APIを使用して保存できます。 GridFSの詳細については、
mongofilesと ドライバー のドキュメントを参照してください。
- BSON ドキュメントのネストの深さ
MongoDB では、BSON ドキュメントで 100 レベル以下のネストがサポートされます。オブジェクトまたは配列ごとにレベルが追加されます。
命名制限
- データベース名での大文字と小文字の使用
データベース名は大文字と小文字を区別しません。データベースを作成 したら、そのデータベースを参照する際に一貫した大文字と小文字を使用します。
例、
salesDataとSalesDataのような名前のデータベースを 2 つ使用することはできません。salesDataデータベースを作成する場合は、salesdataやSalesDataのように大文字と小文字を入れ替えたものを使用しないよう注意してください。
- コレクション名の制限
コレクション名はアンダースコアまたは文字で始める必要があり、次のことはできません。
次を含む:
$空の文字列である(例:
"")「null」の文字が含まれる
system.プレフィックスで始まる(内部で使用するため利用できません)include
.system.
コレクション名にアンダースコアなどの特殊文字が含まれている場合、または数字で始まる場合は、コレクションにアクセスするために、
mongoshのdb.getCollection()メソッドまたは ドライバーの同様のメソッドを使用します。名前空間の長さは、シャーディングされていないコレクションとビューでは、255 バイト、シャーディングされたコレクションでは 235 バイトを上限とします。コレクションまたはビューの名前空間には、データベース名、ドット(
.)セパレーター、コレクションまたはビューの名前(例:<database>.<collection>)が含まれます。
- フィールド名に関する制限
フィールド名に
null文字を含めることはできません。サーバーでは、ドット(
.)とドル記号($)を含むフィールド名を保存できます。MongodB 5.0 では、フィールド名における(
$)および(.)の使用に対するサポートが強化されました。制限事項がいくつかあります。詳細については、フィールド名の考慮事項を参照してください。各フィールド名はドキュメント内で一意である必要があります。 ドキュメントに重複フィールドがある場合、MongoDB CRUD操作が予期しない動作をする可能性があるため、重複フィールドを持つドキュメントを保存しないでください。
命名に関する警告
警告
使用に注意が必要です。このセクションの問題は、データの損失または破損につながる可能性があります。
- MongoDB は重複するフィールド名をサポートしていません。
MongoDB クエリ言語では、フィールド名を作成または更新する際に以下の制限が適用されます。
MongoDB はフィールド名が重複するドキュメントの挿入をサポートしていません。一部の BSON ビルダはこのようなドキュメントの作成をサポートしていますが、挿入が成功した場合や成功したように見える場合でも、MongoDB ではサポートされていません。
アップデートが 成功したように見えても 、重複するフィールド名を持つドキュメントのアップデートはサポートされていません。
例、 MongoDBドライバーを使用して重複しているフィールド名を持つBSONドキュメントを挿入すると、挿入前にドライバーが勝手に重複値を削除したり、重複フィールドを含む無効なドキュメントが挿入されたりする可能性があります。 これらのドキュメントをクエリすると、結果が不整合になります。
MongoDB6.1 以降、ドキュメントに重複するフィールド名があるかどうかを確認するには、
validatefullフィールドを に設定してtrueコマンドを使用します。いずれのMongoDBバージョンでも、ドキュメントに重複するフィールド名があるかどうかを確認するには、$objectToArray集計子を使用します。
- あいまいなフィールド名を回避
埋め込みフィールドのドット表記と同じ名フィールド名は使用しないでください。埋め込みフィールド
{ "a" : { "b": ... } }を持つドキュメントがある場合、そのコレクション内の他のドキュメントはトップレベルフィールド"a.b"を保持してはいけません。埋め込みフィールドと最上位フィールドを同じ方法で参照できる場合、インデックス作成とシャーディング操作は埋め込みフィールドの で行われます。同じ方法で参照埋め込みフィールドがコレクションにある間は、最上位フィールド
"a.b"のインデックスやシャードはできません。例、コレクションに埋め込みフィールド
{ "a" : { "b": ... } }と最上位フィールド"a.b"の両方を持つドキュメントが含まれている場合、インデックス作成とシャーディング操作は埋め込みフィールドの で実行されます。コレクションに埋め込みフィールド{ "a" : { "b": ... } }も含まれている場合、最上位フィールド"a.b"のインデックスまたはシャードは実行できません。
- ドル記号(``$``) とピリオド(``.``) に関するインポートとエクスポートの問題
MongoDB 5.0 以降、ドキュメントフィールド名に接頭辞としてドル記号(
$)を付けたり、ピリオド(.)を含めたりすることができます。ただし、フィールド名にこれらの記号が使用されている場合、状況によってはmongoimportとmongoexportが通常どおりに動作しないことがあります。MongoDB Extended JSON v2では、型ラッパーと、型ラッパーと同じ名前を持つフィールドを区別できません。対応する BSON 表現にドル(
$)で始まるキーが含まれる可能性があるコンテキストでは、拡張 JSON 形式を使用しないでください。DBRef メカニズムは、この一般ルールの例外です。フィールド名にピリオド(
.)が含まれる状態でのmongoimportとmongoexportの使用にも制限があります。CSV ファイルではデータ階層を表すのにピリオド(.)が使用されるため、フィールド名のピリオド(.)はネストのレベルと誤解されます。
- ドル記号(``$``) およびピリオド(``.``) の使用によるデータ損失の可能性
ドル記号(
$)で始まるフィールド名や、ピリオド(.)を含むフィールド名を使用し、MongoDB 5.0 以前のサーバーで未確認の書き込み(書き込み確認(write concern)w=0)と組み合わせて使用すると、頻度は低いもののデータが失われる可能性があります。insert、update、およびfindAndModifyコマンドを実行すると、5.0 互換のドライバーは、ドル記号($)で始まるフィールド名またはピリオド(.)を含むフィールド名を持つドキュメントの使用に対する制限を解除します。これらのフィールド名は、以前のドライバー バージョンではクライアント側のエラーを引き起こしていました。ドライバーが接続されているサーバー バージョンに関係なく、制限は解除されます。5.0 ドライバーが古いサーバーにドキュメントを送信すると、エラーを送信することなくドキュメントは拒否されます。
Indexes
- クエリでは、テキスト インデックスと地理空間インデックスを併せて使用できません
特殊な テキスト インデックス を必要とする
$textクエリと、異なるタイプの特殊なインデックスを必要とするクエリ演算子を組み合わせることはできません。例として、$textクエリと$near演算子を組み合わせることはできません。
- 2dsphere インデックスを持つフィールドにはジオメトリのみを保持できます
2dsphere インデックスを持つフィールドには、座標ペアまたは GeoJSON データの形式でジオメトリ データを格納する必要があります。
2dsphereインデックス付きフィールドにジオメトリデータ以外のデータを含むドキュメントを挿入しようとしたり、インデックス付きフィールドにジオメトリ以外のデータが含まれているコレクションに2dsphereインデックスを構築しようとしたりすると、操作は失敗します。Tip
シャーディング操作制限におけるユニークインデックスの制限。
- 2dsphere インデックス キーの個数制限
2dsphere インデックスのキーを生成するために、
mongodは GeoJSON シェイプを内部表現にマッピングします。結果として得られる内部表現は、値の大きな配列になる可能性があります。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パラメーターを使用してメモリ制限を調整します。このパラメータを増やす必要があるのは、単一の コマンドで多数の同時インデックスビルドを実行する場合や、createIndexes500GBより大きいデータセットをインデックス場合など、まれなケースのみです。各
createIndexesコマンドにはmaxIndexBuildMemoryUsageMegabytesの制限があります。デフォルトのmaxNumActiveUserIndexBuildsである 3 を使用する場合、すべての同時インデックスビルドの合計メモリ使用量は、maxIndexBuildMemoryUsageMegabytesの値の最大 3 倍に達します。maxIndexBuildMemoryUsageMegabytesの制限は、createIndexesなどのユーザー コマンドまたは最初の同期などの管理プロセスによって開始されるすべてのインデックスビルドに適用されます。最初の同期では一度に 1 つのコレクションのみが取り込まれるため、メモリ制限を超えるリスクはありません。ただし、ユーザーが複数のデータベース内の複数のコレクションに対して同時にインデックスビルドを開始することも可能です。
- 照合順序とインデックスの種類
次のインデックス タイプは単純なバイナリ比較のみをサポートしており、照合はサポートしていません。
Tip
単純ではない照合順序を持つコレクションに
textまたは2dインデックスを作成するには、インデックスの作成時、明確に{collation: {locale: "simple"} }を指定する必要があります。
- Hidden Indexes
_idインデックスは非表示にできません。非表示のインデックスでは
hint()を使用できません。
ソート
上限付きコレクション
- 上限付きコレクション内の最大ドキュメント数
createのmaxパラメーターを使用して、上限付きコレクション内のドキュメントの最大数を指定する場合、その値は 2 31ドキュメント未満である必要があります。上限付きコレクションの作成時にドキュメントの最大数を指定しない場合、ドキュメント数の制限はありません。
レプリカセット
- レプリカセットの投票ノード数
レプリカセットには最大 7 つの投票ノードを含めることができます。合計ノード数が 7 を超えるレプリカセットについては、「投票権のないノード」を参照してください。
- 自動作成 oplog の最大サイズ
oplogサイズを明示的に指定しない場合(つまり
oplogSizeMBまたは--oplogSizeを使用する場合)、 MongoDB は ギガバイト以下のoplog50 を作成します。 []1[1] oplog は、 majority commit pointが削除されるのを回避するために、設定されたサイズ制限を超えて大きくなることがあります。
シャーディングされたクラスター
- シャーディングされたクラスターのカバーされたクエリ
mongosで実行すると、インデックスにシャードキーが含まれている場合にのみ、シャーディングされたコレクションのクエリをカバーできます。
- シャーディングされたコレクションにおける単一ドキュメントの変更操作
justOneまたはmulti: falseオプションを指定するシャーディングされたコレクションに対してupdateおよびremove()操作を使用するには以下に従ってください。1つのシャードのみをターゲットにする場合は、クエリ仕様で部分的なシャードキーを使用するか、
クエリ仕様でシャードキーまたは
_idフィールドを指定できます。
- シャーディングされたコレクションにおけるユニークインデックス
MongoDB は、ユニークインデックスにインデックスのプレフィックスとして完全なシャードキーが含まれている場合を除き、シャード間のユニークインデックスをサポートしていません。このような状況では、MongoDB は単一のフィールドではなく、キー全体に対して一意性を強制します。
- 移行する範囲あたりのドキュメントの最大数
デフォルトでは、範囲内のドキュメント数が、構成された範囲サイズを平均ドキュメントサイズで割った結果の 2 倍を超える場合、MongoDB は範囲を移動できません。MongoDB でチャンクのサブ範囲を移動して、サイズをその結果より小さくできる場合、バランサーは範囲を移行することで移動できます。
db.collection.stats()には、コレクション内の平均ドキュメント サイズを表すavgObjSizeのフィールドが含まれます。大きすぎて移行できないチャンクの場合は次のようになります。
バランサー設定の
attemptToBalanceJumboChunksでは、チャンクにjumboというラベルが付いていない限り、バランサーが大きすぎて移動できないチャンクを移行できます。詳細については、「サイズ制限を超えるバランス範囲」を参照してください。moveRangeとmoveChunkコマンドを発行するときに、移動できないほど大きい範囲の移行を可能にするために forceJumbo オプションを指定できます。その範囲にはジャンボというラベルが付いている場合と付いていない場合があります。
シャードキー
- シャードキー インデックスの種類
シャードキー インデックスは、シャードキーの昇順インデックス、シャードキーで始まりシャードキーの昇順を指定する複合インデックス、またはハッシュインデックスにすることができます。
シャードキー インデックスは、以下のようにはできません。
- シャードキー選択
シャードキーを変更するためのオプションは、実行している MongoDB のバージョンによって異なります。
MongoDB 5.0 以降では、ドキュメントのシャードキーを変更することでコレクションの再シャーディングが可能です。
既存のシャードキーにサフィックス フィールドを追加することで、シャードキーを調整できます。
- 単調に増加するシャードキーは挿入スループットを制限する可能性があります
挿入量が多いクラスターでは、単調に増加したり減少したりするシャードキーが挿入スループットに影響を与える可能性があります。シャードキーが
_idフィールドである場合、_idフィールドのデフォルト値は一般に増加する値を持つ ObjectId であることに注意してください。単調に増加するシャードキーを持つドキュメントを挿入する場合、挿入されたすべてのドキュメントは単一のシャード上の同じチャンクに属します。最終的に、システムがすべての書き込み操作を受けるチャンク範囲を分割し、その内容を移行してデータをより均等に分散させます。ただし、クラスターは常に挿入操作を単一のシャードにのみ指示するため、挿入スループットのボトルネックが生じます。
クラスターでの操作が主に読み取り操作と更新である場合、この制限はクラスターに影響しない可能性があります。
この制約を回避するには、ハッシュされたシャードキーを使用するか、単調に増加または減少しないフィールドを選択します。
ハッシュされたシャードキーとハッシュされたインデックスには、昇順の値を持つキーのハッシュが格納されます。
操作
- ソート操作
MongoDB は、 インデックスまたは複数のインデックスを使用してソート順序を取得できない場合、データに対してMongoDB内ソート操作を実行する必要があります。
ソートとインデックスの使用の詳細については、「ソートとインデックスの使用」を参照してください。
- 集計パイプライン ステージ
MongoDBは、単一のパイプラインで許可される集計パイプラインステージの数を 1000 に制限します。
集計パイプラインが解析される前または解析された後に ステージの制限を超えると、エラーが発生します。
- 集計パイプライン メモリ
MongoDB 6.0 以降のバージョンでは、実行に 100 MB を超えるメモリを必要とするパイプライン ステージが、デフォルトで一時ファイルをディスクに書き込むかどうかを
allowDiskUseByDefaultパラメーターが制御します。allowDiskUseByDefaultがtrueに設定されている場合、実行に 100 MB を超えるメモリを必要とするパイプライン ステージは、デフォルトで一時ファイルをディスクに書き込みます。{ allowDiskUse: false }オプションを使用して、特定のfindまたはaggregateコマンドの一時ファイルのディスクへの書き込みを無効にすることができます。allowDiskUseByDefaultがfalseに設定されている場合、実行に 100 MB を超えるメモリを必要とするパイプライン ステージでは、デフォルトでエラーが発生します。{ allowDiskUse: true }オプションを使用して、特定のfindまたはaggregateの一時ファイルのディスクへの書き込みを有効にすることができます。
$search集計ステージは別のプロセスで実行されるため、 RAM の 100 メガバイトに制限されません。allowDiskUse が
trueの場合に一時ファイルをディスクに書き込むことができるステージの例は次のとおりです。$sortソート操作がインデックスでサポートされていない場合
注意
パイプライン ステージはドキュメントのストリームに対して動作し、各パイプライン ステージはドキュメントを取り込んで処理し、その結果となるドキュメントを出力します。
一部のステージでは、受信したドキュメントをすべて処理するまでドキュメントを出力できません。これらのパイプライン ステージは、すべての受信ドキュメントが処理されるまで、ステージ出力を 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インデックスを使用すると、誤った結果やエラーが返されることがあります。たとえば、2dインデックスでは、北極と南極が入っている球面クエリはサポートされていません。
- 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を呼び出せません。
killCursorsコマンドをトランザクションの最初の操作に指定することはできません。さらに、トランザクション内で
killCursorsコマンドを実行すると、サーバーは指定されたカーソルを直ちに停止します。トランザクションがコミットされるのを待ちません。
次の操作はトランザクションでは許可されません。
クロスシャードの書き込みトランザクションで新しいコレクションを作成します。たとえば、あるシャードで既存コレクションに書き込み、別のシャードで暗示的にコレクションを作成する場合、MongoDB では同じトランザクションで両方の操作を実行できません。
コレクションの明示的な作成(
db.createCollection()メソッドやインデックスの明示的な作成(db.collection.createIndexes()およびdb.collection.createIndex()メソッドなど)で、"local"以外の読み取り保証(read concern)レベルを使用する場合listCollectionsコマンドとlistIndexesコマンド、およびそのヘルパー メソッド。その他の CRUD 操作や情報操作以外の操作、例えば
createUser、getParameter、countなどおよびその補助ツール。並列操作。複数の名前空間を同時に更新するには、
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 } この例では、
refreshSessions5分ごとに を使用して、30 分のアイドル タイムアウトを防ぎます。カーソルは無期限に開いたままになります。
Atlas のみの制限
次の制限は、MongoDB Atlas でホストされている配置にのみ適用されます。 これらの制限のいずれかが組織にとって問題となる場合は、 Atlas サポートにお問い合わせください。
クラスターの制限
コンポーネント | Limit |
|---|---|
マルチリージョンクラスター内のシャード | 12 |
単一リージョン クラスターでのシャード | 70 |
マルチリージョン クラスターのクロスリージョン ネットワーク権限 |
|
レプリカセットまたはシャードごとに選挙可能なノード | 7 |
コンフィギュレーションサーバーのクラスター階層(最小値および最大値) |
|
クラスター階層による接続制限
MongoDB Atlas は、クラスター層とクラスに基づいて同時着信接続数を制限します。
接続制限はノードごとに適用
シャーディングされたクラスターの場合、制限は mongos ルーターごとに適用されます(ルーターの数はすべてのシャードにわたるレプリカセットのノードの数と等しくなります)
クラスター階層の接続制限:
注意
MongoDB Atlas では、MongoDB Atlas サービスをサポートするために、各クラスターへの接続が少数確保されます。
マルチクラウド接続の制限
MongoDB Atlas のマルチクラウド配置にプライベート接続で接続する場合、クラウドプロバイダーは接続元と同じノードにのみアクセスできます。このクラウドプロバイダーは、そのリージョンに プライマリノードがない場合があります。このような場合は、接続文字列で セカンダリの読み込み設定 (read preference) ) モードを指定します。
プライベート接続を介して現在のプロバイダーのすべてのノードにアクセスするには、残りのクラウドプロバイダーごとにMongoDB Atlasへの VPN または プライベートエンドポイント を構成します。
コレクションとインデックスの制限
MongoDB Atlasクラスター内のコレクションの数に厳密な制限はありません。ただし、コレクションとインデックスが多い場合はパフォーマンスが低下します。コレクションが大きいほど、影響が大きくなります。
クラスター層ごとに推奨されるコレクションとインデックスの最大合計数。
クラスター階層 | 推奨最大値 |
|---|---|
| 5,000 コレクションとインデックス |
| 10,000 コレクションとインデックス |
| 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 件ごとのネットワーク ピアリング接続の総数 |
|
プロジェクトごとの保留中のネットワーク ピアリング接続数 | 25 |
Amazon Web Services Private Linkのリージョンあたりのアドレス指定可能なターゲット数 | 50 |
Azure PrivateLink のリージョンあたりのアドレス指定可能なターゲット数 | 150 |
MongoDB Atlas が管理するグローバルクラスター プロジェクトあたり固有シャードキー数 | |
| 1 |
500 |
サービス アカウントの制限
コンポーネント | Limit |
|---|---|
組織あたり Atlas サービス アカウント | 200 |
サービス アカウントごとのアクセスリストエントリ | 200 |
2 | |
サービス アカウントごとのアクティブなトークン | 100 |
ラベルの制限
MongoDB Atlas では、次のコンポーネント ラベルで長さが制限され、正規表現要件が適用されます。
コンポーネント | 文字数制限 | 正規表現パターン |
|---|---|---|
クラスター名 | 64[]2 |
|
プロジェクト名 | 64 |
|
組織名 | 64 |
|
API キーの説明 | 250 |
| [2] | ピアリング専用モードが有効になっている場合、クラスター名は最大 23 文字です。 |
| [3] | MongoDB Atlas ではクラスター名の最初の 23 文字が使用されます。これらの文字はクラスターのプロジェクト内で一意である必要があります。23 文字未満のクラスター名の末尾には、ハイフン(-)を使用できません。23 文字を超えるクラスター名では、23 番目の文字にはハイフンを使用できません。 |
| [4] | (1、2) 組織名とプロジェクト名には Unicode 文字または数字、および句読点(-_.(),:&@+' を含めることができます。 |
無料クラスターとフレキシブルなクラスターの制限
MongoDB Atlas の無料クラスターと Flex クラスターには、追加の制限が適用されます。詳しくは、以下を参照してください。
コマンドの制限
一部の MongoDB コマンドは MongoDB Atlas ではサポートされません。また、一部のコマンドは MongoDB Atlas の無料クラスターでのみサポートされます。詳しくは以下を参照してください。