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

  • 4 分

NoSQL クエリの柔軟性を長く保ちたい場合に、パスを除外するのはなぜでしょうか。 挿入操作または更新操作のたびに、インデクサーを実行して、新たに作成または更新した項目のデータで逆インデックスを更新する必要があります。 サイズが大きい項目が多い場合またはワークロードが大きい場合は、インデックス作成に多くの 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 つだけであり、その後に複数の潜在的な値があることを示しています。

単一のプロパティ ノード price と複数の子ノードを含む逆ツリー

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

{
  "indexingMode": "none",
}