쿼리 및 색인 생성에 대한 우수 사례

AEM 6의 Oak로 전환하는 것과 함께 쿼리 및 인덱스가 관리되는 방식에 몇 가지 주요 변경 사항이 수행되었습니다. Jackrabbit 2에서 모든 콘텐츠는 기본적으로 인덱싱되었으며 자유롭게 쿼리할 수 있습니다. Oak에서 인덱스는 oak:index 노드 아래에 수동으로 만들어야 합니다. 쿼리는 인덱스 없이 실행될 수 있지만 큰 데이터 세트의 경우 매우 느리게 실행되거나 중단됩니다.

이 문서에서는 색인을 작성할 때뿐만 아니라 색인이 필요하지 않은 시기, 쿼리가 필요하지 않은 경우 쿼리를 사용하지 않도록 하는 트릭 및 가능한 한 최적으로 수행하기 위해 색인과 쿼리를 최적화하는 팁에 대해 설명합니다.

또한 쿼리 및 인덱스 작성에 대한 Oak 설명서를 읽어야 합니다. AEM 6에서 새로운 개념인 인덱스 외에도 이전 AEM 설치에서 코드를 마이그레이션할 때 고려해야 하는 Oak 쿼리에는 구문 차이가 있습니다.

쿼리 사용 시기

저장소 및 분류 디자인

저장소의 분류 체계를 디자인할 때 몇 가지 요소를 고려해야 합니다. 여기에는 액세스 제어, 로컬라이제이션, 구성 요소 및 페이지 속성 상속이 포함됩니다.

이러한 문제를 해결하는 분류법을 디자인하는 동안 색인 설계의 "순회 기능"을 고려해야 합니다. 이 컨텍스트에서 순회 기능은 경로를 기반으로 컨텐츠를 예측 가능하게 액세스할 수 있는 분류법의 기능입니다. 이렇게 하면 많은 쿼리를 실행해야 하는 것보다 쉽게 유지 관리할 수 있는 성능 시스템이 향상됩니다.

또한 분류법을 디자인할 때는 순서 지정이 중요한지 고려해야 합니다. 명시적 순서가 필요하지 않고 동위 노드의 수가 많은 경우 sling:Folder 또는 oak:Unstructured 같은 순서가 없는 노드 유형을 사용하는 것이 좋습니다. 순서가 필요한 경우 nt:unstructuredsling:OrderedFolder이 더 적절합니다.

구성 요소의 쿼리

쿼리는 AEM 시스템에서 수행되는 더 많은 과세 작업 중 하나일 수 있으므로 구성 요소에서 쿼리를 피하는 것이 좋습니다. 페이지를 렌더링할 때마다 몇 개의 쿼리가 실행되면 시스템의 성능이 저하될 수 있습니다. 구성 요소를 렌더링할 때 쿼리를 실행하지 않도록 하는 두 가지 전략이 있습니다.노드 탐색프리페치 결과.

노드 탐색

저장소가 필요한 데이터의 위치를 미리 알 수 있도록 설계된 경우 필요한 경로에서 이 데이터를 검색하는 코드를 배포하기 위해 쿼리를 실행하지 않고도 배포할 수 있습니다.

특정 카테고리에 맞는 콘텐츠를 렌더링하는 것이 예시입니다. 한 가지 방법은 컨텐츠를 카테고리의 항목을 표시하는 구성 요소를 채우기 위해 쿼리할 수 있는 카테고리 속성으로 구성하는 것입니다.

보다 나은 접근 방법은 이 컨텐츠를 카테고리별로 분류하여 수동으로 검색할 수 있도록 구성하는 것입니다.

예를 들어 다음과 유사한 분류법에 컨텐츠가 저장되는 경우

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

/content/myUnstructuredContent/parentCategory/childCategory 노드는 단순히 검색할 수 있으며, 그 하위 노드를 구문 분석하여 구성 요소를 렌더링하는 데 사용할 수 있습니다.

또한 작은 결과 세트 또는 균일한 결과 세트를 처리하는 경우 동일한 결과 세트를 반환하도록 쿼리를 만드는 대신 리포지토리를 트래버스하고 필요한 노드를 수집하는 것이 더 빠를 수 있습니다. 일반적으로 쿼리는 가능한 곳에서 피해야 합니다.

프리페치 결과

경우에 따라 구성 요소에 대한 컨텐츠 또는 요구 사항에 따라 필요한 데이터를 검색하는 방법으로 노드 순회를 사용할 수 없습니다. 이 경우 최종 사용자에게 최적의 성능을 보장하기 위해 구성 요소를 렌더링하기 전에 필요한 쿼리를 실행해야 합니다.

