MongoDB の制限としきい値

MongoDB Atlas の制限

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

BSON ドキュメント

BSON ドキュメントのサイズ

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

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

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

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

命名制限

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

データベース名は大文字と小文字を区別しません。そのため、salesDataとSalesDataのような名前のデータベースを 2 つ使用することはできません。

MongoDB でデータベースを作成したら、そのデータベースを参照する際に一貫した大文字小文字の使用が必要です。例として、salesData データベースを作成する場合は、salesdata や SalesDataのように大文字と小文字を入れ替えたものを使用しないよう注意してください。

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

Windows で実行中の MongoDB の配置について、データベース名に次の文字は使えません。

/\. "$*<>:|?

また、データベース名に「null」の文字を含めることはできません。

Unix および Linux システムにおけるデータベース名の制限

Unix および Linux システムで実行中の MongoDB 配置の場合、データベース名に次の文字は使えません。

/\. "$

また、データベース名に「null」の文字を含めることはできません。

データベース名の長さ

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

コレクション名の制限

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

• $を含む。

• 空の文字列である（例:""）。

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

• system.で始まる。（内部で使用するため利用できません。）

• .system.が含まれる。

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

名前空間の長さ：

featureCompatibilityVersionが"4.4"以上に設定されている場合、MongoDB はコレクションまたはビューの名前空間の制限を255バイトに引き上げます。 コレクションまたはビューの名前空間には、データベース名、ドット（ . ）セパレーター、コレクションまたはビューの名前（例: <database>.<collection> ）、

フィールド名に関する制限

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

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

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

_idの制限

The field name _id is reserved for use as a primary key; its value must be unique in the collection, is immutable, and may be of any type other than an array or regex. _idにサブフィールドが含まれている場合、サブフィールド名は（ $ ）記号で始めることができません。

命名に関する警告

名前空間

名前空間の長さ

featureCompatibilityVersionが"4.4"以上に設定されている場合、MongoDB はコレクションまたはビューの名前空間の制限を255バイトに引き上げます。 コレクションまたはビューの名前空間には、データベース名、ドット（ . ）セパレーター、コレクションまたはビューの名前（例: <database>.<collection> ）、

Tip

命名制限

Indexes

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

1 つのコレクションで保有できるインデックスは 64 個までです。

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

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

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

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

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

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

Tip

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

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

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

Multikey Index

マルチキー インデックスは、配列フィールドに対する カバー クエリは実行できません。

地理空間インデックス

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

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

createIndexesは、コレクションに 1 つ以上のインデックスの構築をサポートしています。 createIndexesはメモリとディスク上の一時ファイルの組み合わせを使用してインデックス構築を完了します。 createIndexesのメモリ使用量のデフォルト制限は200メガバイトで、単一のcreateIndexesコマンドを使用してビルドされたすべてのインデックスに共有されます。 メモリ制限に達すると、 createIndexesは--dbpathディレクトリ内の_tmpという名前のサブディレクトリにある一時ディスク ファイルを使用してビルドを完了します。

maxIndexBuildMemoryUsageMegabytesサーバー パラメータを設定することで、メモリ制限を上書きできます。メモリ制限を高く設定すると、より早くインデックス構築を完了できる可能性があります。ただし、システム上の未使用 RAM に対してこの制限を高く設定しすぎると、メモリが不足し、サーバーがシャットダウンする可能性があります。

• 機能の互換性バージョン (fcv) "4.2" 以降では、インデックス構築でのメモリ制限がすべてのインデックス構築に適用されます。

インデックスのビルドは、インデックスの作成などのユーザー コマンドまたは最初の同期などの管理プロセスによって開始される場合があります。 どちらもmaxIndexBuildMemoryUsageMegabytesが設定した制限の対象となります。

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

Tip

レプリカセットおよびレプリカセット シャードを含むシャーディングされたクラスターへのインデックス構築の影響を最小限に抑えるには、「レプリカセットでのローリング インデックス構築」で説明されているローリング インデックス構築手順を使用してください。

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

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

• text indexes,

• 2dインデックス、

• geoHaystack indexes.

Tip

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

Hidden Indexes

• _id インデックスは非表示にできません。

• 非表示のインデックスではhint()を使用できません。

ソート

ソートキーの最大数

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

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

データ

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

maxパラメータを使用してcreateに上限付きコレクションの最大ドキュメント数を指定する場合、その制限は2 ³²ドキュメント未満である必要があります。 Capped コレクションの作成時にドキュメントの最大数を指定しない場合、ドキュメント数の制限はありません。

レプリカセット

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

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

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

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

自動作成 oplog の最大サイズ

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

