Docs Menu
Docs Home
/
MongoDB Atlas
/ / /

フィールド マッピングの定義

項目一覧

  • 静的マッピングと動的マッピング
  • 静的マッピング
  • ダイナミックマッピング
  • データ型
  • 制限
  • 複数のデータ型としてのインデックス フィールド
  • 静的マッピングの例
  • 複合マッピングの例

Atlas Search インデックスを作成すると、次のことが可能になります。

  • 静的マッピングを使用してインデックスを作成するフィールドを指定します。

  • 動的マッピングを使用して、サポートされているすべてのフィールドタイプを自動的にインデックス化するように Atlas Search を設定します。

静的マッピングを使用するには、インデックスを作成するフィールドをコレクション内に明示的に含める必要があります。 typeフィールドで、フィールド定義内のフィールドのデータ型を指定します。あるいは、フィールドのフィールド定義の配列を、データ型ごとに 1 つずつ指定することもできます。

構文
1{
2 "mappings": {
3 "dynamic": <boolean>,
4 "fields": {
5 "<field-name>": [
6 {
7 "type": "<field-type>",
8 ...
9 },
10 ...
11 ],
12 ...
13 }
14 }
15}

Atlas Search インデックス定義では、任意の順序でフィールドを定義できます。

静的マッピングと動的マッピングを使用して、Atlas Search がコレクション内のすべての動的にインデックス付け可能なフィールドを自動的にインデックス化する必要があるかどうか指定できます。

静的マッピングを使用して、動的にインデックスを作成したくないフィールドのインデックス オプションを設定したり、1 つのフィールドをインデックス内の他のフィールドと独立して構成したりします。

静的マッピングの場合は、mappings.dynamicfalse に設定し、mappings.fields を使用してインデックスするフィールドを指定します。Atlas Search は、特定のオプションを使用して指定されたフィールドのみをインデックス化します。 インデックス付きフィールドに多形データが含まれている場合、Atlas Search は、そのフィールドのインデックス定義で指定されたマッピングに対応するドキュメントのみをインデックス化し、そのフィールドのインデックス定義で指定されたデータ型ではない値を含むドキュメントを無視します。

ドット表記を使用してネストされたフィールドを静的にインデックスすることはできません。ネストされたフィールドのインデックスを定義する場合、そのネストされたフィールドの各親フィールドのマッピングを定義する必要があります。例については、このページのを参照してください。ここでは、addressという名前のフィールド内にネストされているcityという名前のフィールドのインデックス構文が示されています。

スキーマが定期的に変更される場合や不明な場合、またはAtlas Searchを試す場合は、動的マッピングを使用します。動的マッピングを使用するようにインデックス全体を構成することも、document タイプのフィールドなどの個々のフィールドを動的にマッピングするように指定することもできます。動的マッピングを使用する前に、データ型の表を参照してください。

動的マッピングの場合は、mappings.dynamictrueにします。Atlas Search は、各ドキュメント内のサポートされている型のフィールドを自動的にインデックス化します。文字列 型のフィールドの場合、Atlas Search はそのフィールドをmongotに保存します。

注意

動的にマップされたインデックスは、静的にマップされたインデックスよりも多くのディスク領域を占有し、パフォーマンスを低下させる可能性があります。

Atlas Search では次の BSON データ型をサポートしていません。

  • Decimal128

  • JavaScript コード(スコープ付き)

  • Max key

  • Min key

  • 正規表現

  • タイムスタンプ

次の表は、サポートされている BSON データ型と、BSON データ型のインデックス作成に使用できる Atlas Search フィールド型を示しています。この表には、動的マッピングを有効にしたときに Atlas Search フィールド型が Atlas Search インデックスに自動的に含まれるかどうかも示されており、フィールド値を照会するために使用できる演算子とコレクターがリストされています。

注意

多形データを持つフィールドを動的にインデックス化すると、Atlas Search は、データに対応する動的にインデックス付け可能なすべてのフィールドタイプとしてフィールドを自動的にインデックス化します。自動的にインデックスを作成しない種類のデータがフィールドに含まれている場合、Atlas Search はそのデータのインデックスを作成しません。

BSON 型
Atlas Search フィールド型
動的なインデックス付け
演算子とコレクター

配列内のデータ型をサポートする演算子。

ブール値

日付

日付

Double

Double

Double

knnVector(非推奨)

32 ビット整数

32 ビット整数

64 ビット整数

64 ビット整数

null

該当なし

オブジェクト

すべての演算子

オブジェクト

埋め込みドキュメント(オブジェクトの配列用)

ObjectId

文字列

文字列

文字列

文字列

いくつかの制限が適用されます。詳細については、配列の要素のインデックス作成方法を参照してください。

string タイプの場合、moreLikeThis 演算子および queryString 演算子は文字列の配列をサポートしていません。

Atlas Search は、静的にインデックスが付けられたフィールドと動的にインデックスが付けられたフィールドの両方の null 値を自動的にインデックス化するため、Atlas Search には null 値をインデックス化するためのフィールド タイプが含まれていません。

注意

サポートされているすべての データ型 のフィールドを Atlas Search に格納するには、storedSource オプションを使用します。

