카우치베이스 4.5 베타의 멀티노드 전체 텍스트 검색

카우치베이스 서버 4.5 베타에서 전체 텍스트 검색 확장하기

카우치베이스 서버 4.5에는 새로운 서비스가 포함되어 있습니다, 전체 텍스트 검색(FTS) . 이 블로그에서는 FTS가 노드 간에 확장되는 방법, 인덱스를 복제하는 방법, 리밸런싱에서 작동하는 방식에 대해 설명합니다.

Couchbase Server 4.5 개발자 프리뷰가 출시된 이후 FTS 팀은 바쁘게 움직였습니다. Couchbase Server 4.5 베타 릴리스에는 많은 FTS 버그가 해결되었을 뿐만 아니라 다음과 같은 기능도 포함되어 있습니다. 많은 큰 FTS 개선 사항:

• 12배 빠른 인덱싱 성능
• 더 나은 통계
• 인증 및 역할 기반 액세스 제어 지원
• 관리자 이벤트의 감사 로깅
• 부분 결과 지원

4.5 베타 버전에서 가장 주목할 만한 새로운 검색 기능은 여러 노드에서 FTS 서비스를 실행할 수 있는 기능입니다. 지금 베타 버전에서 사용해 볼 수 있으며, 여기에서 읽은 내용은 Couchbase Server 4.5가 정식 버전이 되어도 계속 적용됩니다.

면책 조항을 먼저 말씀드리겠습니다:  FTS는 카우치베이스 서버 4.5의 GA 버전에서는 개발자 프리뷰로 유지되므로 프로덕션 서버에서 실행하지 마세요.. FTS에는 정말 멋진 기능이 많지만 아직 해야 할 일 목록에 있는 성능 및 시스템 테스트 확인란을 모두 체크하지는 않았습니다. 긍정적인 측면은 초기 테스트 사용자들로부터 받은 피드백을 반영할 수 있는 기회라는 점입니다. (피드백이 있으신가요? couchbase 닷컴에서 직접 이메일을 보내주세요.)

자, 이제 본론으로 들어가 보겠습니다. 검색 서비스를 사용하면 타사 검색 패키지에 의존하지 않고도 Couchbase 문서에서 텍스트를 색인하고 검색할 수 있습니다. 새로운 검색 서비스는 데이터, 색인 및 쿼리 서비스를 결합하며 다차원 확장(MDS)을 위해 다른 서비스처럼 관리할 수 있습니다. N1QL과 달리 검색 서비스는 단일 서비스에서 전체 텍스트 쿼리와 색인 작업을 모두 수행한다는 점에 유의하세요.

분산 검색 서비스 - 내부 

대부분의 경우 분산 검색 인덱스는 "그냥 작동"합니다. Couchbase 전체 텍스트 검색 서비스는 노드를 추가할 때 새로운 하드웨어를 활용하고 전체 텍스트 인덱스는 데이터 서비스와 함께 페일오버되고 재조정됩니다. 이 섹션에서는 이를 가능하게 하는 메커니즘에 대해 설명하며, 일반적으로 사용자는 알 필요는 없지만 부분 검색 결과(나중에 다룸)에서와 같이 가끔 마주칠 수 있는 메커니즘에 대해 설명합니다.

처음부터 전체 텍스트 검색은 데이터 서비스가 버킷에 데이터를 배포하는 것과 매우 유사한 방식으로 텍스트 인덱스를 노드 전체에 배포하도록 설계되었습니다. Couchbase Server의 버킷 및 vBuckets를 이해하면 이를 이해하는 데 좋은 정신적 모델을 갖게 됩니다. 버킷은 작업하기 쉬운 데이터 포함의 논리적 단위이며, vBucket은 버킷에 있는 데이터의 물리적 부분으로 클러스터의 특정 노드에 존재합니다. 버킷에서 복제를 켜면 Couchbase Server는 해당 버킷을 구성하는 모든 필요한 vBucket의 복사본을 만듭니다. 또한 Couchbase Server는 이러한 vBucket의 레이아웃이 최적인지 확인하는데, 이는 그 자체로 복잡한 주제이지만 지금은 노드에 고르게 분산되도록 vBucket의 위치 균형을 맞추는 것으로 생각하면 됩니다.

