書き込み負荷の高いインデックス パターンを確認する

完了

SQL クエリの柔軟性を長く保ちたい場合に、パスを除外するのはなぜでしょうか。 挿入操作または更新操作のたびに、インデクサーを実行して、新たに作成または更新した項目のデータで逆インデックスを更新する必要があります。 サイズが大きい項目が多い場合またはワークロードが大きい場合は、インデックス作成に多くの RU が使用されたり、長い時間がかかったりすることになります。

前の例よりもはるかに大きい JSON オブジェクトの例について考えてみましょう。

{
  "id": "3324734",
  "name": "Road-200 Green",
  "internal": {
    "tracking": {
      "id": "eac06d51-2462-4bfb-8eb6-46281da16f8e"
    }
  },
  "inStock": true,
  "price": 1303.33,
  "description": "Consequat dolore commodo tempor pariatur consectetur fugiat labore velit aliqua ut anim. Et anim eu ea reprehenderit sit ullamco elit irure laborum sunt ea adipisicing eu qui. Officia commodo ad amet ea consectetur ea est fugiat.",
  "warehouse": {
    "shelfLocations": [
      20,
      37,
      35,
      27,
      38
    ]
  },
  "metadata": {
    "color": "brown",
    "manufacturer": "Fabrikam",
    "supportEmail": "support@fabrik.am",
    "created_by": "sdfuouu",
    "created_on": "2020-05-05T19:21:27.0000000Z",
    "department": "cycling",
    "sku": "RD200-B"
  },
  "tags": [
    "pariatur",
    "et",
    "commodo",
    "ex",
    "tempor",
    "esse",
    "nisi",
    "ullamco",
    "Lorem",
    "ullamco",
    "ex",
    "ea",
    "laborum",
    "tempor",
    "consequat"
  ]
}

既定のインデックス作成ポリシーを使用すると、新しい項目を作成するか既存の項目を更新するたびに、この項目全体とすべてのパスにインデックスが付けられて、逆インデックスに追加されます。 項目内の 1 つのプロパティを更新した場合でも、インデックス作成が項目全体に対して実行されます。

これに対処するために、SQL クエリで必要なもの以外すべてのパスを除外したインデックス作成ポリシーを使用できます。 アプリケーションによって次の 2 つの SQL クエリしか発行されないシナリオについて考えてみましょう。

SELECT 
    * 
FROM 
    products p
WHERE
    p.price >= <numeric-value> AND
    p.price <= <numeric-value>
SELECT 
    * 
FROM 
    products p
WHERE
    p.price = <numeric-value>

ここでは、price プロパティ パスを除くすべてのパスを除外するインデックス作成ポリシーが適切です。 このポリシーでも項目にインデックスが付けられますが、逆インデックスに追加されるプロパティは 1 つだけなのですばやく行われます。

{
  "indexingMode": "consistent",
  "automatic": true,
  "includedPaths": [
    {
      "path": "/price/?"
    }
  ],
  "excludedPaths": [
    {
      "path": "/*"
    }
  ]
}

ヒント

この方法の欠点は、やはり、スキーマを変更するたびにインデックスを更新する必要があることです。

次に示すのは、走査するプロパティ 1 つのみと可能性がある複数の値が含まれる逆インデックスの図です。

Inverted tree with a single property node of price and multiple child nodes

アプリケーションは書き込み負荷が高く、id および partition key 値を使用したポイント読み取りしかしないと想定します。 その場合は、カスタマイズしたインデックス作成ポリシーを使用して、インデックス作成を完全に無効にすることもできます。

{
  "indexingMode": "none",
}