前へ

次へ

インデックスについて理解する

完了

すべての Azure Cosmos DB for NoSQL コンテナーには、各項目のインデックス作成方法を決定する組み込みポリシーがあります。 既定では、このポリシーにより、任意の項目の作成、更新、または削除操作でインデックスを更新し、インデックスにすべての項目のすべてのプロパティを含める必要があります。 このインテリジェントな既定値は、インデックスのチューニングまで深く掘り下げることなく、優れた予測可能なクエリ パフォーマンスが得られるため、多くのソリューションの開始時に最適です。

既定のポリシーの例を実際に確認しましょう。

ここに、3 つのタグ (bike、touring、および blue) が付いた Touring-1000 Blue という名前の製品を表す JSON オブジェクトがあります。 tags 配列内の要素の数に注意する必要があります。

{
  "name": "Touring-1000 Blue",
  "tags": [
    {
      "name": "bike"
    },
    {
      "name": "touring"
    },
    {
      "name": "blue"
    }
  ]
}

この JSON オブジェクトをツリーとして表す場合、この表現には、name プロパティとその値 (Touring-1000 Blue) の両方の走査パスが含まれています。 ツリーには、tags 配列内の 3 つのオブジェクトの 3 つの走査パスも含まれています。それぞれに、name プロパティとそれぞれの値のリーフ ノードがあります。

対比のため、Mountain-400-W Silver という名前の製品を表すもう 1 つの JSON オブジェクトを次に示します。このオブジェクトには、2 つのタグ (bike と silver) だけが含まれます。 このオブジェクトは、BK-M38S-38 の値を持つ sku プロパティが含まれるという点でも一意です。

{
  "name": "Mountain-400-W Silver",  
  "sku": "BK-M38S-38",
  "tags": [
    {
      "name": "bike"
    },
    {
      "name": "silver"
    }
  ]
}

この JSON オブジェクトのツリー表現には、name と sku のプロパティの単純な走査パスが含まれています。 これには、tags 配列内の 2 つのオブジェクトの 2 つの走査パス、および name プロパティとそれぞれの値のリーフ ノードも含まれます。

コンテナーのインデックスを概念化する場合、私たちはインデックスをコンテナー内の各項目のすべてのツリーの共用体と考える傾向があります。 これにより、逆インデックスが作成され、クエリ操作を実行するときにデータベース エンジンが高速かつ効率的に走査できます。 ツリー内の各ノードには、インデックス内のどの項目が特定のノードと一致するかを示すメタデータがあります。

この例を示すため、次の SQL クエリを考えてみましょう。

SELECT * FROM products p WHERE p.sku = 'BK-M38S-38'

検索エンジンは、各項目を個別に走査するのではなく、逆インデックスを走査します。 このクエリでは、サンプル走査について説明します。

1. 最初に、検索エンジンがルートから開始されます。 現在のところ、すべての項目が一致します。
2. 次に、検索によって sku プロパティが走査されます。 今度は、#2 項目だけが一致します。
3. 最後に、検索が BK-M38S-28 ノードで終了します。 やはり、#2 項目だけが一致します。

検索結果では、#2 項目 (Mountain-400-W Silver) が一致し、SQL クエリによってこの項目のすべてのフィールドが返されます。

SQL クエリの別の例を使用します。

SELECT p.id FROM products p WHERE p.name = 'Touring-1000 Blue'

同様の走査を実行できます。

1. ルートから始まり、すべての項目が一致します。
2. name プロパティに移動しても、やはりすべての項目が一致します。
3. 最後に、Touring-1000 Blue ノードで終わり、#1 項目だけが一致します。

検索結果では、#1 項目 (Touring-1000 Blue) が一致し、SQL クエリによってこの項目の id フィールドのみが返されます。

続行