쿼리 및 색인 생성에 대한 우수 사례 best-practices-for-queries-and-indexing

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

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

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

쿼리 사용 시기 when-to-use-queries

저장소 및 분류법 디자인 repository-and-taxonomy-design

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

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

또한 분류법을 디자인할 때는 순서 지정 여부가 중요한지 고려해야 합니다. 명확한 순서 지정이 필요하지 않고 대량의 형제 노드가 예상되는 경우에는 sling:Folder 또는 oak:Unstructured와 같은 비순차 노드 유형을 사용하는 것이 바람직합니다. 순서 지정이 필요한 경우에는 nt:unstructured 및 sling:OrderedFolder가 더 적합할 것입니다.

구성 요소에서의 쿼리 queries-in-components

쿼리는 AEM 시스템에서 수행하는 비교적 더 까다로운 작업들 중 하나일 수 있기 때문에 구성 요소에서는 이를 피하는 것이 좋습니다. 페이지가 렌더링될 때마다 여러 쿼리가 실행되도록 할 경우 종종 시스템 성능이 저하될 수 있습니다. 구성 요소를 렌더링할 때 쿼리를 실행하지 않도록 하는 두 가지 전략이 있습니다. 탐색 노드 및 프리페치 결과.

노드 트래버스 traversing-nodes

필요한 데이터의 위치에 대한 사전 정보가 이용 가능하도록 저장소를 디자인한 경우, 쿼리를 통해 이 데이터를 찾을 필요 없이 필요 경로로부터 이 데이터를 가져오는 코드를 배포할 수 있습니다.

예를 들어 특정 카테고리에 부합하는 콘텐츠를 렌더링하는 경우가 있습니다. 한 가지 접근법은 카테고리에서 항목을 표시하는 구성 요소를 채우도록 쿼리할 수 있는 카테고리 속성을 가진 콘텐츠를 구성하는 것입니다.

그보다 나은 접근법은 이 콘텐츠를 카테고리별 분류법에 따라 구성하여 수동으로 가져올 수 있도록 하는 것입니다.

예를 들어 콘텐츠가 다음과 유사한 분류법으로 저장된다고 가정해봅시다.

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

/content/myUnstructuredContent/parentCategory/childCategory 노드를 간편하게 가져올 수 있으며, 그 자식 항목들은 구문 분석되어 구성 요소 렌더링에 사용될 수 있습니다.

또한 작은 크기 또는 같은 형식의 결과 세트를 다룰 때, 동일 결과 세트를 반환하는 쿼리를 만드는 것보다 저장소를 트래버스하고 필요 노드를 모으는 것이 더 빠를 수 있습니다. 일반적인 고려사항은 가능하면 쿼리를 피하는 것입니다.

결과 프리페치 prefetching-results

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

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

데이터나 콘텐츠가 규칙적으로 변경되는 경우에는 일정에 따라 쿼리를 실행하거나 기반 데이터의 업데이트에 대한 리스너를 사용하여 쿼리를 실행할 수 있습니다. 그러면 저장소의 공유 위치에 결과를 작성할 수 있습니다. 이 경우, 런타임 시 쿼리를 실행할 필요 없이 이 데이터를 필요로 하는 모든 구성 요소가 이 단일 노드에서 해당 값을 가져올 수 있습니다.

쿼리 최적화 query-optimization

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

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

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

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

쿼리 설명 도구 the-explain-query-tool

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

쿼리에 대한 디버그 로깅 debug-logging-for-queries

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

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

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

인덱스 통계 index-statistics

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

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

JMX 콘솔에 로그인하고 나면 다음을 검색합니다. Lucene 인덱스 통계 찾기 위해서 다른 인덱스 통계는 IndexStats MBean.

쿼리 통계를 보려면 이름이 인 MBean을 참조하십시오. Oak 쿼리 통계.

