ドキュメント
MongoDB はデータ レコードを BSON ドキュメントとして保存します。BSON は JSON ドキュメントのバイナリ表現ですが、JSON よりも多くのデータ型を含みます。BSON 仕様については、bsonspec.org を参照してください。「BSON Types」も参照してください。
互換性
MongoDB は、次の環境でホストされる配置のレコードをドキュメントとして保存します。
MongoDB Atlas はクラウドでの MongoDB 配置のためのフルマネージド サービスです
MongoDB Enterprise: サブスクリプションベースの自己管理型 MongoDB バージョン
MongoDB Community: ソースが利用可能で、無料で使用できる自己管理型の MongoDB のバージョン
ドキュメント構造
MongoDB ドキュメントはフィールドと値のペアで構成され、次の構造をしています。
{ field1: value1, field2: value2, field3: value3, ... fieldN: valueN }
フィールドの値は、他のドキュメント、配列、ドキュメントの配列など、任意の BSON データ型にすることができます。たとえば、次のドキュメントには多彩なタイプの値が含まれています。
var mydoc = { _id: ObjectId("5099803df3f4948bd2f98391"), name: { first: "Alan", last: "Turing" }, birth: new Date('Jun 23, 1912'), death: new Date('Jun 07, 1954'), contribs: [ "Turing machine", "Turing test", "Turingery" ], views : NumberLong(1250000) }
上記のフィールドには、次のデータ型があります。
_id
。ObjectId を保持します。name
。first
とlast
フィールドを含む埋め込みドキュメントを保持します。birth
とdeath
。Date 型の値を保持します。contribs
文字列の配列を保持します。views
。NumberLong 型の値を保持します。
フィールド名
フィールド名は文字列です。
ドキュメントにはフィールド名に関して次の制限があります。
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
にサブフィールドが含まれている場合、サブフィールド名は($
)記号で始めることができません。
フィールド名に
null
文字を含めることはできません。サーバーでは、ドット(
.
)とドル記号($
)を含むフィールド名を保存できます。MongodB 5.0 では、フィールド名における(
$
)および(.
)の使用に対するサポートが強化されました。制限事項がいくつかあります。詳細については、フィールド名の考慮事項を参照してください。
MongoDBクエリ言語はフィールド名が重複するドキュメントをサポートしていません。
BSONビルダによっては、重複するフィールド名を持つBSONドキュメントの作成をサポートしている場合がありますが、これらのドキュメントをMongoDBに挿入した場合、挿入が 成功したように見えても サポートされていません。
例、 MongoDBドライバーを使用して重複しているフィールド名を持つBSONドキュメントを挿入すると、挿入前にドライバーが勝手に重複値を削除したり、重複フィールドを含む無効なドキュメントが挿入されたりする可能性があります。これらのドキュメントをクエリすると、結果が不整合になります。
アップデートが 成功したように見えても 、重複するフィールド名を持つドキュメントのアップデートはサポートされていません。
MongoDB6.1 validate
full
true
以降、ドキュメントに重複するフィールド名があるかどうかを確認するには、 フィールドを$objectToArray
に設定して コマンドを使用します。いずれのMongoDBバージョンでも、ドキュメントに重複するフィールド名があるかどうかを確認するには、 集計演算子を使用します。
ドット表記
MongoDB は、ドット表記を使用して配列の要素と埋め込みドキュメントのフィールドにアクセスします。
配列
ゼロベースのインデックス位置で配列要素を指定したりアクセスしたりするには、配列名をドット(.
)とゼロベースのインデックス位置と連結し、引用符で囲みます。
"<array>.<index>"
たとえば、ドキュメントに次のフィールドがあるとします。
{ ... contribs: [ "Turing machine", "Turing test", "Turingery" ], ... }
contribs
配列の 3 つ目の要素を指定するには、ドット表記「"contribs.2"
」を使用します。
配列のクエリの例については、次のトピックを参照してください。
Tip
以下も参照してください。
$[]
更新操作用のすべての位置演算子$[<identifier>]
更新操作のためのフィルタリングされた位置指定演算子$
位置演算子(操作を更新する場合)$
プロジェクション演算子(配列インデックスが不明な場合)配列のクエリ(配列を使ったドット表記の例)
埋め込みドキュメント
ドット表記で埋め込みドキュメントのフィールドを指定またはアクセスするには、埋め込みドキュメント名をドット(.
)とフィールド名と連結し、引用符で囲みます。
"<embedded document>.<field>"
たとえば、ドキュメントに次のフィールドがあるとします。
{ ... name: { first: "Alan", last: "Turing" }, contact: { phone: { type: "cell", number: "111-222-3333" } }, ... }
name
フィールドにlast
という名前のフィールドを指定するには、ドット表記"name.last"
を使用します。phone
ドキュメントのnumber
をcontact
フィールドに指定するには、ドット表記"contact.phone.number"
を使用します。
警告
パーティション フィールドでは、ドット(.
)を含むフィールド名は使用できません。
埋め込みドキュメントをクエリする例については、以下を参照してください。
ドキュメントの制限
ドキュメントには次の属性があります。
ドキュメント サイズの制限
BSON ドキュメントの最大サイズは 16 MB です。
ドキュメントの最大サイズを設定すると、単一ドキュメントが過大な量の RAM を使用したり、送信中に過大な量の帯域幅を使用したりする問題が軽減します。MongoDB では、最大サイズを超えるドキュメントは、GridFS API を使用して保存できます。GridFS の詳細については、「mongofiles
」および使用しているドライバーのドキュメントを参照してください。
ドキュメント フィールドの順序
JavaScript オブジェクトと違い、BSON ドキュメント内のフィールドには順序が指定されています。
クエリ内のフィールドの順序
クエリの場合、フィールドの順序に関する動作は次のようになります。
ドキュメントを比較する場合、フィールドの順序は重要です。たとえば、クエリ内でフィールド
a
のあるドキュメントとフィールドb
のあるドキュメントを比較する場合、次のようになります。{a: 1, b: 1}
は次と等しい:{a: 1, b: 1}
{a: 1, b: 1}
は次と等しくない:{b: 1, a: 1}
クエリエンジンはクエリを効率的に実行するために、クエリ処理中にフィールドの順序を再配置する場合があります。フィールド順序が変わる別のケースとして、次のプロジェクション演算子を処理する場合が挙げられます。
$project
、$addFields
、$set
、$unset
。フィールド順序は、クエリによって返される中間的な結果と最終的な結果の両方で変更される可能性があります。
一部の操作ではフィールドの順序が再配置される場合があるため、以前にリストされたプロジェクション演算子を使用したクエリで返される結果のフィールド順序に依存しないでください。
書き込み操作におけるフィールド順序
MongoDB は次のケースを除き、書込み操作でドキュメントのフィールド順序を維持します。
_id
フィールドは常にドキュメントの最初のフィールドとなります。更新にフィールド名
renaming
が含まれる場合、ドキュメント内のフィールド順序が変更されることがあります。
_id
フィールド
MongoDBでは、標準コレクション内に保存される各ドキュメントにはプライマリキーとして機能する一意の _idフィールドが必要です。挿入されたドキュメントで _id
フィールドが省略されている場合、 MongoDBドライバーは フィールドの ObjectId _id
を自動的に生成します。
上記は、アップサート: true に設定した更新操作を通じて挿入されるドキュメントにも適用されます。
注意
時系列コレクション では、 MongoDBは フィールドにインデックスを作成しないため、ドキュメントには一意の _idフィールドは必要ありません。_id
_id
フィールドの動作と制約は次のとおりです。
デフォルトでは、MongoDB はコレクションの作成時に
_id
フィールドにユニークインデックスを作成します。_id
フィールドは常にドキュメントの最初のフィールドとなります。サーバーは、_id
フィールドが先頭にないドキュメントを受信した場合、そのフィールドを先頭に移動します。_id
にサブフィールドが含まれている場合、サブフィールド名は($
)記号で始めることができません。_id
フィールドには、配列、正規表現、または未定義のデータ型以外に、任意の BSON データ型の値を含めることができます。警告
レプリケーションが正常に機能するように、
_id
フィールドに BSON 正規表現型の値は保存しないでください。
以下は、_id
の値を保存するための一般的なオプションです。
ObjectId を使用します。
自然な一意識別子がある場合は、それを使用すると、スペースが節約され、追加のインデックスが不要になります。
自動インクリメント番号を生成します。
アプリケーション コードで UUID を生成します。コレクションと
_id
インデックス内の UUID 値をより効率的に保存するには、BSONBinData
型の値として UUID を保存します。BinData
型のインデックス キーは、次の場合、より効率的にインデックスに保存されます。バイナリ サブタイプ値が 0〜7 または 128〜135 の範囲にあり、かつ
バイト配列の長さが 0、1、2、3、4、5、6、7、8、10、12、14、16、20、24、または 32 である。
ドライバーの BSON UUID 機能を使用して UUID を生成します。ドライバーを実装する際、UUID の直列化および逆直列化のロジックが異なる場合があり、他のドライバーと完全には互換しない可能性があることに注意してください。UUID の相互運用性に関する詳細については、ドライバーのドキュメントを参照してください。
注意
ほとんどの MongoDB ドライバーは_id
フィールドを含み、MongoDB に挿入操作を送信する前にObjectId
を生成します。 ただし、クライアントが_id
フィールドなしでドキュメントを送信した場合、 mongod
は_id
フィールドを追加し、 ObjectId
を生成します。
ドキュメント構造のその他の用途
MongoDB はデータ レコードの定義に加え、クエリフィルター、更新仕様ドキュメント、インデックス仕様ドキュメントといった項目(これらに限定されません)全体にわたってドキュメント構造を使用します。
クエリフィルター ドキュメント
クエリフィルター ドキュメントは、読み取り、更新、削除操作のために選択するレコードの決定条件を指定します。
<field>:<value>
式を使用して、等価条件とクエリ演算子式を指定できます。
{ <field1>: <value1>, <field2>: { <operator>: <value> }, ... }
例については、以下を参照してください。
仕様ドキュメントの更新
更新仕様ドキュメントは、更新演算子を使用して更新操作中に特定のフィールドで実行するデータ変更を指定します。
{ <operator1>: { <field1>: <value1>, ... }, <operator2>: { <field2>: <value2>, ... }, ... }
使用例については、「仕様の更新」を参照してください。
インデックス仕様ドキュメント
インデックス仕様ドキュメントでは、インデックスを作成するフィールドとインデックスのタイプを定義します。
{ <field1>: <type1>, <field2>: <type2>, ... }
さらに読む
MongoDB document model の詳細については、「MongoDB アプリケーション モダナイゼーション ガイド」をダウンロードしてください。
ダウンロードには、次のリソースが含まれています。
MongoDB を使用したデータ モデリングの方法論に関するプレゼンテーション
RDBMS データモデルから MongoDB に移行するためのベストプラクティスと考慮事項を説明したホワイトペーパー
MongoDB のスキーマを RDBMS の同等のスキーマで参照
アプリケーション モダナイゼーション スコアカード