Docs Menu
Docs Home
/
開発
Docs Home
/
開発
Docs Home
/
開発

ドキュメント

MongoDB はBSONドキュメントとしてデータ レコードを保存します。 BSON は、追加のデータ型を持つ JSONドキュメントのバイナリ表現です。 BSON仕様については、 bsonspec.org を参照してください。 「 BSON Types 」も参照してください。

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 : Long(1250000)
            }

上記のフィールドには、次のデータ型があります。

  • _id 。ObjectId を保持します。

  • name 。first と last フィールドを含む埋め込みドキュメントを保持します。

  • birth と death。Date 型の値を保持します。

  • contribs 文字列の配列を保持します。

  • views 。NumberLong 型の値を保持します。

フィールド名

フィールド名は、特定の制限と要件を持つ string です。

一般的な制限

フィールド名に関する一般的な制限は次のとおりです。

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

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

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

一意性要件

フィールド名は、次の一意性条件を満たす必要があります。

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

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

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

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

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

注意

フィールドに固有の制限については、「_id _idフィールド 」を参照してください。

ドット表記

MongoDB は、ドット表記を使用して配列要素と埋め込みドキュメントフィールドにアクセスします。

配列

ゼロベースのインデックス位置で配列要素を指定したりアクセスしたりするには、ドット表記を使用して配列名とゼロベースのインデックス位置を連結し、結果を引用符で囲みます。

"<array>.<index>"

たとえば、ドキュメントに次のフィールドがあるとします。

{
   ...
   contribs: [ "Turing machine", "Turing test", "Turingery" ],
   ...
}

contribs 配列の 3 つ目の要素を指定するには、"contribs.2" を使用します。

配列のクエリの例については、次のトピックを参照してください。

Tip

  • $[] 更新操作用のすべての位置演算子

  • $[<identifier>] 更新操作のためのフィルタリングされた位置指定演算子

  • $ 位置演算子（操作を更新する場合）

  • $ プロジェクション演算子（配列インデックスが不明な場合）

  • 配列のクエリ（配列を使ったドット表記の例）

埋め込みドキュメント

埋め込みドキュメントのフィールドを指定またはアクセスするには、ドット表記を使用して埋め込みドキュメント名とフィールド名を連結し、結果を引用符で囲みます。

"<embeddedDocument>.<field>"

たとえば、ドキュメントに次のフィールドがあるとします。

{
   ...
   name: { first: "Alan", last: "Turing" },
   contact: { phone: { type: "cell", number: "111-222-3333" } },
   ...
}

  • で lastnameフィールドを指定するには、次の を使用します。"name.last"

  • ネストされた phoneドキュメントで numberフィールドを指定するには、 "contact.phone.number" を使用します。

警告

パーティション フィールドでは、ドット（.）を含むフィールド名は使用できません。

埋め込みドキュメントをクエリする例については、以下を参照してください。

ドキュメントの制限

MongoDBドキュメントには、ドキュメントサイズやフィールド順序など、クエリ動作やアプリケーションのパフォーマンスに影響を与える可能性のある特定の属性があります。

ドキュメント サイズの制限

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

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

ドキュメント フィールドの順序

BSONドキュメントのフィールドは順序付けられています（ JavaScriptオブジェクトとは異なります）。

クエリ内のフィールドの順序

クエリの場合、フィールドの順序に関する動作は次のようになります。

  • フィールドの順序は、ドキュメントを比較する際に重要です。 （例: ）。

    • {a: 1, b: 1} は次と等しい: {a: 1, b: 1}

    • {a: 1, b: 1} は次と等しくない: {b: 1, a: 1}

  • クエリエンジンは、効率的な実行のためにフィールドの順序を再配置する場合があります。フィールド順序は、中間的なクエリ結果と最終的なクエリ結果で発生する可能性があり、次のプロジェクション演算子で発生する可能性があります。

重要

一部の操作ではフィールドの順序が再配置される場合があるため、上記のプロジェクション演算子を使用したクエリの結果のフィールド順序に依存しないでください。

書き込み操作におけるフィールド順序

MongoDB は次のケースを除き、書込み操作でドキュメントのフィールド順序を維持します。

  • _id フィールドは常にドキュメントの最初のフィールドとなります。

  • 更新にフィールド名 renaming が含まれる場合、ドキュメント内のフィールド順序が変更されることがあります。

_idフィールド

MongoDBでは、標準コレクション内に保存される各ドキュメントには プライマリキーとして機能する一意の _idフィールドが必要です。_id挿入されたドキュメントで フィールドが省略されている場合、 MongoDBドライバーは _idフィールドの ObjectId を自動的に生成します。

上記は、アップサート: true に設定した更新操作を通じて挿入されるドキュメントにも適用されます。

注意

時系列コレクション では、 MongoDB は フィールドにインデックスを作成しないため、ドキュメントには一意の _idフィールドは必要ありません。_id

行動と制約：

一般的な _id 値のオプション:

以下は、_idフィールドの値を保存するための一般的なオプションです。

  • ObjectId を使用します。

  • 自然な一意識別子がある場合は、それを使用します。スペースが節約され、追加のインデックスが不要になります。

  • 自動インクリメント番号を生成します。

  • コレクションと _idインデックス内の効率的な UUIDストレージのために UUID をBSON BinData タイプとして生成します。

    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>, ...  }

戻る

Overview

次へ

データベースとコレクション

項目一覧