더 민첩하고 세련된 scorch 인덱싱 포맷이 Couchbase 6.0.0에 출시된 이후, FTS 팀은 새로운 인덱싱 체계가 열어줄 미래의 최적화 잠재력에 대해 매우 기대하고 있습니다. 6.5.0 릴리스와 함께, 우리는 전체 텍스트 검색 엔진의 성능을 최적화하고 조정하는 끝없는 여정을 시작하게 되었습니다.
곧 출시될 6.5.0 버전에 도입되는 흥미로운 최적화 기능에 대해 몇 가지 소개해드리겠습니다.
지리적 쿼리
FTS는 두 가지 유형의 지리적 쿼리를 지원합니다. 점 거리 및 경계 사각형. 이 기능이 처음 도입된 이래로 이 기능을 수정하고 개선할 기회가 없었지만, 쿼리 구현에 메모리와 CPU 사용률 측면에서 개선이 필요하다는 것은 거의 확실했습니다. 좋은 소식은 6.5.0의 모든 성능 개선 사항 중에서 지역 변경으로 가장 큰 개선이 이루어졌다는 것입니다.
기회
지리적 쿼리의 높은 메모리 사용량을 분석하는 과정에서 아직 개발되지 않은 엄청난 성능 튜닝 잠재력이 있다는 것이 분명해졌습니다. 점 거리와 경계 사각형 쿼리 유형 모두에서 인덱싱 엔진(bleve)는 주어진 쿼리 매개변수에서 검색 기준을 충족하는 검색할 지리적 위치의 범위(후보 용어)를 파악해야 합니다. Bleve는 특정 수학적 단계를 통해 이러한 후보 지역 용어를 도출합니다.
하지만 수학적으로 생성된 후보 지역 용어에 대한 필터링은 전혀 수행되지 않았습니다. 즉, 백그라운드에서 의도하지 않은 검색 공간의 증폭이 일어나고 있었던 것입니다. 그리고 이로 인해 불필요하거나 관련 없는 용어 검색 반복자(예: 색인에 존재하지도 않는 용어)가 너무 많이 생성되어 관리해야 할 내부 임시 객체가 많아지고 가비지 컬렉터에 큰 오버헤드가 추가되었습니다.
응답
이 경우, 기본적으로 수학적으로 생성된 지리적 포인트가 용어 사전에 존재하는지 검증하고 용어 사전에 존재하는 경우에만 자격을 부여하는 지리적 용어 필터링을 적용하여 최적화했습니다. 이 접근 방식은 반전된 인덱스에 대해 검색되는 후보 지리적 위치/용어의 수를 크게 줄였고, 따라서 지리적 쿼리의 지연 시간과 처리량 수치를 모두 개선했습니다.
보상
이를 통해 최대 6X 내부 벤치마크에서 지리적 쿼리에 대한 지연 시간 감소를 확인했습니다.
퍼지 쿼리
사전 scorch 일 동안 퍼지/편집 거리 쿼리가 수신되면 색인 엔진은 쿼리에서 주어진 필드에 대해 색인된 모든 용어를 검토하여 편집 거리를 계산하여 현재 용어가 쿼리 용어와 요청된 편집 거리 내에 있는지 여부를 파악합니다. 그리고 해당 편집 거리 기준을 충족하는 경우, 역 인덱스에서 해당 용어를 조회하여 해당 용어가 나타나는 문서 목록과 쿼리에서 지정한 대로 필요한 세부 정보를 가져옵니다. (용어 벡터, 문서 값 등)
최근의 스코치 인덱싱 포맷은 FiniteStateTransducers(FST)를 사용하여 용어 사전을 구현할 수 있습니다. DFA 속성. 이를 통해 쿼리에서 주어진 편집 거리 내에서 후보 용어를 찾는 초보자의 접근 방식을 개선하는 데 도움이 되었습니다.
접근 방식은 L에븐슈테인 Automaton(LA)를 편집 거리 쿼리에서 주어진 용어에 대해 반환합니다. 이 LA는 쿼리에서 주어진 "d"의 편집 거리에 있는 모든 용어를 일치시키는 속성을 가진 DFA입니다. 그리고 이 LA DFA는 쿼리의 일부로 최종적으로 검색해야 하는 후보 용어를 필터링하기 위해 원래 색인된 용어집/용어 사전(FST DFA)과 함께 단계적으로 또는 교차하도록 만들어집니다.
기회
6.0 릴리스까지는 들어오는 쿼리마다 LA DFA를 새로 만들었는데, 이 LA DFA 구축 부분이 메모리 사용량과 DFA 구축 속도 측면에서 부담이 되는 것으로 나타났습니다.
응답
원작에서 영감을 받아 종이 블로그 게시물 - 레벤슈타인와 달리, 최신 레벤슈타인 오토마톤 구조는 2단계 접근 방식을 취합니다. 첫 번째 단계에서는 사전 정의된* 편집 거리 집합에 대한 파라메트릭 DFA를 미리 계산하며, 이 부분은 쿼리 문자열과 완전히 독립적이므로 미리 계산할 수 있습니다. 두 번째 단계에서는 이 파라메트릭 DFA를 사용하여 쿼리별 LA DFA를 계산합니다. 따라서 DFA 구성이 매우 빠르고 메모리 친화적입니다.
보상
Go 마이크로 벤치마크에 따르면 최신 구현은 다음과 같습니다. 5X 더 빠르고 12X 메모리 사용량이 개선되었습니다. 그리고 내부 성능 테스트에서 다음과 같은 결과를 얻었습니다. ~50% 쿼리 처리량 개선.
여기까지 스크롤해 주셔서 감사합니다.
여러분의 집중력을 높이기 위해 여기서 잠시 멈추고 나머지 이야기는 2부에서 다루도록 하겠습니다. 다음 파트에서는 숫자 범위, 접두사, 와일드카드 등과 같은 쿼리뿐만 아니라 FTS에 gRPC를 도입했을 때 얻을 수 있는 성능 향상에 대해 다룰 것입니다.
… 파트 2
{사전 정의된* 편집 거리 => 현재 FTS는 최대 2까지 편집 거리를 지원합니다. 즉, 1과 2만 지원합니다.
그 주된 이유는 적당한 크기의 문서 말뭉치에는 쿼리 용어와 편집 거리가 2를 초과하는 용어가 너무 많기 때문입니다. 따라서 더 이상의 인덱스 조회는 검색 관련성이 떨어지고 리소스를 매우 많이 사용하게 됩니다.}
