フィールド マッピングの定義
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.dynamic
を false
に設定し、mappings.fields
を使用してインデックスするフィールドを指定します。Atlas Search は、特定のオプションを使用して指定されたフィールドのみをインデックス化します。 インデックス付きフィールドに多形データが含まれている場合、Atlas Search は、そのフィールドのインデックス定義で指定されたマッピングに対応するドキュメントのみをインデックス化し、そのフィールドのインデックス定義で指定されたデータ型ではない値を含むドキュメントを無視します。
ドット表記を使用してネストされたフィールドを静的にインデックスすることはできません。ネストされたフィールドのインデックスを定義する場合、そのネストされたフィールドの各親フィールドのマッピングを定義する必要があります。例については、このページの例を参照してください。ここでは、address
という名前のフィールド内にネストされているcity
という名前のフィールドのインデックス構文が示されています。
ダイナミックマッピング
スキーマが定期的に変更される場合や不明な場合、またはAtlas Searchを試す場合は、動的マッピングを使用します。動的マッピングを使用するようにインデックス全体を構成することも、document
タイプのフィールドなどの個々のフィールドを動的にマッピングするように指定することもできます。動的マッピングを使用する前に、データ型の表を参照してください。
動的マッピングの場合は、mappings.dynamic
をtrue
にします。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 は、レプリカセットまたは単一のシャードで、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
フィールド。埋め込まれたサブフィールドにはcity
とstate
の 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
フィールド。埋め込まれたサブフィールドにはcity
とstate
の 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 } } } }