전체 텍스트 검색 프로덕션 시스템을 위한 7가지 유용한 팁

생성하기 오른쪽 검색 색인 의 원활한 작동을 위해서는 다양한 구성을 조정하는 것이 매우 중요합니다. 전체 텍스트 검색 생산 시스템. 이러한 운영 측면은 검색 시스템의 색인 및 쿼리 성능을 개선하는 데 중요한 역할을 합니다. 모든 검색 서비스 사용자가 아래의 인덱스 관리 개념을 숙지하고 클러스터에서 현명하게 사용하시기를 권장합니다. 더 아래로 스크롤하여 메모리 할당량, 인덱스 파티션, 복제본, 별칭, 장애 복구 재조정과 같은 몇 가지 효과적인 검색 서비스 운영 팁을 살펴볼 수 있습니다.

1. 충분한 메모리 할당량 프로비저닝 

검색 서비스의 기본 메모리 할당량은 512MB이며, 이는 프로덕션 규모의 검색 시스템을 지원하기에는 충분하지 않습니다. 따라서 클러스터 크기 조정의 일부로 검색 RAM 할당량을 보다 의미 있는 값으로 수정하는 것이 좋습니다.

검색 서비스는 인덱스에 대한 최소 메모리 상주 비율을 강제하지 않습니다. 하지만 사용자는 인덱스의 적절한 상주 비율을 위해 충분한 검색 메모리 할당량을 확보하는 것이 좋습니다. 이렇게 하면 시스템에서 인덱싱, 쿼리 또는 리밸런싱 등과 같은 기타 수명 주기 작업을 수행하기에 충분한 메모리를 확보할 수 있습니다.

다음은 몇 가지 사항입니다. 증상 검색 클러스터의 메모리 할당량이 부족한 경우,

• 서버의 HTTP 429 오류 코드로 인해 쿼리가 거부되었습니다.

이 속도 제한은 검색 서비스에 대해 구성된 메모리 할당량을 준수하기 위해 적용됩니다. 설정된 메모리 할당량을 초과하지 않고 쿼리를 처리할 수 있는 메모리가 충분하지 않은 경우 들어오는 쿼리를 거부합니다. 인덱스 모니터링 페이지에서 쿼리 오류율이 증가하는 것을 확인할 수 있습니다.

• 시스템에서 느린 쿼리 수가 증가하고 있습니다.

시스템의 운영 메모리 부족으로 인해 느린 쿼리가 급증할 수도 있습니다.

• 쿼리의 평균 지연 시간이 증가합니다.

시스템의 운영 메모리 부족으로 인해 쿼리 지연 시간이 점진적으로 증가할 수도 있습니다. 

위의 모든 쿼리 통계는 Couchbase 서버의 기본 제공 인덱스 통계 페이지에서 모니터링할 수 있습니다. 

2. 파일 시스템 캐시를 위한 충분한 메모리를 확보합니다.

검색 메모리 할당량을 구성할 때 또 다른 주요 측면은 운영 체제에서 관리할 수 있도록 충분한 여유 RAM을 남겨두는 것입니다. 파일 시스템 캐시. 내부적으로는 Search의 내부 텍스트 인덱싱 라이브러리(bleve) 사용 메모리 매핑 를 사용할 수 있습니다. 따라서 운영 체제를 위해 충분한 RAM을 확보하면 파일 시스템 캐시 메모리에 인덱스 파일의 핫 영역을 유지하는 데 도움이 됩니다. 이는 검색 성능 향상에 도움이 됩니다.

일반적인 가이드라인은 검색 메모리 할당량을 검색 노드에서 사용 가능한 RAM의 60-70%로 설정하는 것입니다.

최적의 검색 성능을 위해서는 시스템에 충분한 RAM 메모리를 구성하고 검색 할당량 메모리를 충분히 할당하는 것이 필수적입니다.

증상 - 인덱싱 또는 쿼리 프로세스 중에 검색 서비스가 반복적으로 OS에 의해 OOM 종료되는 것은 시스템의 RAM 메모리 부족을 암시할 수도 있습니다.

3. 검색 노드를 통한 서비스 멀티테넌시 방지

단일 노드에서 여러 서비스를 호스팅하면 서비스 간에 리소스 경합이 발생할 위험이 있습니다. 모든 서비스에 리소스 할당량을 설정해도 이를 완전히 방지할 수는 없습니다. 

예를 들어 검색 서비스는 더 나은 메모리 매핑 성능을 위해 구성된 메모리 할당량을 초과하여 사용 가능한 RAM 메모리에 크게 의존합니다. 그러나 동일한 노드에서 실행 중인 다른 서비스가 이러한 사용 가능한 RAM을 소모하여 의도치 않게 검색 성능에 영향을 줄 수 있습니다. CPU 코어도 마찬가지입니다.

단일 서비스 호스팅 노드를 사용하면 성능 문제나 검색 시스템의 초기 사이징을 디버깅하고 해결하는 것이 훨씬 쉬워집니다. 

따라서 사용자는 초기 배포 기간 동안 최소한 단일 서비스 검색 노드로 시작하는 것이 좋습니다.

