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

インデックスのないクエリ

• インデックスに解決​ されず、結果を収集するために JCR のコンテンツをトラバースするクエリ

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

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

結果セットが大きいクエリ

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

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

完全な結果セットがすぐに必要で​ ない ​場合は、Query Builder の guessTotal を使用します。

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

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

• 最適化されたクエリ

  code language-js
  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-js
  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-js
  /jcr:root/content/my-site/us/en//element(*, cq:Page)[jcr:content/@contentType = 'article-page'] order by jcr:content/@publishDate descending

この XPath（または JCR-SQL2）を https://oakutils.appspot.com/generate/index で 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）と既存のインデックス（/oak:index/cqPageLucene）の設定の差分を特定し、欠けている設定を最適化したインデックスから既存のインデックス定義に追加します。
3. AEM のインデックス再作成のベストプラクティスにより、このインデックス設定の変更が既存コンテンツに影響するかどうかに基づいて、更新または再インデックス付けのいずれかが必要になります。

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

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

• Query Builder クエリ

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

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

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

この XPath（または JCR-SQL2）を https://oakutils.appspot.com/generate/index で 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 Index Definition Generator によって新しいインデックスに提供された XML 定義を、Oak インデックス定義を管理する AEM プロジェクトに追加します（コードは Oak インデックス定義に依存するので、これらの定義はコードとして扱うことを忘れないでください）。

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

このインデックスを初めてデプロイしたときに、AEM によってインデックスに必要なデータが追加されます。