[4]	oplog は、majority commit point が削除されるのを回避するために、設定されたサイズ制限を超えて大きくなることがあります。

シャーディングされたクラスター

シャーディングされたクラスターには、ここで説明する制限としきい値があります。

操作

ソート操作

MongoDB は、1 つまたは複数のインデックスを使用してソート順序を取得できない場合、データに対してブロッキングソート操作を実行する必要があります。この名前は、SORT ステージが出力ドキュメントを返す前にすべての入力ドキュメントを読み取り、その特定のクエリのデータフローをブロックするという要件に由来しています。

MongoDB でのブロッキング ソート操作に 100 メガバイトを超えるシステム メモリが必要な場合、クエリが cursor.allowDiskUse() を指定していない限り、MongoDB はエラーを返します。allowDiskUse() を指定することで、MongoDB は 100 メガバイトのシステムメモリ制限を超えるデータをディスク上の一時ファイルに保存し、ブロッキングソート操作を処理することができます。

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

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

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

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

集計パイプライン メモリ

パイプラインの各ステージには 100 MB の RAM 制限があります。 デフォルトでは、 ステージがこの制限を超えると、MongoDB はエラーを発生させます。 一部のパイプライン ステージでは、 allowDiskUseオプションを使用して一時ファイルにデータを書込む集計パイプライン ステージを有効にすることで、パイプライン処理がより多くのスペースを消費するようにできます。

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

allowDiskUseがtrueの場合にディスクに書き出すことができるステージの例は次のとおりです。

• $bucket

• $bucketAuto

• $group

• $sort ソート操作がインデックスでサポートされていない場合

• $sortByCount

注意

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

一部のステージでは、受信したドキュメントをすべて処理するまでドキュメントを出力できません。これらのパイプライン ステージは、すべての受信ドキュメントが処理されるまで、ステージ出力を 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

次を参照してください。

• $or

• 2d インデックスの内部構造

地理空間クエリ

球面クエリの場合は、 2dsphereインデックス結果を使用します。

球面クエリに2dインデックスを使用すると、北極と南極が入っている球面クエリに2dインデックスを使用するなど、誤った結果が生じる可能性があります。

地理空間座標

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

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

GeoJSON ポリゴンの面積

$geoIntersectsまたは$geoWithinの場合、単一の半球よりも大きい面積を持つ単一リングの多角形を指定する場合は、 the custom MongoDB coordinate reference system in the $geometry式が含まれます。それ以外の場合、補完ジオメトリに対して$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 などおよびその補助ツール。

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

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

100,000 書き込み (write) は、サーバーへの単一のリクエストで定義される、単一のバッチ 操作内で許可されます。

mongosh の Bulk() 操作と、ドライバーの同等のメソッドには、この制限はありません。

ビュー

ビュー定義pipelineには$outまたは$mergeステージを含めることはできません。 ビュー定義にネストされたパイプラインが含まれている場合（たとえば、ビュー定義に$lookupまたは$facetステージが含まれている場合）、この制限はネストされたパイプラインにも適用されます。

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

• ビューは読み取り専用です。

• ビューの名前を変更することはできません。

• ビューに対するfind()操作は次のプロジェクション演算子をサポートしていません。

  • $

  • $elemMatch

  • $slice

  • $meta

• ビューは$textをサポートしていません。

• ビューでは map-reduce 操作をサポートしていません。

プロジェクションの制限

$-プレフィックスが付いたフィールドパス制限

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 ユーザー）でクライアント セッションと因果整合性の保証を使用するには、ユーザー名を 10k バイトより大きくすることはできません。

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

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

db.collection.find()を発行するアプリケーションを考えてみましょう。サーバーは、find() の cursor.batchSize() で定義されたドキュメントのバッチとともにカーソルを返します。セッションは、アプリケーションがサーバーに新しいドキュメントのバッチを要求するたびに更新されます。ただし、現在のドキュメントのバッチ処理に 30 分以上かかる場合、そのセッションは期限切れとしてマークされ、終了します。アプリケーションが次のドキュメントのバッチを要求すると、セッションの終了時にカーソルが強制終了されるため、サーバーはエラーを返します。

カーソルを返す操作の場合、カーソルが 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
}

この操作例では、db.collection.find()メソッドは明示的なセッションに関連付けられています。カーソルには noCursorTimeout() が構成されており、アイドル状態のときにサーバーがカーソルを閉じないようにしています。while ループには、refreshSessions を使用して 5 分ごとにセッションを更新するブロックが含まれています。セッションが 30 分のアイドル タイムアウトを超えることはないため、カーソルは開いたままになります。

MongoDB ドライバーの場合、セッションを作成するための手順と構文については、ドライバーのドキュメントを参照してください。