4. 인덱스 토폴로지 고려 사항

• 인덱스 파티션 수

인덱싱되는 데이터의 양에 따라 인덱스 파티션의 수와 노드/CPU 코어 간의 분포를 조정하여 서비스 성능을 최적화합니다. 

파티션이 너무 많으면 분산 수집 비용이 증가하고, 파티션이 너무 적으면 검색 병렬화가 제한됩니다. 

모든 사용 사례에 맞는 일반적인 사전 정의된 인덱스 파티션 수는 없습니다. 사용자는 각 사용 사례 SLA에 대해 이를 경험적으로 탐색해야 합니다.

사용자가 보유한 데이터가 수백만 개에 불과하다면 기본 파티션 수인 6개를 1 또는 2와 같은 작은 값으로 재정의하는 것이 좋습니다.

인덱스 파티션 수와 관련하여 염두에 두어야 할 몇 가지 중요한 사항은 다음과 같습니다,

• 클러스터 규모에 따라 사용 가능한 노드에 인덱싱 및 쿼리 워크로드를 보다 효율적으로 할당할 수 있도록 도와줍니다.
• 여러 노드에서 상대적으로 작은 파티션을 사용하면 리밸런싱 작업을 더 빠르게 수행할 수 있습니다.
• 파티션은 CPU 코어 활용도를 높이는 데 도움이 됩니다.
• 색인되는 데이터의 양에 따라 파티션 수를 조정하여 파티션이 너무 크지 않도록 하는 것이 좋습니다. 

• 복제본 수

복제본은 검색 서비스에서 고가용성을 위한 목적으로만 사용됩니다. 오늘. 따라서 어떤 이유로든 노드가 다운될 때마다 사용자는 결함이 있는 노드에 대한 장애 조치 리밸런싱을 수행할 수 있습니다. 이렇게 하면 복제 파티션의 라이브 트래픽이 즉시 제공되고 최종 사용자에게 서비스가 원활하게 유지됩니다.

복제본 번호는 인덱스 생성 시간 동안 사용자가 명시적으로 구성해야 합니다. 

기본적으로 검색 서비스는 파티션 복제본을 사용하도록 설정하지 않습니다. 인덱스 생성.

사용자는 고가용성 요구 사항에 따라 복제본 개수를 1개 이상으로 구성하는 것이 좋습니다.

• 장애 조치 및 복구

사용자가 하드웨어 또는 소프트웨어 유지 관리 작업을 위해 클러스터에서 노드를 일시적으로 제거해야 하는 경우, 노드 장애 조치를 시도할 수 있습니다. 검색 노드가 장애 조치되는 동안 노드에 있는 모든 인덱스 파티션 데이터는 보존됩니다.

유지 관리 작업이 끝나면 "복구" 옵션을 사용하여 클러스터에 다시 추가할 수 있습니다. 여기서 동일한 노드를 복구하기 때문에 검색 서비스는 복구된 노드에 있는 기존의 모든 인덱스 파티션 데이터를 재사용할 수 있습니다. 이렇게 하면 노드 복구 작업이 매우 빨라집니다.

복제 파티션을 사용하면 검색 서비스는 서비스 중단 시간 없이 유지 관리를 위해 노드를 페일오버하고 복구할 수 있어야 합니다.

5. 업데이트 사용량이 많은 사용 사례에 대한 병합 정책 강화

검색 인덱스는 일반적으로 세그먼트라고 하는 여러 개의 인덱스 파일로 구성됩니다. 이러한 세그먼트는 데이터 소스/버킷에서 발생하는 문서 변경(삽입/업데이트/삭제)에 의해 생성됩니다. 검색 요청을 처리하는 동안, FTS는 이 모든 세그먼트를 순차적으로 검색해야 합니다. 따라서 세그먼트 수가 많을수록 인덱스 검색 작업 속도가 느려집니다.

인덱스 스토리지 계층에서는 백그라운드 병합 프로세스가 이러한 작은 디스크 세그먼트 파일을 안정적인 큰 세그먼트 집합으로 계속 병합합니다. 이 병합 동작은 인덱스 정의에 대해 지정할 수 있는 병합 정책에 의해 제어됩니다. 지나치게 공격적인 병합은 인덱스의 수명 주기 또는 쿼리 작업의 다른 경쟁 스레드에서 더 많은 리소스(디스크 및 CPU)를 훔칠 수 있습니다. 따라서 기본 병합 정책은 다양한 사용 사례에서 작동할 수 있도록 충분히 일반적일 수 있도록 유지했습니다.

기본 병합 정책은 특정 순간에 아래와 같이 세그먼트 크기가 커지는 로그 계단 패턴을 따르는 인덱스 세그먼트 무리를 생성하려고 시도합니다.

그러나 병합 정책을 재정의하는 것이 더 확인해야 하는 상황이 있을 수 있으므로 이를 살펴보겠습니다.

• 업데이트/삭제가 많은 워크로드로 디스크 공간을 더 빠르게 확보할 수 있습니다.

