우리는 이미 몇 가지 모범 사례에 대해 살펴봤습니다. 파트1의 FTS 인덱스에서 인덱스의 운영 및 유지 관리 측면에 대한 몇 가지 유용한 팁을 살펴봤습니다.
처음 사용하는 사용자 정보 검색(IR) 도메인의 경우, 특히 인덱스에 대한 텍스트 분석 파이프라인을 구성할 때 FTS 인덱스 정의 프로세스가 다소 지루하다고 느낄 수 있습니다. 문자 필터, 토큰 생성기, 약어와 같은 IR 전문 용어로 인한 정보 과부하에 압도당할 수도 있습니다. 엄프틴 토큰 필터 슁글, 엔그램, 엣지_엔그램 등과 같이. 사용자 지정 텍스트 분석기를 구성하기 시작하면 이러한 선택의 폭은 무궁무진합니다. 사용자 정의/내장 분석기로 인덱스를 정의한 후에는 앞서 언급한 모든 내재적 복잡성으로 인해 구성된 분석기의 출력을 예측하고 검증하는 작업이 점점 더 번거로워집니다.
이제 텍스트 분석 결과에 대한 자세한 인사이트가 왜 중요할까요?
대부분의 검색 사용자가 전체 텍스트 검색 시스템을 처음 시도할 때 다음과 같은 질문에 부딪히기 때문에 이 질문은 매우 중요합니다,
Qn. 가이드라인에 따라 색인을 정의했고 문서에 검색 토큰이 존재한다는 것을 알고 있는데도 검색이 조회수를 반환하지 않는 이유는 무엇인가요?
이는 주로 다음과 같은 이유로 발생합니다,
- 인덱스 정의에 구성된 분석기의 결함으로 인해 데이터를 토큰화하거나 큐레이팅할 때 예상과 달리 토큰이 생성되거나 시스템에서 인덱싱되는 경우, 즉 분석기에서 생성된 토큰이 예상과 다른 토큰이 생성되는 경우입니다.
- 인덱스 정의의 필드 매핑에 따라 정의된 것과는 다른 분석기를 검색하는 동안 자신도 모르게 다른 분석기를 선택했습니다.
문서 텍스트는 색인에 기록될 때 분석되며, 이와 별도로 검색을 수행할 때 검색어도 분석됩니다. 일반적으로 기본적으로 필드 범위 쿼리인 경우 인덱스 정의에 지정된 필드 분석기가 쿼리 내용을 분석하는 데 선택됩니다.
인덱스 분석 파이프라인을 쉽게 이해하고 수정하는 데 도움을 주기 위해 FTS는 6.5.0 릴리스에서 휴식 엔드포인트를 도입했습니다, /api/index/{indexName}/analyzeDoc 는 요청 본문에서 json 문서를 수락하고 주어진 인덱스로 구성된 분석기에 따라 분석된 토큰이 포함된 json 응답을 반환합니다.
이 엔드포인트를 사용하여 개발 또는 스테이징 환경에 대해 분석기 출력을 탐색하고 디버깅할 수 있습니다. 이 엔드포인트는 프로덕션 시스템에서 시도해도 안전합니다. 응답은 말 그대로 유사한 문서를 색인했다면 색인의 일부로 색인되었을 토큰을 보여줍니다. 인덱스 유형 매핑에 정의된 대로 문서 유형이 일치하는 json 문서로 쿼리 텍스트와 함께 쿼리 필드만 전달하여 쿼리 분석 출력을 확인하는 데 동일한 엔드포인트를 사용할 수 있습니다.
인덱스와 쿼리 시간 사이의 분석기 불일치를 수정하려면 필드 범위 쿼리를 사용하거나 많은 쿼리에서 이에 대한 옵션을 제공하므로 쿼리 시간 동안 분석기를 재정의할 수 있습니다.
Qn. FTS 클러스터의 크기가 올바른지 어떻게 알 수 있나요?프로비저닝되지 않은 클러스터를 감지하기 위한 ignpost를 사용하시나요?
클러스터 크기 조정은 일반적으로 올바른 클러스터 토폴로지와 함께 RAM/FTS 메모리 할당량, CPU 처리 능력과 같은 충분한 시스템 리소스를 구성하는 것으로 구성됩니다. 클러스터 토폴로지는 또한 주어진 데이터 볼륨과 쿼리/색인 부하에 적합한 파티션 수와 노드 수로 구성됩니다. 많은 고객들이 크기 조정 가이드라인을 따르지 않고 크기가 작은 클러스터를 사용하는 것을 보았습니다. 크기 조정은 각 고객 사용 사례에 따라 매우 구체적인 주제이므로 여기서는 자세히 다루지 않겠습니다. 사용자는 각 요구 사항에 맞는 맞춤형 크기 조정 가이드라인에 대한 도움을 받기 위해 Couchbase 팀에 문의하는 것이 좋습니다.
그러나 클러스터가 프로비저닝 중임을 암시하는 몇 가지 간단한 지표가 이미 시스템에 내장되어 있습니다.
- 쿼리 부하나 지속적인 문서 변경이 없는 경우에도 인덱싱 진행 속도가 매우 느립니다.
- 검색 쿼리가 http 상태 코드 429로 거부되고 있습니다. 이는 시스템의 FTS 메모리 할당량이 부족하다는 것을 나타냅니다.
- 통계 그래프에서 느린 쿼리가 많다는 것은 검색 쿼리 크기 조정이 잘못되었거나 검색 쿼리가 최적화되지 않았음을 암시할 수 있습니다.
여기서 최적이 아닌 쿼리는 올바른 검색 절을 사용하여 최상의 결과를 얻기 위해 신중하게 작성되지 않은 쿼리를 말합니다. 간혹 250개 이상의 하위 쿼리가 포함된 복잡한 복합 쿼리를 시도하는 고객을 본 적이 있습니다. 여기에 숨어 있는 가장 큰 비효율성은 검색 시스템이 인덱스의 작은 표면적을 훑어보기만 해도 동일한 결과를 얻을 수 있는 더 나은 타깃 쿼리에 비해 올바른 결과를 가져오기 위해 대량의 색인된 데이터(대부분 디스크에서)를 스캔해야 한다는 점입니다. 그 결과 시스템 리소스를 훨씬 더 효율적으로 사용할 수 있습니다.