FTS도 비슷하게 작동합니다. 전체 텍스트 인덱스는 자동으로 다음과 같은 조각으로 나뉩니다. 핀덱스는 '분할 인덱스' 또는 '물리적 인덱스'의 줄임말로, 누구에게 물어보느냐에 따라 다릅니다. 버킷과 마찬가지로 전체 텍스트 인덱스는 논리적 개념입니다. vBucket이 버킷의 물리적 구현인 것처럼 핀덱스는 인덱스의 물리적 구현입니다.

핀덱스는 검색 서비스를 실행하는 카우치베이스 노드에 물리적으로 분산되어 있으며, 그 수는 얼마든지 늘어날 수 있습니다. 개발자 프리뷰에서는 단일 노드였지만 베타에서는 이 제한이 해제되었습니다. 아래 예제에서는 간단하게 하기 위해 두 개의 노드만 사용하겠습니다.

검색 노드 추가하기

이제 시작할 시간입니다. Couchbase Server 4.5 베타 이상을 사용 중이라면 모든 준비가 완료된 것입니다. 둘 이상의 노드를 설정해야 하므로 가상 머신을 준비하세요. 이 예제에서는 두 개의 Windows Server 2012 VM을 사용하겠습니다.

검색 서비스를 실행하는 단일 노드부터 시작해 보겠습니다. 여행 샘플 버킷의 호텔 문서에 간단한 색인을 생성하겠습니다. 여행 샘플이 설치되어 있지 않은 경우, 여행 샘플을 클릭하여 다운로드할 수 있습니다. 설정 > 샘플 버킷 을 클릭한 다음 확인란을 선택합니다.

이 데모에서는 어떤 전체 텍스트 인덱스든 사용할 수 있습니다. "name" 및 "description" 두 필드, store = true, "지정된 필드만 색인"으로 type="hotel"(기본 유형 매핑을 비활성화하는 것을 잊지 마세요)에 인덱스를 생성하여 빠르게 빌드하도록 했습니다.

UI 알레르기가 있는 경우를 대비하여 curl 명령어를 소개합니다:

완료되면 '여관'과 같은 일반적인 단어를 검색하여 제대로 작동하는지 확인할 수 있습니다.

Couchbase 데이터 디렉토리를 살펴보면 다음과 같이 표시됩니다. @fts 디렉토리를 만듭니다. 이 디렉터리를 열면 핀덱스가 포함된 여러 디렉터리가 표시됩니다.

두 번째 검색 노드 및 리밸런싱

평소처럼 클러스터에 두 번째 노드를 추가합니다. 검색 서비스를 활성화하려면 상자를 체크하는 것을 잊지 마세요.

완료되면 다음과 같은 화면이 표시되며 서버 재조정 보류 중임을 알 수 있습니다.

이 경우 여행 샘플 데이터에 복제본이 없기 때문에 장애 조치 경고가 표시됩니다. 들어가서 재조정 버튼을 누르세요. 문서가 새 노드로 복사되기 시작하고 복제본이 만들어지며 여행 샘플의 뷰는 일종의 로컬 인덱스이므로 데이터 재조정은 활성 데이터가 이동함에 따라 뷰도 다시 만들어야 함을 의미합니다. (이 데모의 목적을 위해 시간을 절약하고 싶다면 뷰를 삭제할 수 있습니다.) 핀덱스도 사용 가능한 노드에 대해 재조정됩니다.

프로세스가 완료되면 이제 각 서버에 절반씩의 핀덱스가 생깁니다.

이를 확인하려면 Couchbase da디렉토리로 다시 이동합니다. 디렉터리 수가 절반으로 줄어듭니다:

인덱스 복제본

Couchbase에서 활성 문서와 복제 문서를 가질 수 있는 것처럼 전체 텍스트 인덱스를 복제할 수 있습니다. 문서 복제본과 마찬가지로 텍스트 인덱스 복제본도 사용 가능한 하드웨어에 따라 클러스터에 자동으로 균형 있게 배치됩니다. 전체 텍스트 인덱스를 복제하는 것은 주로 장애 복구 속도를 높이기 위한 것입니다. 문서와 달리, 전체 텍스트 인덱스는 언제든지 인덱스 정의를 사용하여 재색인하여 다시 만들 수 있으므로 데이터 손실의 위험이 없습니다.