구성 요소에 필요한 결과를 작성 시 계산할 수 있고 컨텐츠가 변경될 가능성이 없는 경우 작성자가 대화 상자에서 설정을 적용할 때 쿼리를 실행할 수 있습니다.

데이터 또는 컨텐츠가 정기적으로 변경되는 경우 기본 데이터에 대한 업데이트를 위해 일정 또는 수신기를 통해 쿼리를 실행할 수 있습니다. 그런 다음 리포지토리의 공유 위치에 결과를 쓸 수 있습니다. 이 데이터가 필요한 모든 구성 요소는 런타임 시 쿼리를 실행할 필요 없이 이 단일 노드에서 값을 가져올 수 있습니다.

쿼리 최적화

인덱스를 사용하지 않는 쿼리를 실행하면 노드 순서와 관련하여 경고가 기록됩니다. 자주 실행되는 쿼리인 경우 인덱스를 만들어야 합니다. 주어진 쿼리에서 사용할 인덱스를 확인하려면 쿼리 설명 도구를 사용하는 것이 좋습니다. 자세한 내용은 관련 검색 API에 대해 DEBUG 로깅을 활성화할 수 있습니다.

노트

인덱스 정의를 수정한 후 인덱스를 다시 작성(다시 인덱싱)해야 합니다. 인덱스 크기에 따라 완료하는 데 시간이 걸릴 수 있습니다.

복잡한 쿼리를 실행할 때 쿼리를 여러 개의 작은 쿼리로 분류하고 팩트가 더 뛰어난 성능을 발휘한 후 코드를 통해 데이터를 연결하는 경우가 있을 수 있습니다. 이러한 경우에 대한 권장 사항은 두 가지 접근 방식의 성능을 비교하여 해당 사용 사례에 더 적합한 옵션을 결정하는 것입니다.

AEM에서는 다음 세 가지 방법 중 하나로 쿼리를 쓸 수 있습니다.

모든 쿼리가 실행되기 전에 SQL2로 변환되지만 쿼리 변환의 오버헤드가 최소화되므로 쿼리 언어를 선택할 때 가장 큰 문제는 개발 팀에서 가독성과 편안함 수준입니다.

노트

QueryBuilder를 사용할 때 기본적으로 결과 카운트가 결정되며, 이전 버전의 Jackrabbit에 비해 Oak에서는 더 느려집니다. 이를 보완하려면 guessTotal 매개 변수를 사용할 수 있습니다.

쿼리 설명 도구

모든 쿼리 언어와 마찬가지로 쿼리를 최적화하는 첫 번째 단계는 쿼리 실행 방법을 이해하는 것입니다. 이 활동을 활성화하려면 작업 대시보드에 포함된 쿼리 설명 도구를 사용할 수 있습니다. 이 도구를 사용하면 쿼리를 연결하고 설명할 수 있습니다. 쿼리가 실행 시간 및 사용할 색인뿐만 아니라 큰 저장소에 문제가 발생하는지 여부를 묻는 경고가 표시됩니다. 또한 이 도구는 설명하고 최적화할 수 있는 느리고 자주 사용하는 쿼리 목록을 로드할 수 있습니다.

쿼리에 대한 디버그 로깅

Oak에서 사용할 인덱스를 선택하는 방법과 쿼리 엔진이 실제로 쿼리를 실행하는 방법에 대한 자세한 내용을 보려면 다음 패키지에 대해 DEBUG 로깅 구성을 추가할 수 있습니다.

  • org.apache.jackrabbit.oak.plugins.index
  • org.apache.jackrabbit.oak.query
  • com.day.cq.search

쿼리 디버깅을 완료하면 많은 작업이 출력되고 결과적으로 로그 파일로 디스크를 채울 수 있으므로 이 로거를 제거해야 합니다.

이 작업을 수행하는 방법에 대한 자세한 내용은 로깅 설명서를 참조하십시오.

인덱스 통계

Lucene은 각 인덱스에 있는 문서의 크기 및 수를 비롯하여 인덱싱된 컨텐츠에 대한 세부 정보를 제공하는 JMX Bean을 등록합니다.

https://server:port/system/console/jmx에서 JMX 콘솔에 액세스하면 여기에 도달할 수 있습니다

JMX 콘솔에 로그인하고 나면 Lucene Index Statistics​에 대한 검색을 수행하여 찾으십시오. 다른 인덱스 통계는 IndexStats MBean에서 찾을 수 있습니다.

