処理に時間のかかるクエリのトラブルシューティング troubleshooting-slow-queries

インデックスなしクエリ

• 実行するクエリ not インデックスに解決し、JCR のコンテンツを走査して結果を収集する

制限（範囲指定）が不十分なクエリ

• インデックスに解決されるが、結果を収集するには、すべてのインデックスエントリをトラバースする必要があるクエリ

大きな結果セットクエリ

• 非常に多くの結果を返すクエリ

クエリが既存の Lucene プロパティインデックスに解決されるように、ノードタイプの制限を追加します。

• 最適化されていないクエリ

  code language-none
  property=jcr:content/contentType property.value=article-page

• 最適化されたクエリ

  code language-none
  type=cq:Page property=jcr:content/contentType property.value=article-page

ノードタイプの制限がないクエリにより、AEM では nt:base ノードタイプが想定されます。これは、AEM のすべてのノードのサブタイプなので、実質上ノードタイプの制限は存在しません。

type=cq:Page を設定すると、このクエリは cq:Page ノードのみに限定され、AEM の cqPageLucene に解決されます。これにより、結果は AEM のノードのサブセット（ cq:Pageノードのみ）に限定されます。

クエリが既存の Lucene プロパティインデックスに解決されるように、クエリのノードタイプ制限を調整します。

• 最適化されていないクエリ

  code language-none
  type=nt:hierarchyNode property=jcr:content/contentType property.value=article-page

• 最適化されたクエリ

  code language-none
  type=cq:Page property=jcr:content/contentType property.value=article-page

nt:hierarchyNode は、cq:Page の親ノードタイプです。カスタムアプリケーションを通じて jcr:content/contentType=article-page が cq:Page ノードのみに適用されるとすると、このクエリは、jcr:content/contentType=article-page である cq:Page ノードのみを返します。ただしこれは、以下の理由から、次善策としての制限となります。

• nt:hierarchyNode から継承された他のノード（例：dam:Asset）が、結果候補のセットに不必要に追加されます。
• AEM で提供される、nt:hierarchyNode 用のインデックスは存在しませんが、cq:Page 用に提供されているインデックスはあります。

type=cq:Page を設定すると、このクエリは cq:Page ノードのみに限定され、AEM の cqPageLucene に解決されます。これにより、結果は AEM のノードのサブセット（cq:Page ノードのみ）に限定されます。

または、クエリが既存のプロパティインデックスに解決されるようにプロパティの制限を調整します。

• 最適化されていないクエリ

  code language-none
  property=jcr:content/contentType property.value=article-page

• 最適化されたクエリ

  code language-none
  property=jcr:content/sling:resourceType property.value=my-site/components/structure/article-page

プロパティの制限を jcr:content/contentType（カスタム値）から既知のプロパティ sling:resourceType に変更すると、クエリはプロパティインデックス slingResourceType に解決されます。これは、sling:resourceType によってすべてのコンテンツにインデックスを作成します。

（Lucene プロパティインデックスとは異なる）プロパティインデックスは、クエリがノードタイプで認識されず、単一のプロパティ制限が結果セットに優先する場合に最も適しています。

クエリに可能な最も厳密なパス制限を追加します。 例：/content/my-siteより/content/my-site/us/enが推奨され、また/より/content/damが推奨されます。

• 最適化されていないクエリ

  code language-none
  type=cq:Page path=/content property=jcr:content/contentType property.value=article-page

• 最適化されたクエリ

  code language-none
  type=cq:Page path=/content/my-site/us/en property=jcr:content/contentType property.value=article-page

パス制限の範囲を path=/content から path=/content/my-site/us/en に指定すると、調査する必要があるインデックスエントリの数を減らすことができます。単に /content や /content/dam ではなく、クエリでパスを効果的に制限できる場合は、インデックスに evaluatePathRestrictions=true があることを確認します。

evaluatePathRestrictions を使用すると、インデックスのサイズが大きくなります。

可能な場合は、LIKE や fn:XXXX などのクエリの関数や操作を避けます。これらのコストは、制限に基づいた結果の数に伴って増減するからです。

• 最適化されていないクエリ

  code language-none
  type=cq:Page property=jcr:content/contentType property.operation=like property.value=%article%

• 最適化されたクエリ

  code language-none
  type=cq:Page fulltext=article fulltext.relPath=jcr:content/contentType

LIKE 条件の評価には時間がかかります。これは、テキストがワイルドカードで始まる場合（「%…」）はインデックスを使用できないからです。jcr:contains 条件は、フルテキストのインデックスの使用を可能にするので、推奨されています。これには、解決された Lucene プロパティインデックスに、analayzed=true に設定された jcr:content/contentType のインデックスルールが必要です。

