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 型の値を保持します。

フィールド名

フィールド名は特定の制限や要件を持つ文字列です。

一般的な制限

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

  • フィールド名に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" } },
   ...
}

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

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

警告

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

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

ドキュメントの制限

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

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

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

最大ドキュメントサイズは、1つのドキュメントが送信中に過剰な量の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

動作と制約:

  • コレクションを作成する際、MongoDB はデフォルトで_idにユニークインデックスを作成します。

  • _id フィールドは常にドキュメントの最初のフィールドとなります。サーバーは、_idフィールドが最初にないドキュメントを受信した場合、そのフィールドをドキュメントの先頭に移動します 。

  • _id サブフィールド名は（$）記号で始めることはできません。

  • _idフィールドには、配列、正規表現、または未定義を除く任意の BSON データ型を含めることができます。

一般的な_id値オプション：

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

  • ObjectId を使用します。

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

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

  • UUID を生成して BSON BinData 型としてコレクションに効率的にストレージし、_id インデックスを作成します。

    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

次へ

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

項目一覧