쿼리 통계를 보려면 Oak 쿼리 통계​라는 MBean을 보십시오.

Luke와 같은 도구를 사용하여 인덱스를 검색하려면 Oak 콘솔을 사용하여 NodeStore의 인덱스를 파일 시스템 디렉토리로 덤프해야 합니다. 이 작업을 수행하는 방법에 대한 지침은 Lucene 설명서를 참조하십시오.

시스템의 인덱스를 JSON 형식으로 추출할 수도 있습니다. 이렇게 하려면 https://server:port/oak:index.tidy.-1.json에 액세스해야 합니다

쿼리 제한

개발 중

oak.queryLimitInMemory에 대해 낮은 임계값을 설정합니다(예: 10000)과 oak가 포함된 URL이 있는지 확인합니다. queryLimitReads (예: 5000)을 사용하여 "쿼리가 x 노드보다 많이 읽었습니다…"라는 UnsupportedOperationException을 누를 때 고가의 쿼리를 최적화할 수 있습니다.

이렇게 하면 리소스 집약적인 쿼리(예: 어떤 인덱스도 지원하지 않거나 더 적은 커버 인덱스로 백업되지 않음). 예를 들어, 100만 개의 노드를 읽는 쿼리는 입출력을 높이고 전체 애플리케이션 성능에 부정적인 영향을 줍니다. 위의 제한으로 인해 실패하는 모든 쿼리는 분석 및 최적화되어야 합니다.

배포 후

  • 큰 노드 순회 또는 큰 힙메모리 소비를 트리거하는 쿼리에 대한 로그를 모니터링합니다."

    • *WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
    • 쿼리를 최적화하여 탐색 노드 수를 줄입니다
  • 큰 힙메모리 소비를 트리거하는 쿼리에 대한 로그를 모니터링합니다.

    • *WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
    • 힙메모리 소비를 줄이기 위해 쿼리를 최적화합니다.

AEM 6.0 - 6.2 버전의 경우, AEM 시작 스크립트에서 JVM 매개 변수를 통해 노드 순번의 임계값을 조정하여 큰 쿼리가 환경을 오버로드하지 못하도록 할 수 있습니다.

권장되는 값은 입니다.

  • -Doak.queryLimitInMemory=500000
  • -Doak.queryLimitReads=100000

AEM 6.3에서 위의 2개 매개 변수는 사전 구성된 OOTB이며 OSGi QueryEngineSettings 를 통해 유지할 수 있습니다.

다음에서 추가 정보를 사용할 수 있습니다.https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits

효율적인 인덱스 만들기 팁

인덱스를 만들어야 합니까?

인덱스를 만들거나 최적화할 때 가장 먼저 묻는 질문은 주어진 상황에서 색인이 실제로 필요한지 여부입니다. 일괄 처리 프로세스를 통해 시스템에 대해 한 번 또는 한 번 또는 한 번 또는 가끔 그리고 비스파이크 시간에만 해당 쿼리를 실행하려는 경우 인덱스를 전혀 만들지 않는 것이 좋습니다.

인덱스를 만든 후에는 인덱싱된 데이터가 업데이트될 때마다 색인도 업데이트해야 합니다. 이 경우 시스템에 성능 영향을 주므로 실제로 필요한 경우에만 인덱스를 만들어야 합니다.

또한 색인은 색인에 포함된 데이터가 충분히 고유한 경우에만 유용합니다. 책의 색인과 이 책의 주제를 고려하십시오. 텍스트에서 주제 집합을 인덱싱할 때 일반적으로 수백 또는 수천 개의 항목이 있으며, 이를 통해 페이지 하위 집합으로 빠르게 이동하여 찾고 있는 정보를 빠르게 찾을 수 있습니다. 해당 색인에 2~3개의 항목만 포함되어 있으면 각각 수백 페이지를 가리키면 색인이 별로 유용하지 않을 것입니다. 이러한 개념은 데이터베이스 인덱스에 적용됩니다. 두 개의 고유한 값만 있는 경우 색인은 매우 유용하지 않습니다. 즉, 색인이 너무 커서 유용할 수 없다는 것이다. 인덱스 통계를 보려면 위의 인덱스 통계를 참조하십시오.

Lucene 또는 속성 인덱스?

