전체 텍스트 검색 - 쿼리 성능을 향상시키는 5가지 팁

검색 쿼리 성능을 조정하는 것은 매우 중요한 측면입니다. 전체 텍스트 검색 비즈니스 크리티컬 애플리케이션이 지연 시간 및 처리량이라는 SLA 요구 사항을 충족하는 데 도움이 되기 때문입니다. 자세한 설명 없이 검색 성능 문제 해결을 위한 몇 가지 유용한 권장 사항을 공유하겠습니다. 이 모든 제안은 하드웨어 구성, 클러스터 토폴로지에 구애받지 않으며 대부분의 일반적인 검색 사용 사례에 적용할 수 있습니다.

가능한 한 적은 수의 필드 검색

이는 특히 다음과 같은 특정 유형에 적용됩니다. 복합 쿼리 사용자가 인덱싱된 여러 필드에서 공통 검색어 텍스트를 검색하려고 하는 경우입니다.

샘플 쿼리를 자세히 살펴보겠습니다.

접속 복합 쿼리에는 4개의 일치 쿼리 절이 있으며 모두 동일한 검색 텍스트를 가지고 있습니다. 이는 매우 비효율적인데, 백그라운드에서 검색 시스템이 동일한 검색 텍스트에 대해 여러 필드에 걸쳐 색인된 많은 데이터를 탐색해야 하기 때문입니다. 이러한 오버헤드는 여러 필드에 걸쳐 생성되는 수많은 런타임 쿼리 구조와 가비지 수집으로 인해 더욱 악화됩니다.

FTS에는 매우 효율적인 방식으로 이를 지원하는 기능이 있습니다. 이 기능을 통해 사용자는 구성 가능한 일반 필드에 대해 여러 소스 문서 필드를 색인할 수 있습니다. 사용자가 색인 정의 시간 동안 이 작업을 수행하면 단일 공통 필드에 대해 검색을 실행할 수 있습니다.

이 기능을 이용하려면 사용자는 다음을 수행해야 합니다. 활성화 _all 옵션을 인덱싱하는 동안 필드 매핑의 모든 여러 필드에 대해 사용할 수 있습니다.

이렇게 하면 이러한 모든 필드 콘텐츠도 기본값에 대해 색인화됩니다. _all 필드를 추가합니다. 여기에는 인덱스 크기에 대한 추가 저장 공간이 있습니다.

이제 사용자는 대상 필드를 명시적으로 지정하지 않고도 쿼리를 실행할 수 있습니다. 또한 쿼리에 대상 필드가 지정되지 않은 경우, 전체 텍스트 검색은 기본 공통 필드를 기준으로 검색합니다. _all. 

따라서 위의 최적화를 통해 이전 쿼리는 아래와 같이 더 간단한 쿼리가 될 것입니다,

이 검색 쿼리 성능은 원래 쿼리에 비해 훨씬 더 가볍고 빨라야 합니다.

참고: 다음과 같은 경우에 해당됩니다. 점수 부스팅 하위 절에 대한 원래 쿼리에 사용되었습니다.

지정 접두사_길이 퍼지 매치 쿼리의 경우 

사용자가 퍼지 선택 쿼리 일치 를 사용하여 검색 텍스트 내의 잠재적인 철자 오류를 방지할 수 있습니다. 퍼지 인자를 사용하면 검색 시스템에서 의도한 문서를 찾을 수 있습니다. 하지만 퍼지 사용자는 퍼지 쿼리가 리소스를 매우 많이 소모하는 쿼리라는 점을 염두에 두어야 합니다.

방법 - 충분히 큰 FTS 인덱스에서는 쿼리 텍스트에서 주어진 퍼지/편집 거리에 있는 많은 후보 토큰이 있을 것입니다. 따라서 기본적으로 하나의 퍼지 쿼리는 인덱스에 존재하는 모든 후보 토큰에 대해 분리/또는 쿼리가 됩니다. 그 결과 초보적인 검색 작업에서 내부 팬이 많이 발생하고 리소스가 많이 소모됩니다.

여기에서 쿼리 팬아웃에 대한 간단한 예를 확인해 보겠습니다.

쿼리 텍스트 'plan'에 대해 퍼지 값이 1인 일치 퍼지 쿼리를 사용하면 이 예에서와 같이 총 6개의 용어가 아래에 검색됩니다. (색인된 콘텐츠에는 요청된 편집 거리 또는 퍼지 1에 해당하는 5개 용어만 존재한다는 가정 하에).

잠재적인 맞춤법 오류를 방지하면서 한 가지 중요한 최적화 아이디어는 대부분의 맞춤법 오류는 텍스트의 시작 부분이 아닌 끝 부분에서 발생한다는 점입니다. 사용자는 이 사실을 활용하고 접두사_길이 옵션을 사용하세요. 일단 접두사_길이 가 주어지면, 퍼지는 주어진 텍스트에 대해서만 고려됩니다. 접두사_길이.

일반적으로 접두사_길이 의 2 또는 3이 좋아야 합니다. 하지만 이는 애플리케이션 또는 사용 사례에 따라 다릅니다.

예시:

이렇게 하면 주어진 퍼지 쿼리에 대해 인덱스에서 검색되는 토큰의 범위/개수가 크게 줄어듭니다. 그리고 검색 쿼리 성능을 크게 향상시키기 위해 prefix_length 를 입력하세요.                     

텍스트 관련성이 중요하지 않은 경우 채점 건너뛰기

