インデックス作成ポリシー戦略を確認する
最も簡単に言えば、インデックス作成ポリシーは、実際にどのプロパティにインデックスを作成するかを決定するために評価される include/exclude 式の 2 つのセットです。 この性質上、include と exclude のパスの間には競合が発生しますが、競合の存在は設計上の問題です。 競合が発生すると、精度が最も高い式が優先されます。 たとえば、次の 2 つの include と exclude のパス セットを評価しましょう。
対象のパス:
/category/name/?
対象外のパス:
/category/*
対象外のパスでは、category パス内で使用可能なすべてのプロパティが除外されます。ただし、対象のパスの方が精度は高く、具体的には category.name プロパティが含まれます。 その結果、category 内のすべてのプロパティにインデックスが作成されることがなくなります。唯一の例外は、category.name プロパティです。
インデックス作成ポリシーには、ルート パスと、対象の、または対象外のパスとして指定できるすべての値 (/*
) を含める必要があります。 その基準を超える精度のレベルとして、より多くのカスタマイズが存在します。 これにより、多くの例で見られる 2 つの基本的なインデックス作成戦略が生み出されます。
まず、一部のインデックス作成ポリシーには、ルート パスで使用できるすべてのプロパティが含まれます。そして、対象外のパスの一覧を使用して、必要に応じて特定のプロパティまたはパスを除外します。 この戦略は、既定のインデックス作成ポリシーの場合です。 これに続くのは、category.id を除くすべてのプロパティを含むインデックス作成ポリシーの例です。
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/category/id/?"
}
]
}
ヒント
一般に、すべてのパスを既定で含めて、特定のパスのみをインデックスから除外する方が、はるかに優れた方法です。 この戦略では、ユーザーはスキーマを変更でき、インデックスは新しいプロパティのセットで引き続き動作します。
次に、他のインデックス作成ポリシーでは、ルート パスで使用可能なすべてのプロパティを除外し、パスの特定のプロパティを選択して含めることができます。 このインデックス作成ポリシーの例では、すべてのプロパティが除外され、name と tags[].name のプロパティのみを選択してインデックスが作成されています。
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/name/?"
},
{
"path": "/tags/[]/name/?"
}
],
"excludedPaths": [
{
"path": "/*"
}
]
}