Docs Menu
Docs Home
/
MongoDBマニュアル
/
はじめに
Docs Home
/
MongoDBマニュアル
/
はじめに
Docs Home
/
MongoDBマニュアル
/
はじめに

ドキュメント

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

MongoDB ドキュメントです。

互換性

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 ドキュメントを挿入すると、挿入前にドライバーが勝手に重複値を削除したり、重複フィールドを含む無効なドキュメントが挿入されたりする可能性があります。このようなドキュメントに対してクエリを実行すると、無作為で一貫性のない結果になります。

ドット表記

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 ドライバーが _id フィールドの ObjectId を自動的に生成します。

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

_id フィールドの動作と制約は次のとおりです。

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

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

  • _idにサブフィールドが含まれている場合、サブフィールド名は（ $ ）記号で始めることができません。

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

    警告

    レプリケーションが正常に機能するように、_id フィールドに BSON 正規表現型の値は保存しないでください。

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

  • ObjectId を使用します。

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

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

  • アプリケーション コードで UUID を生成します。コレクションと _id インデックス内の UUID 値をより効率的に保存するには、BSON BinData 型の値として 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 の同等のスキーマで参照

  • アプリケーション モダナイゼーション スコアカード

戻る

時系列データ上でのマテリアライズドビューの構築

次へ

クエリ API

項目一覧