와 같은 도구를 사용하여 인덱스를 검색하려면 루크를 채울 때는 Oak 콘솔을 사용하여 색인을 NodeStore 파일 시스템 디렉토리에 추가합니다. 이 작업을 수행하는 방법에 대한 지침은 Lucene 설명서.

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

쿼리 제한 query-limits

개발 중

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

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

배포 후 post-deployment

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

권장되는 값은 입니다.

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

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

효율적인 인덱스를 만드는 팁 tips-for-creating-efficient-indexes

인덱스를 만들어야 합니까? should-i-create-an-index

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

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

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

Lucene 또는 속성 인덱스? lucene-or-property-indexes

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

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

솔루션 색인 지정 solr-indexing

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

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

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

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

디자인 고려 사항 design-considerations

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

CopyOnRead copyonread

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

OSGi 콘솔에서 다음과 같이 구성할 수 있습니다. LuceneIndexProvider Oak 1.0.13부터 서비스 및 가 기본적으로 활성화되어 있습니다.

인덱스 제거 removing-indexes

인덱스를 제거할 때는 항상 type 속성 대상 disabled 및 를 테스트하여 실제로 삭제하기 전에 애플리케이션이 올바르게 작동하는지 확인합니다. 색인은 비활성화된 상태에서 업데이트되지 않으므로 다시 활성화한 경우 올바른 컨텐츠가 없을 수 있으며 다시 색인화해야 할 수도 있습니다.

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

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

색인 재지정 re-indexing

이 섹션에서는 전용 Oak 색인을 다시 색인화하는 데 적합한 이유입니다.

아래에 요약된 이유 외에 Oak 인덱스의 재색인을 시작하면 not 동작을 변경하거나 문제를 해결하고 AEM의 로드를 일시적으로 늘립니다.

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

Oak 색인 구성 변경 사항 oak-index-configuration-changes

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

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

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

속성 인덱스 정의 변경 property-index-definition-change

Lucene 인덱스 정의 변경 lucene-index-definition-change

예외 및 예외 상황 erring-and-exceptional-situations

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

AEM에서 아래에 설명된 기준과 일치하지 않는 문제가 발생하는 경우 다음을 수행하십시오. not 문제가 해결되지 않으므로 모든 인덱스를 다시 색인화합니다.

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

Lucene 인덱스 바이너리가 없습니다. lucene-index-binary-is-missing

Lucene 인덱스 바이너리가 손상되었습니다. lucene-index-binary-is-corrupt

다시 색인화하는 방법 how-to-re-index

속성 인덱스 다시 인덱싱 re-indexing-property-indexes

Lucene 속성 인덱스 다시 인덱싱 re-indexing-lucene-property-indexes

바이너리 사전 추출 텍스트 text-pre-extraction-of-binaries

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

언제 텍스트 사전 추출을 사용할 수 있습니까? when-can-text-pre-extraction-be-used

색인 재지정 기존 이진 추출이 활성화된 lucene 인덱스

의 배포 지원 새 이진 추출이 활성화된 AEM의 lucene 색인

언제 텍스트 사전 추출을 사용할 수 있습니까? when-can-text-pre-extraction-not-be-used

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

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

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

텍스트 사전 추출 사용을 위한 사전 요구 사항 prerequisites-to-using-text-pre-extraction

텍스트 사전 추출을 수행하는 방법 how-to-perform-text-pre-extraction

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

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

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

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

전체 노드 저장소는 oak-run 명령의 경로에 지정된 대로 항상 트래버스됩니다 --generate 가 실행되면 새 CSV 파일이 생성됩니다. CSV 파일은 다음과 같습니다 not 텍스트 사전 추출 프로세스의 개별 실행 간에 다시 사용됩니다(단계 1 - 2).

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

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

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

2b. (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에게 추출된 파일에서 전체 텍스트 텍스트를 소스에 전달하도록 지시하고 저장소에 저장된 데이터를 직접 히트하고 처리하지 않도록 합니다.