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

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

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

또한 쿼리 및 인덱스](/docs/experience-manager-64/sites-deploying/queries-and-indexing.html?lang=ko)를 작성하는 방법에 대한 [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에서는 다음 3가지 방법 중 하나로 쿼리를 작성할 수 있습니다.

모든 쿼리를 실행하기 전에 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 인덱스 통계​를 검색하여 찾습니다. 다른 인덱스 통계는 IndexStats MBean에서 찾을 수 있습니다.

쿼리 통계에 대해서는 Oak 쿼리 통계​라는 MBean을 확인합니다.

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

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

쿼리 제한

개발 중

oak.queryLimitInMemory(예: 10000) 및 oak. 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
    • Heap 메모리 소비를 줄이기 위해 쿼리 최적화

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

권장 값은 다음과 같습니다.

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

AEM 6.3에서는 위의 2개 매개 변수가 미리 구성된 OTB이며 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 쿼리를 지원하는 데에도 사용할 수 있습니다. AEM 인스턴스에 동시 사용자 수가 많은 검색 기반 웹 사이트와 같은 검색 중심 배포에 필요한 쿼리 수를 처리할 수 있는 CPU 용량이 없는 경우 솔루션을 고려해야 합니다. 또는 Solr을 Crawler 기반 접근 방식으로 구현하여 플랫폼의 일부 고급 기능을 활용할 수 있습니다.

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

노트

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

이 접근 방식을 사용하기 어려운 점은 기본적으로 AEM 쿼리는 ACL을 준수하므로 사용자에게 액세스 권한이 없는 결과를 숨김하므로 Solr 서버에 검색을 외부화하면 이 기능이 지원되지 않는다는 점입니다. 이러한 방식으로 검색이 외부화되려면 사용자에게 표시되지 않아야 할 결과가 표시되지 않도록 각별히 주의해야 합니다.

이 접근 방식이 적절할 가능성이 있는 경우에 사용할 수 있는 경우도 여러 소스의 검색 데이터를 집계해야 할 수 있습니다. 예를 들어 AEM에서 호스팅되는 사이트는 물론 제3자 플랫폼에서 호스팅되는 제2의 사이트도 있을 수 있습니다. 두 사이트의 컨텐츠를 크롤링하고 이를 집계된 인덱스에 저장하도록 솔러를 구성할 수 있습니다. 이를 통해 크로스 사이트 검색을 수행할 수 있습니다.

디자인 고려 사항

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

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

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

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

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

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

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

CopyOnRead

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

OSGi 콘솔에서 LuceneIndexProvider 서비스 아래에 구성할 수 있으며 Oak 1.0.13부터 기본적으로 활성화됩니다.

인덱스제거

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

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

MongoDB 인스턴스에서 인덱스를 제거하면 삭제 비용이 인덱스의 노드 수에 비례합니다. 큰 색인을 삭제하면 문제가 발생할 수 있으므로 권장 방법은 oak-mongo.js​와 같은 도구를 사용하여 인덱스를 비활성화하고 유지 관리 기간 중에만 삭제하는 것입니다. 데이터 불일치를 도입할 수 있으므로 이 방법을 일반 노드 컨텐츠에 사용해서는 안 됩니다.

노트

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

다시 색인화

이 섹션에서는 Oak 색인을 다시 색인화하는 데 사용할 수 있는 이유인 만 간략히 설명합니다.

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

아래 표에 있는 이유로 인해 설명되지 않는 한 Oak 색인의 재인덱스는 피하십시오.

노트

색인화를 확인하기 위해 아래 표를 살펴보기 전에 항상

  • 쿼리가 정확합니다.
  • 쿼리가 필요한 인덱스로 확인됩니다(쿼리 설명 사용).
  • 인덱싱 프로세스가 완료되었습니다.

Oak 인덱스 구성 변경 사항

Oak 색인을 다시 인덱싱할 수 있는 유일한 예외 조건은 Oak 인덱스의 구성이 변경된 경우입니다.

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

해상도와 관련하여 다음과 같은 세부 문제가 발생할 수 있습니다.

속성 인덱스 정의 변경

  • 적용 대상/해당되는 경우:

  • 증상:

    • 속성 인덱스의 정의 업데이트 이전에 존재하는 노드가 결과에 없습니다.
  • 확인 방법:

    • 업데이트된 색인 정의를 배포하기 전에 누락된 노드가 만들어졌는지/수정했는지 확인합니다.
    • 인덱스 수정 시간에 대해 누락된 노드의 jcr:created 또는 jcr:lastModified 속성을 확인합니다.
  • 해결 방법:

    • 루틴 색인을 다시 색인화합니다.

    • 또는 누락된 노드를 터치(양성 쓰기 작업 수행)합니다.

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

Lucene 색인 정의 변경

  • 적용 대상/해당되는 경우:

  • 증상:

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

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

    • 1.6 이전의 Oak 버전:

      • 루틴 색인을 다시 색인화합니다.
    • Oak 버전 1.6+

      • 기존 컨텐츠가 변경 사항으로 영향을 받지 않으면 새로 고침만 필요합니다

      • 그렇지 않은 경우 lucene 색인을 다시 색인

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

예외 및 예외 상황

다음 표에서는 Oak 색인을 다시 색인화하면 문제가 해결되는 허용 가능한 예외 사항 및 예외 상황에 대해 설명합니다.

아래 나와 있는 기준과 일치하지 않는 AEM에 문제가 발생하면 문제를 해결하지 못하므로 색인을 다시 색인화하지 마십시오.

해상도와 관련하여 다음과 같은 세부 문제가 발생할 수 있습니다.

Lucene 인덱스 바이너리가 누락됨

  • 적용 대상/해당되는 경우:

  • 증상:

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

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

    • 저장소 검사 탐색 수행;예를 들면 다음과 같습니다.

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

      저장소를 통해 다른 바이너리(lucene 파일 제외)가 누락되었는지 확인합니다.

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

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

    • 메모:

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

      이 경우 마지막으로 알려진 저장소 올바른 버전으로 복원하여 누락된 모든 바이너리를 복구합니다.

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

  • 적용 대상/해당되는 경우:

  • 증상:

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

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

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

  • 해결 방법:

    • lucene 색인의 로컬 복사본 제거

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

      1. 참조 색인을 다시 인덱싱합니다.
      2. 또한 Adobe 지원 티켓도 파일

다시 색인화하는 방법

속성 인덱스 다시 인덱싱

Lucene 속성 인덱스 다시 색인화

노트

위의 섹션에서는 AEM 컨텍스트에서 Apache Oak 설명서의 Oak 다시 색인 지침을 요약한 다음 프레임을 보여 줍니다.

이진 파일텍스트 사전 추출

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

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

CAN text pre-extraction은 언제 사용됩니까?

이진 추출이 활성화된 기존 lucene 색인을 다시 인덱싱합니다.

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

이진 추출을 사용하는 AEM에 new 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이(가) 실행되고 new CSV 파일이 생성될 때마다 전체 노드 스토어가 탐색됩니다(Oak-run 명령의 경로에 의해 지정됨). CSV 파일은 텍스트 사전 추출 프로세스의 개별 실행 간(단계 1 - 2) 사이에 다시 사용되지 않는 입니다.

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

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

2a. (1b)에서 생성된 CSV 파일에 열거된 이진 노드의 텍스트를 사전 추출하려면 oak-run.jar --tika을 실행합니다.

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

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

사전 추출된 텍스트는 이진 지문으로 CSV에서 식별됩니다. 이진 파일이 동일한 경우 AEM 인스턴스 간에 사전 추출된 동일한 텍스트를 사용할 수 있습니다. AEM 게시는 일반적으로 AEM 작성자의 하위 세트이므로, AEM 작성자의 사전에 추출된 텍스트를 사용하여 AEM 게시도 다시 색인화할 수 있습니다(AEM 게시에 압축을 푼 텍스트 파일에 대한 파일 시스템 액세스 권한이 있다고 가정할 경우).

미리 추출된 텍스트는 시간이 지남에 따라 증분적으로 추가할 수 있습니다. 텍스트 사전 추출은 이전에 추출된 이진 파일에 대한 추출을 건너가게 되므로 이후에 다시 색인화해야 할 경우에 대비하여 사전 추출된 텍스트를 유지하는 것이 좋습니다(추출된 내용이 너무 크지 않다고 가정할 때). 그렇다면 텍스트가 잘 압축되므로 중간에 있는 내용물의 지프를 평가하십시오.

추출된 텍스트 파일에서 전체 텍스트를 소싱, Oak 색인 재색인 지정

이 작업 중에 노드 스토어가 탐색되는 동안 유지 관리/저사용 기간 동안 재인덱싱(3a-b 단계)을 실행함으로써 시스템에 상당한 로드가 발생할 수 있습니다.

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

3b. Apache Jackrabbit Oak DataStore PreExtractedTextProvider OSGi 구성(파일 시스템 경로를 통해 Extracted 텍스트를 가리키도록 구성)은 Oak가 Extraced Files에서 전체 텍스트 소스를 지정하도록 지시하고 저장소에 저장된 데이터를 직접 히트하고 처리하지 않습니다.

이 페이지에서는