많은 경우 사용자가 약간 흐릿하거나 다음과 같은 기타 검색 특정 기능이 있는 일치 검색 쿼리에 전체 텍스트 검색을 사용하는 것으로 관찰됩니다. geo. 텍스트 연관성 점수는 사용자가 정확하거나 많은 술어가 포함된 타겟팅된 검색을 찾고 있을 때는 중요하지 않습니다. 

사용자가 기본값에 관심이 없는 비슷한 상황의 경우 TF-IDF 점수'를 전달하면 채점을 건너뛰어 쿼리 성능을 최적화할 수 있습니다. 사용자는 검색 요청에 "점수"를 전달하여 채점을 건너뛸 수 있습니다: "없음" 옵션을 전달하여 채점을 건너뛸 수 있습니다. 

예시: 

이렇게 하면 많은 경우, 특히 하위 검색 절이 많은 복합 쿼리의 경우 검색 쿼리 성능이 크게 향상됩니다.

이 기능은 Couchbase 서버 릴리스 6.6.1부터 사용할 수 있습니다.

더 깊은 페이지 검색을 위한 키 설정 페이지 매김

아시다시피 검색 결과의 페이지 매김은 다음을 사용하여 수행할 수 있습니다. 에서 그리고 크기 매개변수를 사용할 수 있습니다. 하지만 검색이 더 깊은 페이지로 들어가면 리소스를 많이 소모하게 됩니다. 가장 큰 이유는 검색 결과가 기본값으로 정렬되기 때문입니다. TF-IDF 점수와 전체 텍스트 검색에는 요청된 페이지의 오프셋과 크기에 비례하는 힙 메모리 요구 사항이 있습니다. 부터+크기 이 순위를 유지해 주셔서 감사합니다. 

임의의 높은 메모리 요구 사항으로부터 보호하기 위해 설정 가능한 제한이 있습니다. bleveMaxResultWindow (기본값 10000)을 최대 허용 페이지 오프셋으로 설정합니다. 하지만 이 제한을 더 높은 수준으로 높이는 것은 확장 가능한 해결책이 아닙니다.

이 문제를 피하기 위해 FTS에 키 세트 페이지 매김이라는 개념을 도입했습니다. 

제공하는 대신 에서 를 건너뛸 검색 결과의 수로 입력하면 사용자는 이전에 본 검색 결과의 정렬 값(일반적으로 현재 페이지에 표시된 마지막 결과)을 제공합니다. 다음 페이지의 결과를 표시하려면 이전 페이지의 마지막 결과 다음에 해당 정렬의 상위 N개의 결과만 표시해야 한다는 것입니다.

이 솔루션을 사용하려면 몇 가지 전제 조건이 충족되어야 합니다:

• 검색 요청은 정렬 순서를 지정해야 합니다.
• 정렬 순서는 결과에 전체 순서를 적용해야 합니다. 그렇지 않으면 페이지 탐색 경계를 처리할 때 동일한 정렬 값을 공유하는 모든 결과가 누락될 수 있습니다. 이에 대한 일반적인 해결책은 항상 문서 ID를 최종 정렬 기준으로 포함하는 것입니다.                                                                      예를 들어 ["이름", "-연령"]을 기준으로 정렬하는 대신 ["이름", "-연령", "_id"]를 기준으로 정렬하려는 경우입니다.

예시:

사용자가 검색하는 항목 설명:빛 기준으로 정렬합니다. ["name", "_id"]

유사한 매개 변수가 있습니다. search_before 을 클릭하여 이전 결과 페이지로 이동합니다. 애플리케이션은 마지막 결과의 정렬 값을 제공하는 대신 현재 페이지의 첫 번째 결과의 정렬 값을 제공합니다. 다른 모든 방식에서는 동일하게 작동합니다.

search_after/search_before 페이지 매김을 사용하면 더 깊은 페이지 검색의 힙 메모리 요구량이 요청된 페이지 크기에만 비례하게 됩니다. 따라서 더 깊은 페이지 검색의 힙 메모리 요구량이 오프셋+프롬 값보다 크게 줄어듭니다.

이 기능은 Couchbase 서버 릴리스 6.6.1부터 사용할 수 있습니다.

복합 쿼리에서 중복 검색 절 피하기

이것이 순진한 제안처럼 들릴 수도 있습니다. 그러나 최종 사용자 검색 쿼리를 FTS 백엔드 검색 요청으로 변환하는 동안 고객 애플리케이션에서 복합 쿼리에 중복된 하위 검색 절이 많이 발생하는 경우가 종종 관찰됩니다.  

예시:

이렇게 하면 쿼리 내용이 중복되어 전체 텍스트 검색 서버 백엔드에서 많은 중복 작업이 발생하게 됩니다.

사용자는 검색 서비스가 주어진 쿼리의 중복 제거를 수행하지 않는다는 점에 유의해야 합니다. 백엔드에서 전체 쿼리 요청을 존중하고 실행합니다. 따라서 사용자는 검색 서비스를 이용하기 전에 최적의 쿼리가 형성되었는지 면밀히 검토해야 합니다.

이 공간에서 전체 텍스트 검색 서비스의 검색 쿼리 성능 튜닝 및 색인 관리 팁을 더 자세히 알아보세요.

FTS 초보자를 위한 텍스트 분석에 대한 또 다른 흥미로운 읽기 여기 

전체 텍스트 검색 엔진 내 텍스트 분석