Lucene 인덱스는 Oak 1.0.9에서 도입되었으며 AEM 6의 초기 시작 시 도입된 속성 인덱스에 대해 몇 가지 강력한 최적화를 제공합니다. Lucene 인덱스 또는 속성 인덱스를 사용할지 결정할 때 다음 사항을 고려하십시오.

  • Lucene 색인은 속성 색인보다 많은 기능을 제공합니다. 예를 들어 속성 인덱스는 단일 속성만 색인화할 수 있고 Lucene 인덱스는 여러 항목을 포함할 수 있습니다. Lucene 색인에서 사용 가능한 모든 기능에 대한 자세한 내용은 설명서를 참조하십시오.
  • Lucene 인덱스는 비동기적입니다. 이렇게 하면 상당한 성능 향상을 제공할 수 있지만, 데이터를 리포지토리에 쓰는 시간과 인덱스를 업데이트하는 시점 사이에 지연을 초래할 수도 있습니다. 쿼리에서 100% 정확한 결과를 반환해야 하는 경우에는 속성 인덱스가 필요합니다.
  • 비동기성을 통해 Lucene 인덱스는 고유성 제약 조건을 적용할 수 없습니다. 필요한 경우 속성 인덱스를 제자리에 두어야 합니다.

일반적으로 높은 성능과 유연성을 얻을 수 있도록 속성 인덱스를 사용해야 할 특별한 필요가 없는 한 Lucene 인덱스를 사용하는 것이 좋습니다.

솔루션 색인 지정

AEM에서는 기본적으로 솔루션 색인화를 지원합니다. 주로 전체 텍스트 검색을 지원하는 데 활용되지만, 모든 유형의 JCR 쿼리를 지원하는 데 사용할 수도 있습니다. 동시 사용자가 많은 검색 기반 웹 사이트와 같이 검색 집약적인 배포에 필요한 쿼리 수를 처리할 CPU 용량이 AEM 인스턴스에 없는 경우 문제를 고려해야 합니다. 또는 Solr을 Crawler 기반 접근 방식으로 구현하여 플랫폼의 일부 고급 기능을 활용할 수 있습니다.

솔루션 인덱스는 개발 환경을 위해 AEM 서버에 임베디드 상태로 실행하도록 구성하거나 원격 인스턴스에 오프로드하여 프로덕션 및 스테이징 환경에서 검색 확장성을 향상시킬 수 있습니다. 검색을 오프로드하면 확장성이 향상되지만 지연이 발생하고 있으므로 필수가 아닌 한 권장되지 않습니다. Solr 통합을 구성하는 방법 및 Solr 인덱스를 만드는 방법에 대한 자세한 내용은 Oak 쿼리 및 색인 지정 설명서를 참조하십시오.

노트

통합 Solr 검색 방법을 사용하면 Solr 서버에 대한 색인을 해제할 수 있습니다. Crawler 기반 접근 방식을 통해 Solr 서버의 고급 기능을 사용하는 경우 추가 구성 작업이 필요합니다. Headwire는 이러한 유형의 구현을 가속화하기 위해 오픈 소스 커넥터를 만들었습니다.

이 방법을 사용하는 데는 기본적으로 AEM 쿼리가 ACL을 준수하므로 사용자가 액세스할 수 없는 결과를 숨기므로 Solr 서버에 대한 검색을 외부화하면 이 기능이 지원되지 않는다는 단점이 있습니다. 이러한 방식으로 검색을 외부화하려면 사용자가 표시되지 않아야 하는 결과가 표시되지 않도록 추가 조치를 취해야 합니다.

이 접근 방식이 적절할 수 있는 잠재적인 사용 사례는 여러 소스의 검색 데이터를 집계해야 하는 경우입니다. 예를 들어 AEM에서 호스팅되는 사이트와 타사 플랫폼에서 호스팅되는 두 번째 사이트가 있을 수 있습니다. 두 사이트의 컨텐츠를 크롤링하고 집계된 인덱스에 저장하도록 솔러를 구성할 수 있습니다. 이렇게 하면 사이트 간 검색이 허용됩니다.

디자인 고려 사항