デフォルトでは 、Atlas Search は、レプリカセットまたは単一のシャードで、2.100億インデックスオブジェクトを超えるインデックスの変更のレプリケートを停止します。ここでは、インデックス作成されたドキュメントまたはネストされた embeddedDocument はそれぞれ単一のオブジェクトとしてカウントされます。つまり、インデックスはクエリ可能ですが、古い結果が生じる可能性があります。

2.110 億オブジェクトを超える可能性のあるフィールドのインデックスを作成する場合は、numPartitions を使用するか、クラスターをシャーディングします。

重要

numPartitionsオプションはプレビュー機能として利用できます。

フィールド名の先頭にドル記号($)が含まれるフィールドにはインデックスを付けられません。

フィールドを複数のタイプとしてインデックス化するには、フィールドのフィールド定義配列でタイプを定義します。

次の例では、フィールドを複数のタイプとしてインデックスを作成するためのフィールド定義を示しています。

1{
2 ...
3 "mappings": {
4 "dynamic": <boolean>,
5 "fields": {
6 "<field-name>": [
7 {
8 "type": "<field-type>",
9 ...
10 },
11 {
12 "type": "<field-type>",
13 ...
14 },
15 ...
16 ],
17 ...
18 },
19 ...
20 }
21}

以下のインデックス定義例では、静的マッピングを使用しています。

  • デフォルトのインデックス アナライザは lucene.standard です。

  • デフォルトの検索アナライザは lucene.standard です。Atlas Search インデックスに格納する方法とは異なる方法でクエリ用語を解析する場合は、検索アナライザを変更できます。

  • インデックスは静的フィールドマッピング(dynamic: false)を指定します。つまり、明示的に指定されていないフィールドにはインデックスが付けられません。したがって、インデックス定義には次のものが含まれます。

    • document型である、address フィールド。埋め込まれたサブフィールドには citystate の 2 つがあります。

      cityサブフィールドは、クエリに対してデフォルトで lucene.simple アナライザを使用します。ignoreAboveオプションを使用すると、長さが 255 バイトを超える文字列を無視します。

      stateサブフィールドは、クエリに対してデフォルトで lucene.english アナライザを使用します。

    • string型である、company フィールド。クエリにはデフォルトで lucene.whitespace アナライザが使用されます。クエリにデフォルトで lucene.french アナライザを使用するmySecondaryAnalyzerという名前のmultiアナライザがあります。

      multiアナライザの詳細については、パス構築を参照してください。

    • 文字列の配列である employees フィールド。クエリにはデフォルトで lucene.standard アナライザが使用されます。配列のインデックス作成において、Atlas Search では配列要素のデータ型のみが必要です。インデックス定義でデータが配列に含まれていることを指定する必要はありません。

{
"analyzer": "lucene.standard",
"searchAnalyzer": "lucene.standard",
"mappings": {
"dynamic": false,
"fields": {
"address": {
"type": "document",
"fields": {
"city": {
"type": "string",
"analyzer": "lucene.simple",
"ignoreAbove": 255
},
"state": {
"type": "string",
"analyzer": "lucene.english"
}
}
},
"company": {
"type": "string",
"analyzer": "lucene.whitespace",
"multi": {
"mySecondaryAnalyzer": {
"type": "string",
"analyzer": "lucene.french"
}
}
},
"employees": {
"type": "string",
"analyzer": "lucene.standard"
}
}
}
}

次のインデックス定義の例では、静的マッピングと動的マッピングの両方を使用します。

  • デフォルトのインデックス アナライザは lucene.standard です。

  • デフォルトの検索アナライザは lucene.standard です。Atlas Search インデックスに格納する方法とは異なる方法でクエリ用語を解析する場合は、検索アナライザを変更できます。

  • インデックスは静的フィールドマッピング(dynamic: false)を指定します。つまり、明示的に指定されていないフィールドにはインデックスが付けられません。したがって、インデックス定義には次のものが含まれます。

    • string 型である、company フィールド。クエリにはデフォルトで lucene.whitespace アナライザが使用されます。クエリにデフォルトで lucene.french アナライザを使用するmySecondaryAnalyzer という名前のmulti アナライザがあります。multiアナライザの詳細については、パス構築を参照してください。

    • 文字列の配列である employees フィールド。クエリにはデフォルトで lucene.standard アナライザが使用されます。

    • document 型である、address フィールド。埋め込まれたサブフィールドには citystate の 2 つがあります。ドキュメント内のネストされた各フィールドを明示的に指定する代わりに、インデックス定義により、ドキュメント内のすべてのサブフィールドの動的なマッピングが可能になります。クエリにはデフォルトで lucene.standard アナライザが使用されます。

{
"analyzer": "lucene.standard",
"searchAnalyzer": "lucene.standard",
"mappings": {
"dynamic": false,
"fields": {
"company": {
"type": "string",
"analyzer": "lucene.whitespace",
"multi": {
"mySecondaryAnalyzer": {
"type": "string",
"analyzer": "lucene.french"
}
}
},
"employees": {
"type": "string",
"analyzer": "lucene.standard"
},
"address": {
"type": "document",
"dynamic": true
}
}
}
}

戻る

トークン フィルター