느린 쿼리 문제 해결 troubleshooting-slow-queries

인덱스 없는 쿼리

• 수행하는 쿼리 not 인덱스를 확인하고 JCR의 컨텐츠를 트래버스하여 결과를 수집합니다.

제한된(또는 범위 지정) 쿼리

• 인덱스로 확인되지만 결과를 수집하려면 모든 인덱스 항목을 트래버스해야 하는 쿼리

큰 결과 집합 쿼리

• 매우 많은 결과를 반환하는 쿼리

쿼리가 기존 Lucene 속성 인덱스로 확인되도록 nodetype 제한을 추가합니다.

• 최적화되지 않은 쿼리

  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

nodetype 제한이 없는 쿼리는 AEM에서 nt:base nodetype: AEM의 모든 노드가 하위 유형이므로 nodetype 제한이 없습니다.

설정 type=cq:Page 이 쿼리는 cq:Page 노드를 확인하고 쿼리를 AEM cqPageLucene로 확인하여 결과를 노드의 하위 집합으로 제한합니다(노드 전용). 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 사용자 지정 응용 프로그램을 통해 노드를 반환하면 이 쿼리는 cq:Page 노드 위치 jcr:content/contentType=article-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 속성 인덱스와 반대됨)는 쿼리가 nodetype으로 식별되지 않고 단일 속성 제한이 결과 집합을 지배하는 경우 가장 잘 사용됩니다.

쿼리에 가능한 가장 가까운 경로 제한을 추가합니다. 예를 들어, /content/my-site/us/en over /content/my-site, 또는 /content/dam over /.

• 최적화되지 않은 쿼리

  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=/contentto 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 속성 색인이 jcr:content/contentType with analayzed=true.

과 같은 쿼리 함수 사용 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 은(는) 처음 100개의 결과만 수집하도록 Query Builder에 지시하고, 하나 이상의 결과가 있는지 여부를 나타내는 부울 플래그를 설정합니다(이 수를 카운트하면 속도가 느려질 수 있으므로). 이 최적화는 결과의 하위 집합만 점진적으로 표시되는 페이지 매김 또는 무한 로드 사용 사례를 능가합니다.

최적 쿼리가 속성 인덱스로 확인되면 속성 인덱스가 최소 조정 가능하므로 수행할 작업이 남아 있지 않습니다.

그렇지 않으면 쿼리가 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 색인 정의 생성기 최적화된 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=ko) 간의 구성 델타를 식별하고 최적화된 인덱스의 누락된 구성을 기존 인덱스 정의에 추가합니다.
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 색인 정의 생성기 최적화된 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 색인 정의 생성기에서 제공하는 XML 정의를 추가합니다(코드가 에따라 Oak 색인 정의를 코드로 처리).

일반적인 AEM 소프트웨어 개발 수명 주기에 따라 새 인덱스를 배포하고 테스트하고 쿼리가 인덱스로 확인되고 쿼리가 작동하는지 확인합니다.

이 색인의 초기 배포 시 AEM은 필수 데이터로 색인을 채웁니다.