Lucene 인덱스에 대한 Oak 설명서는 인덱스를 디자인할 때 고려해야 할 몇 가지 고려 사항을 나열합니다.

  • 쿼리에서 다른 경로 제한을 사용하는 경우 evaluatePathRestrictions 을 사용합니다. 이렇게 하면 쿼리에서 지정된 경로 아래에 결과의 하위 집합을 반환한 다음 쿼리를 기준으로 필터링할 수 있습니다. 그렇지 않으면 쿼리에서 저장소의 쿼리 매개 변수와 일치하는 모든 결과를 검색한 다음 경로를 기준으로 필터링합니다.

  • 쿼리에서 정렬을 사용하는 경우 정렬된 속성에 대한 명시적 속성 정의를 가지고 orderedtrue 로 설정합니다. 이렇게 하면 인덱스의 결과와 같은 순서로 결과를 정렬하고 쿼리 실행 시 비용이 많이 드는 정렬 작업을 저장할 수 있습니다.

  • 필요한 것만 색인에 넣어주세요 필요하지 않은 기능 또는 속성을 추가하면 색인이 커지고 성능이 저하됩니다.

  • 속성 인덱스에서 고유한 속성 이름을 갖는 는 인덱스의 크기를 줄이는 데 도움이 되지만 Lucene 인덱스의 경우 통합 인덱스를 얻으려면 nodeTypesmixins을(를) 사용해야 합니다. 특정 nodeType 또는 mixin을 쿼리하는 것은 nt:base를 쿼리하는 것보다 더 많은 성능입니다. 이 방법을 사용하는 경우 해당 nodeTypes에 대해 indexRules을(를) 정의합니다.

  • 쿼리가 특정 경로에서만 실행되는 경우 해당 경로 아래에 해당 인덱스를 만듭니다. 인덱스가 저장소의 루트에 있을 필요는 없습니다.

  • 인덱싱되는 모든 속성이 Lucene에서 기본적으로 가능한 한 많은 속성 제한을 평가할 수 있도록 관련 있는 경우 단일 인덱스를 사용하는 것이 좋습니다. 또한 조인을 수행할 때에도 쿼리는 하나의 색인만 사용합니다.

CopyOnRead

NodeStore이 원격으로 저장되는 경우 CopyOnRead 옵션을 활성화할 수 있습니다. 이 옵션을 선택하면 원격 인덱스가 로컬 파일 시스템에 기록되어 읽기가 수행됩니다. 이렇게 하면 이러한 원격 인덱스에 대해 자주 실행되는 쿼리의 성능을 개선하는 데 도움이 될 수 있습니다.

이 기능은 LuceneIndexProvider 서비스 아래의 OSGi 콘솔에서 구성할 수 있으며 Oak 1.0.13부터 기본적으로 활성화되어 있습니다.

인덱스 제거 중

인덱스를 제거할 때는 항상 type 속성을 disabled(으)로 설정하여 인덱스를 일시적으로 비활성화하고, 실제로 삭제하기 전에 응용 프로그램이 제대로 작동하도록 테스트하는 것이 좋습니다. 색인은 비활성화된 상태에서 업데이트되지 않으므로 다시 활성화한 경우 올바른 컨텐츠가 없을 수 있으며 다시 색인화해야 할 수도 있습니다.

TarMK 인스턴스에서 속성 인덱스를 제거한 후 압축을 실행하여 사용 중인 디스크 공간을 다시 확보해야 합니다. Lucene 인덱스의 경우 실제 인덱스 컨텐츠는 BlobStore에 있으므로 데이터 저장소 가비지 수집이 필요합니다.

MongoDB 인스턴스에서 인덱스를 제거할 때 삭제 비용은 인덱스의 노드 수에 비례합니다. 큰 인덱스를 삭제하면 문제가 발생할 수 있으므로 oak-mongo.js 등의 도구를 사용하여 유지 관리 기간 동안에만 인덱스를 비활성화하고 삭제하는 것이 좋습니다. 이 접근 방식은 데이터 불일치를 초래할 수 있으므로 일반 노드 컨텐츠에 사용하지 않아야 합니다.

노트

oak-mongo.js에 대한 자세한 내용은 Oak 설명서의 명령줄 도구 섹션을 참조하십시오.

다시 색인화

이 섹션에서는 Oak 인덱스를 다시 색인화하는 데 사용할 수 있는 이유는​뿐입니다.

아래 설명된 이유 외에도 Oak 인덱스의 재색인을 시작하면 비헤이비어를 변경하거나 문제를 해결하지 못하고 AEM에서 로드가 일시적으로 증가합니다.

아래 표에 있는 이유로 다루지 않는 한 Oak 인덱스의 재색인화를 방지합니다.

노트

아래 표를 참조하여 색인화를 다시 정의하는 것이 유용하며, 항상 **를 확인하십시오.

  • 쿼리가 올바릅니다
  • 쿼리가 예상 인덱스로 확인됩니다( 쿼리 설명 사용).
  • 인덱싱 프로세스가 완료되었습니다.

Oak 색인 구성 변경 사항

