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() メソッドまたは ドライバーの同様のメソッドを使用します。

名前空間の長さ：

名前空間の長さは、シャーディングされていないコレクションとビューでは、255 バイト、シャーディングされたコレクションでは 235 バイトを上限とします。コレクションまたはビューの名前空間には、データベース名、ドット（.）セパレーター、コレクションまたはビューの名前（例: <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にサブフィールドが含まれている場合、サブフィールド名は（ $ ）記号で始めることができません。

命名に関する警告

名前空間

名前空間の長さ

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

Tip

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

命名制限

Indexes

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

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

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

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

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

特殊な テキスト インデックス を必要とする$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メガバイトで、単一のcreateIndexesコマンドを使用してビルドされたすべてのインデックスに共有されます。 メモリ制限に達すると、 createIndexesは--dbpathディレクトリ内の_tmpという名前のサブディレクトリにある一時ディスク ファイルを使用してビルドを完了します。

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

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

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

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

Tip

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

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

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

• Text indexes

• 2d indexes

Tip

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

Hidden Indexes

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

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

ソート

ソートキーの最大数

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

データ

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

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

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

レプリカセット

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

レプリカセットには最大 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 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 の場合に一時ファイルをディスクに書き込むことができるステージの例は次のとおりです。

• $bucket

• $bucketAuto

• $group

• $setWindowFields

• $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 インデックスの内部構造

地理空間クエリ

球状データのクエリに 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 を呼び出せません。

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