fn:lowercase(..) などのクエリ関数の使用を最適化するのは、（より複雑で目立つインデックス分析設定の外部に）より高速な同等の手段がないので困難です。他のスコーピング制限を特定して、クエリ全体のパフォーマンスを向上させ、可能な限り小さな結果セットに対して関数を操作する必要があるようにすることをお勧めします。

この調整は、Query Builder 固有であり、JCR-SQL2 または XPath には当てはまりません​ 。

用途 Query Builder の guessTotal 結果の完全なセットがすぐに必要​ な ​場合。

• 最適化されていないクエリ

  code language-none
  type=cq:Page path=/content

• 最適化されたクエリ

  code language-none
  type=cq:Page path=/content p.guessTotal=100

クエリの実行時間が短くても結果の数が多い場合、p.guessTotal は、Query Builder のクエリにとって必要不可欠な最適化です。

p.guessTotal=100 を指定すると、Query Builder は最初の 100 件の結果だけを収集し、さらに 1 つ以上の結果が存在するかどうかを示すブール値フラグを設定します（ただしカウントすると処理に時間がかかるので、残りの数は示されません）。この最適化は、ページネーションや無限読み込みの使用例に優れ、結果のサブセットのみが増分的に表示されます。

最適なクエリがプロパティインデックスに解決される場合、プロパティインデックスは最小限の調整可能なので、実行する必要はありません。

それ以外の場合は、クエリは Lucene プロパティインデックスに解決する必要があります。 解決できるインデックスがない場合は、新しいインデックスの作成に進みます。

必要に応じて、クエリを XPath または JCR-SQL2 に変換します。

• Query Builder クエリ

  code language-none
  query type=cq:Page path=/content/my-site/us/en property=jcr:content/contentType property.value=article-page orderby=@jcr:content/publishDate orderby.sort=desc

• Query Builder クエリから生成された XPath

  code language-none
  /jcr:root/content/my-site/us/en//element(*, cq:Page)[jcr:content/@contentType = 'article-page'] order by jcr:content/@publishDate descending

この XPath（または JCR-SQL2）を Oak Index Definition Generator に提供して、最適化された Lucene プロパティインデックス定義を生成します。

生成された Lucene プロパティインデックス定義

- evaluatePathRestrictions = true
- compatVersion = 2
- type = "lucene"
- async = "async"
- jcr:primaryType = oak:QueryIndexDefinition
    + indexRules
    + cq:Page
        + properties
        + contentType
            - name = "jcr:content/contentType"
            - propertyIndex = true
        + publishDate
            - ordered = true
            - name = "jcr:content/publishDate"

生成された定義を、追加する形で既存の Lucene プロパティインデックスに手動で結合します。既存の設定は、他のクエリを満たすために使用される場合があるので、削除しないように注意してください。

1. cq:Page に対応する既存の Lucene プロパティインデックスを探します（インデックスマネージャを使用）。 この場合は、/oak:index/cqPageLuceneです。
2. 最適化されたインデックス定義 ( ステップ#4) と既存のインデックス (https://experienceleague.adobe.com/oak:index/cqPageLucene?lang=ja) の間の設定差分を特定し、最適化されたインデックスの欠落している設定を既存のインデックス定義に追加します。
3. AEMの再インデックスのベストプラクティスに従って、このインデックス設定の変更によって既存のコンテンツが影響を受けるかどうかに基づいて、更新または再インデックスが順番におこなわれます。

クエリが既存の Lucene プロパティインデックスに解決されないことを確認します。 その場合は、上記の「チューニングと既存のインデックス」の節を参照してください。

必要に応じて、クエリを XPath または JCR-SQL2 に変換します。

• Query Builder クエリ

  code language-none
  type=myApp:Author property=firstName property.value=ira

• Query Builder クエリから生成された XPath

  code language-none
  //element(*, myApp:Page)[@firstName = 'ira']

この XPath（または JCR-SQL2）を Oak Index Definition Generator に提供して、最適化された Lucene プロパティインデックス定義を生成します。

生成された Lucene プロパティインデックス定義

- compatVersion = 2
- type = "lucene"
- async = "async"
- jcr:primaryType = oak:QueryIndexDefinition
    + indexRules
    + myApp:AuthorModel
        + properties
        + firstName
            - name = "firstName"
            - propertyIndex = true

生成された Lucene プロパティインデックス定義をデプロイします。

Oak インデックス定義を管理するAEMプロジェクトに、新しいインデックス用の Oak Index Definition Generator が提供する XML 定義を追加します（コードはコードに依存するので、Oak インデックス定義をコードとして扱うことを忘れないでください）。

通常のAEMソフトウェア開発ライフサイクルに従って新しいインデックスをデプロイおよびテストし、クエリがインデックスに解決され、クエリが実行されていることを確認します。

このインデックスの初期デプロイメント時に、AEMは必要なデータをインデックスに入力します。