Oak 색인 재색인에 대해 허용되는 유일한 비참조 조건은 Oak 색인 구성이 변경된 경우입니다.

재색인화는 AEM 전체 성능에 미치는 영향에 대해 항상 적절한 고려와 함께 접근해야 하며, 낮은 활동이나 유지 관리 기간 동안 수행해야 합니다.

해결 방법과 함께 발생할 수 있는 다음과 같은 세부 문제를 설명합니다.

속성 인덱스 정의 변경

  • 적용 대상/대상:

  • 증상:

    • 속성 인덱스의 정의 업데이트 이전의 기존 노드가 결과에서 누락되었습니다.
  • 확인 방법:

    • 업데이트된 인덱스 정의를 배포하기 전에 누락된 노드가 생성/수정되었는지 확인합니다.
    • 인덱스가 수정한 시간과 함께 누락된 노드의 jcr:created 또는 jcr:lastModified 속성을 확인합니다
  • 해결 방법:

    • Lucene 인덱스 다시 색인화

    • 또는 누락된 노드에 터치(양호한 쓰기 작업 수행)합니다

      • 수동 수정 또는 사용자 지정 코드 필요
      • 누락된 노드 집합을 알고 있어야 합니다.
      • 노드의 속성을 변경해야 합니다.

Lucene 인덱스 정의 변경

  • 적용 대상/대상:

  • 증상:

    • Lucene 색인에 예상 결과가 없습니다.
    • 쿼리 결과는 인덱스 정의의 예상 동작을 반영하지 않습니다
    • 인덱스 정의에 따라 쿼리 계획이 예상 출력을 보고하지 않습니다
  • 확인 방법:

    • Lucene 인덱스 통계 JMX Mbean(LuceneIndex) 메서드 diffStoredIndexDefinition을 사용하여 인덱스 정의가 변경되었는지 확인합니다.
  • 해결 방법:

    • 1.6 이전의 Oak 버전:

      • Lucene 인덱스 다시 색인화
    • Oak 버전 1.6+

      • 기존 컨텐츠가 변경 사항으로 적용되지 않으면 새로 고침만 필요합니다

        • 🔗 oak:queryIndexDefinition []@refresh=true를 설정하여 lucene 인덱스를 새로 고칩니다.
      • 그렇지 않으면 lucene 인덱스 다시 색인화

        • 참고:새로운 재색인화가 트리거될 때까지 마지막 양호한 재인덱싱(또는 초기 색인)의 인덱스 상태가 사용됩니다

참조 및 예외 상황

다음 표에서는 Oak 인덱스를 다시 인덱싱하면 문제가 해결되는 허용 가능한 예외 및 예외 상황만 설명합니다.

아래 설명된 기준과 일치하지 않는 AEM에 문제가 발생하면 문제를 해결하지 않으므로 인덱스를 다시 색인화하지 마십시오.

해결 방법과 함께 발생할 수 있는 다음과 같은 세부 문제를 설명합니다.

Lucene 인덱스 바이너리가 없습니다.

  • 적용 대상/대상:

  • 증상:

    • Lucene 색인에 예상 결과가 없습니다.
  • 확인 방법:

    • 오류 로그 파일에 Lucene 인덱스의 바이너리가 누락되었다는 예외가 있습니다
  • 해결 방법:

    • 탐색 저장소 검사를 수행합니다.예:

      http://localhost:4502/system/console/repositorycheck

      저장소 탐색은 lucene 파일 외에 다른 바이너리가 누락되었는지 확인합니다

    • lucene 인덱스 이외의 바이너리가 누락된 경우 백업에서 복원

    • 그렇지 않으면 다시 인덱스 모든 lucene 인덱스

    • 메모:

      이 조건은 ANY 바이너리(예: 자산 바이너리)가 누락되었습니다.

      이 경우 누락된 모든 바이너리를 복구하려면 리포지토리의 마지막으로 알려진 양호한 버전으로 복원합니다.

Lucene 인덱스 바이너리가 손상됨

  • 적용 대상/대상:

  • 증상:

    • Lucene 색인에 예상 결과가 없습니다.
  • 확인 방법:

    • error.log에서 예외로 인해 AsyncIndexUpdate(5초마다)이 실패합니다.

      ...a Lucene index file is corrupt...

  • 해결 방법:

    • lucene 인덱스의 로컬 복사본 제거

      1. AEM 중지
      2. crx-quickstart/repository/index에서 lucene 인덱스의 로컬 복사본을 삭제합니다.
      3. AEM 다시 시작
    • 이렇게 해도 문제가 해결되지 않고 AsyncIndexUpdate 예외가 계속되면:

      1. 참조 인덱스 다시 색인화
      2. 또한 Adobe 지원 티켓을 파일에 저장합니다.