전체 텍스트 인덱스를 만들거나 업데이트할 때 하나 또는 두 개의 복제본을 지정하는 옵션이 있습니다. 이렇게 하려면 인덱스 정의로 이동하여 편집을 클릭한 다음 고급 설정 표시.

In 계획 매개변수변경 숫자 복제 를 1로 설정한 다음 색인 업데이트.

정의를 저장하자마자 카우치베이스 서버는 활성 및 복제본 텍스트 인덱스 생성을 시작합니다. 이렇게 하면 인덱스의 또 다른 복사본이 생성됩니다. 다시 말하지만, 데이터@fts 디렉터리 중 하나를 보고 인덱스 수를 세어보면 이를 확인할 수 있습니다. 이제 각 노드에는 활성 인덱스의 1/2과 복제본 인덱스의 1/2이 있어야 합니다.

이 정보는 서버 노드 탭에서 서버 중 하나를 클릭한 다음 "전체 텍스트 검색 통계"를 입력합니다. 다음에 대한 통계가 표시됩니다. 실제 핀덱스 (존재 수) 및 핀덱스 대상 (요청한 복제본 수에 따라 몇 개가 있어야 하는지).

실패

이제 노드 하나를 장애 조치합니다. 지금 검색하면 부분적인 결과, 즉 나머지 인덱스에서 검색 결과를 얻을 수 있습니다. 이는 일부 애플리케이션이 오류를 발생시키는 대신 부분적인 결과를 계속 사용하기로 선택할 수 있기 때문에 의도된 것입니다. 결국, 데이터 세트가 충분히 크면 사용자는 누락된 문서를 알아차리지 못할 수도 있습니다.

이제 노드의 밸런스를 재조정합니다. 복제본을 사용한 재조정은 매우 빠릅니다. (이전에 이동 샘플 보기를 삭제하지 않은 경우 장애 조치에 훨씬 더 오래 걸립니다.)

재조정을 누르면 다른 노드가 문서 복제본과 핀덱스 복제본 모두 복제본을 활성화하여 매우 빠르게 인계받습니다. 이 승격은 즉각적으로 이루어집니다. 인덱스가 완전히 따라잡히지 않았거나 문서 변경이 진행 중이어서 인덱싱이 진행 중인 경우, 전체 텍스트 인덱스를 만드는 데 시간이 더 걸릴 수 있습니다. vBuckets가 이동하면 FTS 서비스를 실행하는 노드는 DCP 스트림을 리밸런싱이 완료된 위치에 다시 연결합니다.

리밸런싱이 완료되면 다음과 같은 화면을 볼 수 있습니다. 이제 복제본이 없어지고 처음에 가졌던 핀덱스 수로 돌아갑니다:

복제본 없이 장애 조치하기

먼저 전체 텍스트 인덱스 복제본을 만들지 않고 위의 실험을 수행하면 어떻게 될지 궁금할 것입니다. 그것도 작동하며, 어떤 일이 일어나는지 확인하기 위해 한 번쯤 해볼 가치가 있습니다. 이 경우 정확히 절반에 해당하는 일부 핀덱스에 대해 기본 인덱스가 없을 것입니다. 위에서 언급했듯이 원래 색인 정의를 사용하여 문서를 다시 색인하면 누락된 색인을 다시 만들 수 있으므로 데이터 손실은 없습니다. 부분적인 결과를 얻을 수 있으며, 더 오랜 기간 동안 결과를 얻을 수도 있습니다. 재조정을 수행할 때 누락된 인덱스는 처음부터 다시 시작해야 하며, 사용 가능한 인덱스 복제본이 있는 경우만큼 따라잡지 못하기 때문입니다.

사용해 보기

분산형 전체 텍스트 색인은 이번 릴리스에서 제가 가장 좋아하는 기능 중 하나입니다. 사용하는 것보다 설명하는 데 시간이 더 오래 걸리긴 하지만요! 직접 사용해 보시고 의견을 알려주시기 바랍니다. 즐거운 검색 되세요!