FTS에는 "추가 전용" 스토리지에 저장되어 업데이트/삭제 작업 시 기존 세그먼트의 문서 항목이 삭제/사용되지 않는 것으로 표시됩니다. 디스크 공간의 실제 방출은 동시 병합 주기 동안 이러한 세그먼트가 병합/압축될 때만 발생합니다. FTS의 기본 병합 정책은 디스크 IO와 CPU를 최적화하기 위해 큰 세그먼트보다 작은 세그먼트의 병합을 선호합니다. 이렇게 하면 더 큰 세그먼트가 병합 작업에 자주 선택되지 않기 때문에 더 큰 세그먼트에 속한 업데이트/톰스톤된 문서의 디스크 공간을 회수하는 데 오랜 대기 시간이 걸릴 수 있습니다.

인스턴트에서 회수 가능한 디스크 공간의 양은 다음과 같은 통계를 통해 사용자에게 노출됩니다. NUM_BYTE_USED_DISK_BY_ROOT_RECLAIMABLE.

사용자가 위의 통계에 대해 지속적으로 유의미한 값을 보게 되면 인덱스에 대해 더 엄격한 압축 정책이 필요하다는 것을 나타냅니다. 병합 구성 노브에는 압축/병합 프로세스 중에 더 오래되거나 삭제된 콘텐츠가 더 많은 세그먼트를 선택하는 데 유리하도록 하는 조항도 있습니다.

• 읽기가 많은 워크로드에 대한 검색 성능이 향상됩니다.

우리는 이미 모든 검색 요청이 인덱스 내의 각 세그먼트 파일을 참조한 후에 제공된다는 것을 알고 있습니다. 따라서 세그먼트 파일 수가 많을수록 검색을 제공하는 데 드는 오버헤드가 더 커집니다. 

세그먼트 수가 적을수록 검색 성능을 개선하는 데 도움이 됩니다. 따라서 가능하면 세그먼트 파일 수를 줄이는 것이 좋습니다. (사용량이 적은 시간대)

인덱스 정의를 사용하여 압축 정책을 재정의할 수 있습니다. 나머지 엔드포인트 업데이트. 제발 문의하기 인덱스에 대한 기본 압축 정책을 재정의하는 방법에 대한 자세한 내용을 참조하세요.

6. 인덱스 별칭 사용

An 인덱스 별칭 는 하나 이상의 전체 텍스트 인덱스 또는 추가 별칭을 가리키며, 따라서 그 목적은 파일 시스템의 심볼릭 링크와 어느 정도 비슷합니다. 인덱스 별칭에 대한 쿼리는 모든 최종 대상에 대해 수행되며 병합된 결과가 제공됩니다.

인덱스 별칭을 사용하면 다음을 허용합니다. 지시 를 사용하여 애플리케이션이 변경되지 않는 별칭 이름을 참조하므로, 관리자는 별칭이 가리키는 실제 인덱스의 신원을 주기적으로 자유롭게 변경할 수 있습니다. 이 기능은 인덱스를 업데이트해야 할 때 특히 유용할 수 있습니다. 현재 인덱스가 계속 서비스되는 동안 다운타임을 피하기 위해 현재 인덱스의 복제본을 생성, 수정 및 테스트할 수 있습니다. 그런 다음 복제본이 준비되면 기존 별칭을 리타기팅하여 복제본이 현재 인덱스가 되고 (현재) 이전 인덱스는 제거될 수 있습니다.

색인 별칭 생성에 대한 자세한 내용은 다음을 참조하세요. 여기 

7. 인덱스 정의 업데이트 문제

사용자는 유형 매핑, 파티션, 복제본, 저장소 또는 지속성과 관련된 인덱스의 속성을 변경해야 할 때마다 인덱스 정의를 업데이트할 수 있는 옵션이 있습니다.

인덱스 정의를 업데이트할 때 염두에 두어야 할 한 가지는 업데이트 중 인덱스를 처음부터 다시 작성해야 하는 경우가 거의 없다는 것입니다.

인덱스 재구축 업데이트 

모든 유형의 매핑 또는 파티션 수 관련 업데이트는 항상 인덱스를 다시 빌드합니다. 따라서 이러한 변경 사항은 라이브 트래픽에 영향을 미칩니다. 그러나 일반적으로 이러한 유형의 인덱스 정의 업데이트는 클러스터의 초기 배포 단계에서 이루어집니다.

비리빌딩 업데이트 

나머지 인덱스 속성 업데이트는 즉시 이루어집니다. 업데이트는 기본 구성 요소의 재시작 또는 새로 고침으로만 이루어집니다. 인덱스는 단 몇 초의 다운 기간 내에 가동 및 실행되어야 합니다. 따라서 사용자는 트래픽이 많지 않은 시간대에 이러한 작업을 시도할 수 있습니다.

복제본 수 변경과 같은 인덱스 정의 업데이트, 스토리지 엔진 속성은 이 범주에 속합니다.

검색 시스템과 관련된 문의사항이 있는 경우, 사용자는 다음과 같이 문의할 수 있습니다. 여기.

FTS 쿼리 팁은 아래에서 확인할 수 있습니다. 블로그,

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