다시 색인화하는 방법

속성 인덱스 다시 인덱싱

Lucene 속성 인덱스 다시 인덱싱

  • oak-run.jar를 사용하여 Lucene 속성 인덱스를 다시 색인화합니다.

  • lucene 속성 인덱스에서 async-reindex 속성을 true로 설정합니다.

    • [oak:queryIndexDefinition]@reindex-async=true
노트

위의 섹션에서는 AEM 컨텍스트에서 Apache Oak 설명서의 Oak 재인덱싱 지침을 요약하고 설명합니다.

바이너리 사전 추출 텍스트

텍스트 사전 추출은 분리된 프로세스를 통해 데이터 저장소에서 직접 바이너리에서 텍스트를 추출하고 처리하고 추출된 텍스트를 Oak 인덱스의 후속 재인덱스로 직접 노출하는 프로세스입니다.

  • 추출할 수 있는 텍스트(예: PDF, Word 문서, PPT, TXT) 배포된 Oak 인덱스를 통해 전체 텍스트 검색에 적합합니다.예: /oak:index/damAssetLucene
  • 속성 인덱스가 바이너리에서 텍스트를 추출하지 않으므로 텍스트 사전 추출은 Lucene 인덱스 및 NOT Oak 속성 인덱스의 재색인에만 도움이 됩니다.
  • 텍스트 사전 추출은 텍스트 중심의 바이너리(PDF, Doc, TXT 등)의 전체 텍스트 재색인화를 수행할 때 긍정적인 영향을 많이 받습니다. 여기서 이미지 저장소는 추출 가능한 텍스트를 포함하지 않으므로 동일한 효율성을 제공하지 않습니다.
  • 텍스트 사전 추출을 사용하면 전체 텍스트 검색 관련 텍스트를 매우 효율적으로 추출할 수 있으며, Oak 재인덱싱 프로세스에 표시하여 매우 효율적으로 사용할 수 있습니다.

언제 텍스트 사전 추출을 사용할 수 있습니까?

이진 추출이 활성화된 기존​lucene 인덱스 다시 인덱싱

  • 저장소에서 모든 후보 컨텐츠를 다시 인덱싱하는 중;전체 텍스트를 추출할 바이너리가 많거나 복잡하면 전체 텍스트 추출을 수행하는 데 드는 계산 부담이 AEM에 배치됩니다. 텍스트 사전 추출은 AEM에서 오버헤드 및 리소스 경합을 방지하기 위해 텍스트 추출의 "컴퓨터 비용이 많이 드는 작업"을 AEM Data Store에 직접 액세스하는 분리된 프로세스로 이동합니다.

이진 추출이 활성화된 AEM에 lucene 인덱스 배포를 지원합니다.

  • 새 인덱스(이진 추출을 사용할 수 있음)가 AEM에 배포되면 Oak는 다음 비동기 전체 텍스트 인덱스 실행에서 모든 후보 콘텐츠를 자동으로 인덱싱합니다. 위의 색인 재지정에 설명된 동일한 이유로 AEM에 과도하게 로드될 수 있습니다.

언제 텍스트 사전 추출을 사용할 수 있습니까?

저장소에 추가된 새 컨텐츠에 텍스트 사전 추출을 사용할 수도 없고, 필요할 수도 없습니다.

리포지토리에 새 컨텐츠가 추가되면 비동기 전체 텍스트 인덱싱 프로세스(기본적으로 5초마다)에 의해 자연스럽게 증분 인덱싱됩니다.

웹 UI를 통해 자산을 업로드하거나 자산의 프로그래밍 방식 수집과 같은 AEM의 정상적인 운영에서는 AEM이 자동으로 새로운 이진 컨텐츠에 대한 전체 텍스트 인덱스를 점진적으로 만듭니다. 데이터 양이 증가분 및 비교적 작으므로(5초 후에 리포지토리에 유지할 수 있는 데이터 양 대략), AEM은 전체 시스템 성능에 영향을 주지 않고 인덱싱 중에 바이너리에서 전체 텍스트 추출을 수행할 수 있습니다.

