오늘 다음과 같이 전체 텍스트 검색(FTS)의 중요한 개선 사항을 발표하게 되어 기쁘게 생각합니다. 카우치베이스 서버 4.6. 이 블로그에서는 4.6의 새로운 검색 기능에 대해 설명합니다:
- 성능 개선
- 키별 인덱스 유형 매핑
- 사용자 지정 정렬
Couchbase Server FTS는 클러스터 전체에서 원활하게 실행되며 Elasticsearch와 유사한 검색 기능을 제공합니다. FTS "그냥 작동" 배포 - 를 사용하면 클러스터 전체에 분산된 다중 노드 검색을 실행하기 위해 특별한 작업을 할 필요가 없습니다. 사용자가 Couchbase Server에서 기대하는 것과 동일한 방식으로 관리하면 됩니다. 예를 들어, 하드웨어를 추가하고 밸런스를 재조정하면 Couchbase Server가 클러스터 전체에 인덱스를 배포하여 새로 프로비저닝된 노드가 검색 워크로드를 처리하도록 할 수 있습니다. 이는 개발자와 관리자 모두를 위해 검색을 간단하게 만드는 목표의 일부입니다.
FTS는 개발자 프리뷰 버전이며, Couchbase Server 4.6이 정식 버전으로 출시된 후에도 개발자 프리뷰 버전으로 유지됩니다. 사용해 보시고 피드백을 공유해 주시기 바랍니다.
http://www.couchbase.com/blog/2016/november/introducing-couchbase-server-4.6.0-developer-preview
더 빠른 검색
4.6에서는 이전 릴리스에 비해 검색 속도가 빨라지고 리소스를 더 효율적으로 사용할 수 있습니다. 이번 릴리스에서는 FTS 자체는 물론 다음과 같은 시스템 전반이 개선되었습니다. bleveFTS를 지원하는 전체 텍스트 검색 및 인덱싱 Go 라이브러리입니다.
성능 개선에 가장 큰 기여를 한 것은 FTS의 전체 텍스트 인덱스를 위한 새로운 기본 kv 저장소 메커니즘인 MossStore입니다. MossStore는 Moss ("메모리 지향 정렬 세그먼트")는 순수 Golang 라이브러리로 구현된 간단하고, 빠르고, 지속 가능하며, 정렬된 키 값 컬렉션입니다. Moss는 인덱스 세그먼트를 지속하기 전에 메모리에서 정렬함으로써 쿼리, 특히 인덱싱 성능을 향상시킵니다. MossStore는 세그먼트가 항상 정렬되므로 다시 정렬할 필요가 없다는 점에서 일반적인 KV 저장소에 비해 중요한 이점이 있습니다. 모든 사용 사례에 MossStore를 권장합니다.
다음 릴리스에서는 더 많은 성능 향상이 준비 중입니다. 기대해 주세요!
키별 인덱스 유형 매핑
이제 문서 키를 사용하여 사용자 지정 인덱스 매핑을 만들어 유형을 결정할 수 있습니다. 인덱스 매핑은 문서를 검색 가능하게 만들기 위한 규칙을 지정하는 프로세스입니다. 전체 텍스트 검색에서 개발자는 일반적으로 문서 유형에 따라 서로 다른 인덱스 매핑을 지정합니다. 예를 들어 '도시' 필드를 색인하되 '호텔' 유형의 문서에 대해서만 색인을 생성하고 '랜드마크' 유형의 문서에는 색인을 생성하지 않으려 할 수 있습니다. 이전 릴리즈에서는 문서 JSON의 속성으로 유형이 설정된 경우에만 이 기능이 작동했지만, 4.6에서는 문서 키의 일부(예: "hotel::1234"와 같은 키의 접두사 "::"까지)를 사용하여 문서 유형을 결정할 수도 있습니다.
이 개선 사항으로 문서 유형이 키의 일부로 표시되는 일반적인 데이터 모델링 스타일(예: "user::will.gardella")을 더 쉽게 지원할 수 있습니다. 일반적으로 이 유형 식별자는 키의 접두사가 되므로 FTS를 사용하면 정규식을 사용하지 않고 접두사만 지정할 수 있는 쉬운 옵션이 제공됩니다. 반면에 접두사와 같이 더 복잡한 키 디자인이 있는 경우 정규식을 사용할 수 있습니다.
카우치베이스 서버와 함께 제공되는 여행 샘플 버킷에서 이 기능을 사용해 볼 수 있습니다. 여행 샘플 데이터 모델은 벨트 및 멜빵 원칙을 따르며, 문서 유형은 JSON 유형 속성과 문서 키의 접두사에 중복으로 표시됩니다.
다음은 여행 샘플 버킷이 설치되어 있다는 가정 하에 단계별 예시입니다. 사용자가 호텔과 항공사를 검색할 수 있는 인덱스를 만들어 보겠습니다. 조금 낯선 작업이지만 일단 해보겠습니다.
먼저 웹 관리자로 이동합니다(예 http://localhost:8091/) ) > 색인 > 전체 텍스트 색인 > 새 전체 텍스트 색인으로 이동합니다. 서버를 실행하는 위치에 따라 이 URL로 바로 이동할 수도 있습니다: http://127.0.0.1:8091/ui/index.html#/fts_new/?indexType=fulltext-index&sourceType=couchbase.
새로운 "유형 식별자" 필드로 이동합니다. 이전 동작은 기본값으로, 문서 본문에서 문서 유형을 나타내는 "type"이라는 필드를 찾습니다. 이 경우에는 문서 메타데이터의 ID를 대신 사용합니다.
문서 ID 옆의 확인란을 구분 기호까지 클릭합니다. 밑줄 '_'를 입력합니다. 이렇게 하면 FTS가 밑줄까지 문서 키를 구문 분석하고 해당 접두사를 '유형 매핑'에 입력한 문자열과 비교하도록 지시합니다. 이 단계는 FTS에 문서의 유형을 찾을 위치만 알려줄 뿐, 아직 인덱스 매핑 규칙을 선언하지 않는다는 점에 유의하세요. 이것이 바로 다음에 할 일입니다.
"유형 매핑 추가"를 클릭합니다. "항공사" 유형과 "호텔" 유형을 하나씩 추가합니다. 기본 매핑을 비활성화하지 않으면 항공사 및 호텔뿐만 아니라 모든 항목이 색인에 표시된다는 점을 잊지 마세요.
마지막으로, 테스트이므로 삼각형을 클릭하여 '고급'을 펼치고 '동적 필드 저장'을 체크합니다. 이렇게 하면 모든 항공사 및 호텔 문서의 모든 필드가 색인될 뿐만 아니라 색인된 내용을 전체 텍스트 색인에 저장하여 강조 표시하고 스니펫으로 검색할 수 있습니다. 이렇게 하면 더 멋진 데모를 만들 수 있지만 색인 크기가 커지고 그에 따라 모든 속도가 느려집니다. 이 데모에서는 큰 차이가 없을 것입니다.
모든 작업이 완료되면 인덱스 정의는 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
{ "type": "전체 텍스트 인덱스", "name": "travelPrefix", "sourceType": "couchbase", "sourceName": "travel-sample", "planParams": { "최대 파티션당 인덱스": 32, "numReplicas": 0, "계층 규칙": null, "nodePlanParams": null, "pindexWeights": null, "planFrozen": false }, "params": { "doc_config": { "docid_prefix_delim": "_", "모드": "docid_prefix" }, "매핑": { "기본_분석기": "표준", "기본_날짜_파서": "날짜/시간 옵션", "default_field": "_all", "default_mapping": { "display_order": "2", "동적": true, "enabled": false }, "default_type": "_default", "index_dynamic": true, "store_dynamic": true, "type_field": "type", "types": { "항공사": { "display_order": "0", "동적": true, "enabled": true }, "호텔": { "display_order": "1", "동적": true, "enabled": true } } }, "store": { "kvStoreName": "mossStore" } }, "sourceParams": { "클러스터관리자백오프팩터": 0, "clusterManagerSleepInitMS": 0, "clusterManagerSleepMaxMS": 2000, "데이터 관리자 백오프 팩터": 0, "dataManagerSleepInitMS": 0, "dataManagerSleepMaxMS": 2000, "feedBufferAckThreshold": 0, "피드버퍼사이즈바이트": 0 } } |
새로 생성된 JSON 인덱스 정의에 "params" 객체 호출에 "doc_config", 4.6에 새로 추가된 필드입니다. 이 필드인 "doc_config"는 문서 ID 또는 유형 필드를 기반으로 매핑하는지 여부에 따라 "mode" 및 "type_field" 또는 "mode"라는 두 개의 필드가 있는 객체이기도 합니다.
유형 필드별 인덱스 매핑:
|
1 2 3 4 |
"doc_config": { "모드": "type_field", "type_field": "type" } |
문서 ID로 인덱스 매핑(접두사 최대):
|
1 2 3 4 |
"doc_config": { "docid_prefix_delim": "_", "모드": "docid_prefix" } |
하나의 항공사와 하나의 호텔이 정확히 일치하는 'delta'에 대한 쿼리 문자열 쿼리를 수행하여 반짝이는 새 인덱스를 테스트해 볼 수 있습니다. (알죠, 편리하죠?). REST API를 사용하는 경우 쿼리 JSON은 다음과 같이 표시되며, 웹 관리자의 검색 상자를 사용하여 동일한 검색을 수행할 수도 있습니다.
|
1 2 3 4 5 6 7 8 9 10 |
{ "설명": true, "fields": [ "*" ], "하이라이트": {}, "query": { "query": "델타" } } |
보너스 팁:
검색 입력 필드 오른쪽에 있는 '고급' 옵션을 클릭한 다음 명령줄 컬 예제 상자를 클릭하면 웹 관리자에서 쿼리 JSON을 가져올 수 있습니다.
정렬
Couchbase Server 4.6에서는 해당 필드도 색인되어 있는 경우 문서의 모든 필드별로 검색 결과를 정렬할 수 있는 기능이 도입되었습니다. 이전 릴리스와 4.6에서는 기본적으로 검색 결과가 내림차순으로 정렬되어 가장 관련성이 높은 결과가 먼저 나열됩니다.
사용자 지정 정렬 순서를 사용하려면 쿼리에 문자열 배열이 포함된 '정렬' 필드를 전달하고 각 문자열은 정렬하려는 필드의 이름을 참조합니다. 이전 단계에서 만든 travelPrefix 인덱스를 사용하면 다음과 같이 이름을 기준으로 정렬할 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "설명": false, "fields": [ "title" ], "하이라이트": {}, "sort": ["name"], "query":{ "query": "아름다운 수영장" } } |
필드 이름 앞에 '-' 문자를 붙이면 해당 필드가 내림차순으로 정렬됩니다. 따라서 이전 예제의 정렬 필드는 다음과 같이 표시됩니다:
|
1 |
"sort": ["-name"] |
필드 이름의 배열을 전달하면 먼저 첫 번째 필드를 기준으로 결과가 정렬됩니다. 그런 다음 해당 필드에 대해 동일한 값을 가진 항목은 다음 필드를 기준으로 정렬되는 식으로 정렬됩니다.
모든 문서에 사용할 수 있는 두 가지 특수 필드를 사용할 수 있습니다:
'_id' - 문서 키를 나타냅니다.
'_score' - 는 Bleve에서 계산한 관련성 점수를 나타냅니다.
다음은 또 다른 예입니다. 이 예에서는 문서가 점수, 내림차순, 동점일 경우 ID를 기준으로 정렬됩니다.
|
1 |
"sort": ["-_score","_id"] |
다음은 호텔 검색 결과를 정렬하는 데 사용할 수 있는 좀 더 복잡한 예입니다:
|
1 |
"sort": ["country", "상태", "city","-_score"] |
결과는 먼저 국가별로 정렬됩니다. 문서의 국가 값이 같으면 주별로 정렬되고, 국가와 주가 같으면 도시별로 일치하는 항목이 정렬됩니다. 마지막으로 다른 모든 필드가 같으면 결과가 점수 내림차순으로 정렬됩니다. 이 예에서는 지역에 따라 그룹화되고 도시 수준에서 점수별로 정렬된 결과 목록을 볼 수 있습니다.
피드백 환영
언제나 그렇듯이 여러분의 의견을 기다립니다. 커뮤니티와 얼리어답터들의 관대한 의견은 제품 방향에 큰 영향을 미치기 때문에 공유해 주신 모든 의견에 감사드립니다. 즐거운 검색 되세요!