텍스트 사전 추출 을 사용하기 위한 사전 요구 사항

  • 전체 텍스트 이진 추출을 수행하는 lucene 인덱스를 다시 인덱싱하거나 기존 컨텐츠의 전체 텍스트 인덱스 바이너리를 수행하는 새 인덱스를 배포합니다

  • 텍스트를 미리 추출할 컨텐츠(바이너리)는 저장소에 있어야 합니다

  • CSV 파일을 생성하고 최종 재색인을 수행하기 위한 유지 관리 창

  • Oak 버전:1.0.18+, 1.2.3+

  • oak-run.jarversion 1.7.4+

  • 인덱싱 AEM 인스턴스에서 액세스할 수 있는 추출된 텍스트를 저장할 파일 시스템 폴더/공유

    • 텍스트 사전 추출 OSGi 구성은 추출된 텍스트 파일에 대한 파일 시스템 경로가 필요하므로 AEM 인스턴스(로컬 드라이브 또는 파일 공유 마운트)에서 직접 액세스할 수 있어야 합니다

텍스트 사전 추출을 수행하는 방법

노트

아래에 설명된 oak-run.jar 명령은 https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html에 모두 열거됩니다.

위의 다이어그램과 단계는 Apache Oak 설명서에 설명된 기술 텍스트 사전 추출 단계를 설명하고 보완합니다.

텍스트 사전 추출 프로세스 흐름

사전 추출할 컨텐츠 목록 생성

이 작업 중에 노드 저장소가 이동되므로 유지 관리 기간/저사용 기간 동안 1단계(a-b)를 실행하면 시스템에 상당한 로드가 발생할 수 있습니다.

1a. 텍스트를 미리 추출할 노드 목록을 만들려면 oak-run.jar --generate 을 실행하십시오.

1b. 노드 목록(1a)은 파일 시스템에 CSV 파일로 저장됩니다

--generate이 실행될 때마다 전체 노드 저장소가 oak-run 명령의 경로에 지정된 대로 탐색되고 CSV 파일이 만들어집니다. CSV 파일은 텍스트 사전 추출 프로세스의 개별 실행 간에 다시 사용되지 않습니다(단계 1 - 2).

파일 시스템에 텍스트 사전 추출

2단계(a-c)는 데이터 스토어와만 상호 작용하므로 AEM의 정상적인 작업 중에 실행할 수 있습니다.

2a. (1b)에서 생성된 CSV 파일에 열거된 이진 노드의 텍스트를 미리 추출하려면 oak-run.jar --tika 을 실행하십시오.

2 b. (2a)에서 시작된 프로세스는 데이터 저장소의 CSV에 정의된 이진 노드에 직접 액세스하여 텍스트를 추출합니다.

2c. 추출된 텍스트는 Oak 재인덱싱 프로세스(3a)에서 수집되는 형식으로 파일 시스템에 저장됩니다

사전 추출된 텍스트는 CSV에서 이진 지문으로 식별됩니다. 이진 파일이 동일한 경우 AEM 인스턴스에서 미리 추출된 동일한 텍스트를 사용할 수 있습니다. AEM Publish는 일반적으로 AEM Author의 하위 세트이므로 AEM Author에서 미리 추출한 텍스트를 사용하여 AEM Publish를 다시 색인화할 수 있습니다(AEM Publish에서 추출된 텍스트 파일에 대한 파일 시스템 액세스 권한이 있다고 가정).

미리 추출된 텍스트는 시간에 따라 점진적으로 추가할 수 있습니다. 텍스트 사전 추출은 이전에 추출된 바이너리에 대한 추출을 건너뛰므로, 이후에 다시 색인화가 발생할 경우 사전 추출된 텍스트를 유지하는 것이 좋습니다(추출된 컨텐츠가 그리 크지 않다고 가정할 경우). 그럴 경우 텍스트가 잘 압축되므로 중간에 있는 내용물의 압축을 평가하십시오.

추출된 텍스트 파일에서 전체 텍스트를 소싱하는 Oak 인덱스 다시 색인화

이 작업 중에 노드 저장소가 탐색됨에 따라 유지 관리/저사용 기간 동안 재인덱싱(3a-b단계)을 실행하면 시스템에 상당한 로드가 발생할 수 있습니다.

3a. Lucene 인덱스 의 재색인이 AEM에서 호출됩니다.

3b. Apache Jackrabbit Oak DataStore PreExtrutedTextProvider OSGi 구성(파일 시스템 경로를 통해 추출된 텍스트를 가리키도록 구성됨)은 Oak에게 추출된 파일에서 전체 텍스트 텍스트를 소스에 전달하도록 지시하고 저장소에 저장된 데이터를 직접 히트하고 처리하지 않도록 합니다.

이 페이지에서는