ElasticSearch Analyzers 란?

ElasticSearch 에서  분석하는 하여 데이터를 만드는게 Analyzers.

 

아래는 공식홈페이지 문서 번역한것입니다. 

소개

Elasticsearch 쿼리에 적합한 분석기를 선택하는 것은 과학만큼이나 예술이 될 수 있습니다. 분석기는 문서의 문자열 필드가 역 인덱스의 용어로 변환되는 방식을 결정하는 특수 알고리즘입니다. 이 기사에서 우리는 다양한 분석기를 조사할 것이며, 각각은 텍스트 구문 분석에 대한 매우 다른 접근 방식을 보여줍니다.

10개의 토크나이저, 31개의 토큰 필터 및 3개의 문자 필터가 Elasticsearch 배포와 함께 제공됩니다. 정말 압도적인 수의 옵션. 이 숫자는 플러그인을 통해 계속 증가할 수 있으므로 선택의 폭을 훨씬 더 좁힐 수 있습니다. 이러한 토크나이저, 토큰 필터 및 문자 필터를 조합하여 분석기를 생성합니다. 8개의 표준 분석기가 정의되어 있지만 실제로는 토크나이저, 토큰 필터 및 문자 필터를 직접 정렬하기 위한 편리한 바로 가기입니다. 이 다양한 옵션을 이해하는 것이 어렵게 들릴 수 있지만 분석기를 합리적으로 능숙하게 사용하는 것은 시간과 연습의 문제일 뿐입니다. 분석 이면의 기본 메커니즘을 이해하면 이러한 도구를 비교적 쉽게 추론하고 구성할 수 있습니다.

분석기의 구성 요소

분석기 내부에는 1) 문자 필터링, 2) 토큰화 및 3) 토큰 필터링 단계로 구성된 작은 처리 파이프라인이 있습니다. 물론 분석기의 궁극적인 목표는 문자열을 일련의 토큰으로 변환하는 것입니다. 분석기의 예는 아래 다이어그램에 나와 있습니다. 이 단락의 나머지 부분을 읽으면서 그것을 따라 해보세요. 실행 흐름은 분석기에 입력되는 문자열로 시작됩니다. 이 문자열은 먼저 선택적 문자 필터를 통해 실행되며, 각 필터는 텍스트를 소문자로 바꾸거나 단어를 대체하는 것과 같이 특정 방식으로 문자열을 변환하고 변환된 문자열을 출력합니다. 그런 다음 문자 필터의 문자열 출력은 토큰 목록을 내보내는 분석기의 유일한 필수 구성 요소인 토크나이저로 전달됩니다. 각 토큰에는 문자열 값과 토큰 스트림에서 해당 토큰이 있는 위치를 나타내는 위치 번호가 모두 포함됩니다. 마지막으로 이러한 토큰은 토큰을 추가로 변경할 수 있는 토큰 필터를 통해 선택적으로 전달됩니다.

분석기 파이프라인

Elasticsearch는 소수의 기본 분석기와 함께 제공됩니다. 사용자 지정 분석기는 인덱스 또는 클러스터 수준에서 설정 API를 통해 구성할 수 있습니다. 예제 사용자 지정 분석기의 구성은 아래 코드 샘플에서 볼 수 있습니다.

PUT /my-index/_settings
{
  "index": {
    "analysis": {
      "analyzer": {
        "customHTMLSnowball": {
         "type": "custom", 
          "char_filter": [
            "html_strip"
          ], 
          "tokenizer": "standard",
          "filter": [
            "lowercase", 
            "stop", 
            "snowball"
          ]  
        }}}}}

위의 분석기의 의도는 다음과 같습니다.

• html_stripchar 필터 를 통해 소스 텍스트에서 모든 HTML 태그를 제거합니다 .
• 단어 경계를 따라 텍스트를 standard나누고 토크나이저로 구두점을 제거합니다.
• 모든 토큰을 소문자로 지정하십시오.
• 'the', 'and' 및 기타 관련 없는 일반적인 단어와 같은 불용어인 토큰을 제거합니다.
• snowball토큰 필터 를 사용하여 모든 토큰을 스템합니다 .

소스 텍스트가 주어진 이 예제 분석기의 데이터 흐름을 따라가 보겠습니다 The two <em>lazy</em> dogs, were slower than the less lazy <em>dog</em>.. 이 분석기를 통해 소스 텍스트를 파이프하면 다음 다이어그램에 표시된 경로를 따릅니다.

맞춤형 분석기

분석기 선택

분석기를 구축할 때 가장 어려운 부분은 사용할 올바른 구성 요소를 결정하는 것입니다. 다음 섹션에서는 몇 가지 일반적인 사용 사례를 살펴봄으로써 분석기에 익숙해질 것입니다.

자연어 검색

형태소 분석

블로그 게시물, 잡지 기사, 법률 문서 등과 같은 자연어 본문을 검색할 때 종종 포함된 , , 또는 토큰 필터 와 같은 형태소 분석 토큰 필터를 사용하는 것이 좋습니다 . 이러한 종류의 분석기는 단어의 철자를 정규화하는 데 도움이 됩니다. 예를 들어 'sing', 'sings' 및 'singing' 토큰을 분석기와 마찬가지로 단일 어간 'sing'으로 번역합니다 . 분석기를 테스트하기 위해 다음 요청을 실행하면 이것이 실제로 작동하는 것을 볼 수 있습니다. 또한 기본 눈덩이 분석기에서 '그들'과 '아레'라는 불용어가 삭제되었음을 알 수 있습니다. stemmersnowballkstemporter_stemsnowball

GET http://localhost:9200/_analyze?text=I%20sing%20he%20sings%20they%20are%20singing&analyzer=snowball
// Output (abbreviated)
{
  "tokens": [
    {"token": "i", "position": 1, ...},
    {"token": "sing", "position": 2, ...},
    {"token": "he", "position": 3, ...},
    {"token": "sing", "position": 4, ...},
    {"token": "sing", "position": 7, ...},
  ]
}

형태소 분석 알고리즘은 검색에서 "singing"과 "sings"에 대한 검색을 구별해야 하는 경우가 일반적으로 드물다는 사실을 이용합니다. 그러나 그러한 차이 가 중요한 경우가 있습니다. 앞으로 살펴보겠지만 사람 이름, 제품 이름 등과 같은 콘텐츠와 관련된 검색의 경우 형태소 분석이 거의 의미가 없을 수 있습니다. 간단한 예를 들어, '플라이 낚시'와 '날치'라는 문구는 모두 눈덩이 형태소 분석기로 '플라이 피쉬'로 파생됩니다. 끔찍한 결과. 여행 가이드에서 이것은 실제 문제가 될 수 있습니다. 형태소 분석이 토큰화 전략의 전부는 아닙니다. 정확한 철자가 중요한 경우에는 형태소 분석기 없이 수행하고 필터를 통해 토큰만 필터링하는 더 간단한 전략을 사용하는 것이 더 나을 수 있습니다 lowercase.복잡한 분석기와 결합할 때 예상치 못한 결과를 제공할 수 있는 퍼지 쿼리 . 마지막으로 bool및 dis_max쿼리와 같은 도구를 사용하여 여러 쿼리를 결합할 수 있음을 기억하십시오.

국제화

독일어, 핀란드어 및 한국어와 같은 일부 언어는 검색 엔진에 문제가 될 수 있는 복합어를 사용합니다. 영어에서는 "Ballet Dancer"라는 문구를 사용할 수 있지만 독일어에서는 "Ballet"과 "Tänzerin"이라는 단어가 결합되어 "Balletttänzerin"이라는 단일 단어로 결합됩니다. "Balett"에 대한 검색은 적절한 경계에서 분할되지 않는 한 복합어와 일치하지 않습니다. 이 문제를 해결하려면 Elasticsearch Word Decompounder Analysis Plugin 과 같은 플러그인을 통해 단어를 분해 해야 합니다 . 이렇게 하면 해당 경계를 따라 이러한 단어가 분할됩니다.

대상 포진으로 구문 검색 최적화

쿼리에서 구문이 자주 사용되는 응용 프로그램에서 shingle분석기를 사용하면 성능을 높이고 결과 품질을 향상시킬 수 있습니다. 우리가 지금까지 본 분석기는 문자나 단어 경계에서 단어를 분해하는 반면, shingle 분석기는 소스 텍스트의 일부를 가져와 구문 그룹을 만듭니다. 본질적으로 문자 수준 대신 단어 수준에서 작동하는 nGram 토큰 필터입니다. max_shingle_size: 3따라서 "3월의 이데를 조심하십시오"라는 문장은 및 와 함께 싱글 토큰 필터를 사용하여 처리된 min_shingle_size: 1"주의", "주의", "이데스를 주의", "the", "Ides", "the Ides" 토큰을 생성합니다. ~의 관념" 등이 있습니다.

대상 포진을 생성하면 인덱스에 필요한 스토리지 및 메모리 양이 증가하지만 두 가지 이점이 있습니다. 첫째, 여러 AND-ed 용어의 결과가 아니라 단일 다중 단어 용어에 대해 구문을 일치시킬 수 있으므로 구문 쿼리의 성능이 크게 향상될 수 있습니다. 둘째, 개별 용어보다 실제 구문의 TF/IDF 유사성 이 더 정확한 결과를 산출하므로 점수를 더 정확하게 계산할 수 있습니다 . 대상 포진으로 검색하는 방법에 대한 자세한 내용 은 Elasticsearch 블로그의 대상 포진 검색 , 대규모 검색 블로그의 느린 쿼리 및 일반 단어 , Lucene 개발자 Robert Muir의 스택 오버플로 응답을 확인하십시오 .

대상 포진은 엄청난 성능 향상을 제공할 수 있지만 주로 개별 단어보다 단어의 고유한 조합이 더 많다는 사실과 관련하여 몇 가지 성능 문제를 일으킬 수도 있습니다. omit_term_freq_and_positionsshingle 필드 에 대해 로 설정 true하면 인덱스 크기를 크게 줄이고 검색 속도를 높일 수 있습니다. 구문 검색은 일반적으로 하나의 대상과만 일치하므로 위치 정보를 유지하는 데 큰 가치가 없습니다. 즉, 이 데이터가 없으면 더 긴 구문 검색이 불가능하므로 적절한 슁글 크기를 설정해야 합니다.

텍스트 토큰 검색

일부 유형의 텍스트는 분류하기가 더 어렵습니다. 소셜 사이트의 사용자 이름, 쇼핑 사이트의 카테고리 이름, 블로그 게시물의 태그 및 기타 항목에는 이전에 논의한 자연어 접근 방식과 다른 전략이 필요합니다. 형태소 분석과 같은 기술은 오탐(false positive)으로 이어질 수 있으며, 분리된 용어를 병합할 수도 있습니다. 이러한 경우 토큰의 고유성을 유지하는 것이 종종 중요합니다.

토큰을 정확히 검색하기

이러한 토큰을 처리하는 가장 간단한 전략은 "index": "not_analyzed"해당 필드에 대한 매핑에서 를 지정하여 분석을 완전히 비활성화하는 것입니다. 데이터는 문서에 저장된 텍스트와 정확히 일치합니다. 필드 사용의 예로 not_analyzed"작성자", "게시자" 및 "관리자"와 같은 다양한 사용자에 대한 다양한 역할을 가진 CMS가 있다고 가정해 보겠습니다. 역할별로 사용자를 검색할 수 있기를 원할 수 있습니다. 이 경우 사용자 인터페이스에는 정확한 사용자 유형을 선택하는 데 사용할 수 있는 드롭다운 선택 상자가 있을 수 있으므로 오타 또는 입력의 많은 변형 가능성을 제거합니다. 이것은 필드를 로 지정하는 이상적인 상황입니다 not_analyzed.

토큰을 부정확하게 검색하기

이전 예에서 검색 사용 사례는 GUI에 의해 부과된 제한된 입력에 완벽하게 적합했습니다. 이러한 시스템은 더 많은 자유 형식의 사용자 입력에 직면할 때 제대로 작동하지 않습니다. 사용자 이름은 이 점을 잘 보여주는 일반적인 사용 사례입니다. 사용자 이름 검색에서 다시 한 번 형태소 분석 알고리즘은 의미가 없습니다. 그러나 우리는 분명히 약간의 분석이 필요합니다. 최소한 "CmdrTaco"에 대한 쿼리는 사용자 "cmdrtaco"와 일치해야 합니다. 즉, lowercase토큰 필터가 최소한으로 정렬되어 있는 것 같습니다. 우리는 또한 사용자에게 가능한 가장 일치하는 목록을 보여주고 싶을 수도 있습니다. 'cmrdtaco'에 대한 검색이 여전히 일치한다면 여기에서 맞춤법 오류를 처리하는 것이 좋은 기능이 될 것입니다.

우리가 설명한 것과 같은 사용자 이름 검색의 경우 좋은 출발점이 되는 두 가지 접근 방식이 있습니다. keyword전체 입력 스트림을 토큰으로 내보내고 토큰 필터만 결합된 토크나이저 로 구성된 간단한 분석기 lowercase가 필요한 출력을 제공합니다. 이 출력은 잘 제공된 값 match으로 prefix, 및 match쿼리를 처리합니다. fuzziness특히 퍼지 검색에 대한 자세한 내용 은 Elasticsearch에서 퍼지 검색을 사용하는 방법을 참조하십시오 .

고급 토큰 검색에 NGram 사용

nGram추가 전략은 또는 토크나이저 와 마찬가지로 사용자 이름을 인덱싱하는 것일 수 있습니다 edgeNGram. 이러한 토크나이저는 텍스트를 구성 가능한 크기의 문자 튜플로 분할합니다. 예를 들어, 토크나이저를 통해 실행되는 "news"라는 단어는 min_gram:1, max_gram:2 nGram"n", "e", "w", "s", "ne", "ew" 및 "ws" 토큰으로 나뉩니다. 이러한 종류의 분석은 부정확한 일치와 관련하여 매우 효과적입니다. 기본적으로 match쿼리는 입력 쿼리를 분석한 다음 용어 목록을 다시 가져와서 마지막으로 관련된 용어에 대한 거대한 "OR" 쿼리를 실행한다는 것을 기억하십시오. 즉, 일치하는 용어가 가장 많은 항목이 반환됩니다. 이것은 많은 수의 오탐지가 반환된다는 것을 의미하지만,

음성 분석기 사용

음성 분석기는 실명 및 사용자 이름과 같은 것을 처리하기 위한 강력한 도구입니다. elasticsearch-analysis-phonetic플러그인 을 설치하여 사용할 수 있습니다 . metaphone또는 같은 음성 분석기의 목표는 soundex소스 텍스트를 음절 소리를 나타내는 일련의 토큰으로 변환하는 것입니다. 이를 통해 사용자 는 쿼리 텍스트 와 유사한 내용을 찾을 수 있습니다. 예를 들어, 이름 목록을 검색할 때 사용자가 '종료'라는 용어를 검색하면 'schmidt'라는 이름의 사용자에 대한 쿼리가 일치되기를 원할 수 있습니다. 두 단어가 같은 소리를 내기 때문에 철자 차이는 중요하지 않습니다.

메타폰 구성 요소를 사용한 검색의 예는 Play의 이 예에서 볼 수 있습니다 . 'schmit'에 대한 검색은 'schmidt' 및 'schmitt' 이름 모두와 일치합니다. 정확한 일치 'not_analyzed' 필드의 사용은 정확한 일치가 항상 먼저 나오도록 하는 데 중요합니다. 예제의 두 번째 쿼리에서 'schmidt'와 정확히 일치하는 항목이 있는 경우 정확한 일치 항목은 결과에서 우선 순위를 보장하기 위해 훨씬 더 높은 점수를 받습니다. 이러한 종류의 검색에 대한 보다 완전한 처리는 Elasticsearch 개발자 Clinton Gormley 의 이름 검색에 대한 이 포럼 스레드를 참조하십시오.

여러 접근 방식 결합

주어진 검색에 대해 단일 접근 방식만 취해야 할 이유가 없습니다. Elasticsearch의 옵션을 사용하면 위에서 언급한 Play 메타폰 에서 가져온 아래 예와 같이 multi_field단일 필드를 여러 번 인덱싱할 수 있습니다 ._source

// Document mapping
{
  "properties": {
    "name": {
      "fields": {
        "name_metaphone": {
          "type": "string", 
          "analyzer": "mf_analyzer"
        }, 
        "name_exact": {
          "index": "not_analyzed", 
          "type": "string"
        }
      }, 
      "type": "multi_field"
    }
  }
}

이 예에서는 name_metaphone또는 name_exact필드를 검색하여 동일한 수신 데이터에 대해 다른 결과를 얻을 수 있습니다. 단일 접근 방식으로 제한해야 할 이유가 없으며 bool및 dis_max쿼리를 사용하여 특정 데이터 세트에 대해 여러 쿼리 유형을 결합할 수 있습니다.

 

 

 

키워드 토크나이저를 기반으로 맞춤형 분석기 구축

토크나이저는 사용 가능한 가장 keyword간단한 토크나이저이며 단순히 입력을 단일 토큰으로 반환합니다. 일반적으로 이것이 원하는 유일한 동작인 경우 필드를 로 간단히 지정하는 것이 좋습니다 index: not_analyzed. 그러나 토큰 필터만으로 분석기를 구성할 때 매우 유용합니다. 이렇게 하면 전체 입력을 필요한 토큰 필터로 간단히 전달할 수 있습니다.

예를 들어 대소문자를 구분하지 않고 도시 이름을 검색할 수 있고 일반적으로 'ã'와 같은 펑키한 문자를 입력하지 않는 사용자에게 약간의 여유를 주고 싶다고 가정해 보겠습니다. 도시 이름을 소문자로 인덱싱하고 ASCII 폴딩 필터를 사용하여 'ã'와 같은 변환자를 'a'로 병합할 수 있습니다. 정확히 일치하는 항목만 찾고 있다면 공백으로 도시 이름을 분리하고 싶지 않습니다. 이 경우 모든 실제 작업이 '소문자' 토큰 필터와 'asciifolding' 토큰 필터에 의해 수행되기 때문에 키워드 토크나이저를 사용하려고 합니다. 따라서 분석기는 아래 예와 같이 보일 것입니다.

{
  "analysis": {
    "analyzer": {
      "city_name": {
        "type": "custom",
        "tokenizer": "keyword",
        "filter": ["lowercase", "asciifolding"]
      }
    }
  }
}

역 토큰 필터

reverse토큰 필터는 주석에 표시된 대로 수행하며 토큰을 가져와서 뒤집습니다 . 예를 들어 '고양이'는 'taC'가 됩니다. 이 토큰 필터의 주요 유틸리티는 빠른 접미사 검색을 활성화하는 것입니다. 실제 사용 사례 중 하나는 확장자로 파일 이름을 검색하는 것입니다.

Elasticsearch와 대부분의 모든 데이터베이스에서 기본 데이터 구조는 일종의 이진 트리와 같은 것임을 기억하십시오. 이진 트리를 걷는 것은 빠릅니다.오 ( l o g ( n ) )영형(엘영형g(N))- 접두사 또는 정확히 일치를 검색할 때. 대부분의 다른 검색 유형은 트리의 모든 데이터 조각에 대한 전체 스캔이 필요합니다. Elasticsearch는 멋진 자동 장치를 사용하여 이러한 느린 검색의 일부를 가속화할 수 있지만 여전히 훨씬 느립니다. 따라서 속도와 확장성 을 위해 모든 검색 문제를 접두사 검색 문제로 바꾸는 데 관심이 있습니다 .

다소 혼란스럽게도 접미사로 검색하려면 반대 버전의 원본 텍스트에 대해 검색하기 때문에 쿼리 에 match_phrase_prefix또는 쿼리 유형 을 사용해야 합니다 . prefix이 경우 쿼리를 사용 하는 것이 좋습니다. match_phrase_prefix쿼리는 원본 텍스트를 분석하지만 prefix쿼리는 분석하지 않기 때문입니다.

일반적으로 분석된 쿼리를 사용하는 것이 더 나은 이유를 알아 보기 위해 이 접미사 검색 match_phrase_prefix을 살펴보겠습니다 . 아래 내용으로 사용자 지정 분석기를 만들었습니다.

"fnLowerReverse": {
  "type": "custom",
  "tokenizer": "keyword",
  "filter": ["lowercase", "reverse"]
}

따라서 파일 이름에 대한 텍스트 Foo.tar.gz는 로 인덱싱됩니다 zg.rat.oof. zg.rat.확장명과 일치 하도록 의 접두사 검색을 수행하려고 합니다 . 일반 쿼리의 문제는 쿼리에 분석기가 없기 prefix때문에 애플리케이션에서 이 변환을 자동으로 수행해야 한다는 것 입니다. prefix아래 두 쿼리 중 첫 번째 쿼리가 훨씬 우수하다는 데 우리 모두 동의할 수 있다고 생각합니다.

// Better way
{
    "query": {
        "match_phrase_prefix": {
            "lowerReverse": ".tar.gz"
        }
    }
}
// Worse way
{
    "query": {
        "prefix": {
            "lowerReverse": "zg.rat."
        }
    }
}

또한 두 번째 쿼리를 사용할 때의 또 다른 위험은 분석 설정을 변경하기로 결정한 경우 앱이 단계를 유지해야 한다는 점을 알 수 있습니다. 이는 필터와 같은 복잡한 필터 asciifolding가 추가되는 경우 까다롭거나 거의 불가능할 수 있습니다.

역 토큰 필터를 피해야 하는 경우

토큰 필터는 훌륭 하지만 reverse접미사 일치가 필요한 모든 상황에서 반드시 최상의 옵션은 아닙니다. 도메인 이름과 TLD로 검색하는 경우를 살펴보겠습니다. 접미사 일치가 작동할 수 있지만 훨씬 더 나은 전략이 있습니다. 도메인 이름을 구성 요소 부분 집합으로 나누는 것입니다. 따라서 필터를 사용하여 해결할 수 있다고 생각되는 문제가 발생 reverse하면 실제로 접미사 문제가 있는지 또는 실제로 텍스트가 적절한 토큰으로 분할되지 않은 경우인지 생각해 보십시오. reverse여기서 좋은 지표 는 토큰 경계를 배치할 명확한 장소가 없을 때 사용하려는 것 입니다. 다음 섹션에서는 패턴을 사용하여 텍스트를 분리하는 방법을 다룰 것입니다.

패턴 작업

특정 경계를 따라 구조화된, 아마도 기계 생성된 텍스트를 분할하고 싶을 때가 있습니다. 고전적인 예는 모두 고도로 구조화된 도메인 이름과 IP 주소입니다. 또 다른 예로는 key=value 구문이 있는 INI 파일이 있습니다. 이러한 종류의 형식으로 작업하는 것은 패턴 기반 분석 도구를 사용하여 단순화할 수 있습니다.

패턴 토크나이저

우선 두 가지 모드 중 하나에서 작동할 수 있는 pattern토크나이저 가 있습니다. 기본 모드에서 제공된 정규 표현식은 소스 텍스트를 분할하는 데 사용됩니다. 예를 들어 '-+' 패턴은 소스 텍스트를 대시 시퀀스로 분할하여 'foo and bar—and baz-bot blah' 텍스트를 ['foo and bar', 'and baz', 'bot blah'].

또한 정규 표현식의 캡처 그룹 인덱스를 지정하는 옵션을 pattern사용하여 토큰을 분리하지 않고 토큰을 분리하기 위해 토크나이저를 뒤집을 수 있습니다 . group텍스트에서 모든 숫자를 가져오고 싶다고 가정해 봅시다. 텍스트 'Foo 82 Bar 90 Bat 21'이 주어지면 '[0-9+]' 패턴으로 모든 숫자를 분리하고 group옵션을 '0'으로 설정하여 일치하는 모든 텍스트를 토큰화할 수 있습니다. 정규 표현식에서 '()'로 시작되는 캡처 그룹을 사용하는 경우 group옵션은 일치시킬 그룹의 인덱스를 지정합니다.

패턴 캡처 토큰 필터

또한 사용할 수 있습니다 pattern_capture. 이 토큰 필터는 토크나이저와 크게 다릅니다 pattern. 한 가지 예로, 이 필터의 patterns매개변수는 정규 표현식 목록을 허용하므로 여러 방법으로 텍스트를 일치시킬 수 있습니다. preserve_original또한 옵션 을 통해 방출하는 토큰과 함께 원래 토큰을 통과하는 것을 지원합니다 .

이는 다른 토큰의 하위 부분을 분리하려는 경우에 유용할 수 있습니다. 예를 들어 재무 문서를 색인화할 때 'FY2013'과 같은 용어를 더 풍부한 방식으로 색인화할 수 있습니다. 2013에 대한 검색은 'FY2013'과 일치해야 하며 'FY2013'도 일치해야 합니다. pattern_capture토큰 필터 를 사용하여 이 까다로운 문제를 해결할 수 있습니다 .

{
"filter": {
  "financialFilter": {
    "type": "pattern_capture",
    "patterns": ["FY([0-9]{2,4})"],
    "preserve_original": true
  }}}

토큰 필터 로 작업할 때 pattern_capture토큰은 단순한 텍스트가 아니라 텍스트 및 위치라는 것을 기억하는 것이 중요합니다. 새 토큰은 소스 텍스트와 동일한 토큰 위치를 갖습니다. 위의 예에서 '정말 FY2008은 나빴다'라는 문구는 [“Truly” 1 , “FY2008” 2 , “2008” 2 , “was” 3 , “bad” 4 “]로 토큰화됩니다. 토큰 위치는 위 첨자로 표시되었으며 "FY2008"과 "2008"은 동일한 위치를 공유합니다. 이는 토큰 위치 근접성이 구문의 범위를 결정하는 구문 쿼리 작업에 중요합니다.

필터 의 또 다른 훌륭한 용도 pattern_capture는 트위터와 유사한 해시태그와 멘션(예: '#elasticsearch' 또는 ' 1 ')을 분리하는 것입니다. 이러한 해시태그를 분리하는 것은 와 같은 정규 표현식으로 매우 간단합니다 ([@#]\\w+). 단일 ''는 JSON 형식만 이스케이프하므로 Elasticsearch에 대해 이러한 정규 표현식을 선언할 때 JSON에서 백슬래시를 이중으로 이스케이프해야 합니다. 이 동작은 클라이언트 라이브러리에서 자동으로 처리되어야 하지만 일부는 오작동할 수 있습니다.

마지막으로 주어진 토큰의 패턴을 다른 텍스트로 단순히 바꾸는 pattern_replace토큰 필터 가 있습니다. 이 필터는 간단하기 때문에 간결함의 이름으로 독자를 위한 연습으로 남겨 둘 것입니다.

동의어 작업

Elasticsearch에서 단어 동의어를 인덱싱하는 것은 synonym토큰 필터 를 사용하여 수행할 수 있습니다 . pattern_replace동의어는 하나의 토큰을 여러 토큰에 매핑하는 방법을 제공하며 이전에 언급한 필터 와 유사한 토큰 위치 문제의 대상이 됩니다 . 토큰화된 출력의 주어진 위치에는 여러 동의어에 대한 여러 토큰이 포함될 수 있습니다. 토큰 필터 의 작동은 synonym제공된 동의어 규칙에 따라 다르며 이러한 규칙에 따라 토큰을 추가하거나 교체합니다.

동의어를 사용하는 간단한 예는 레시피 웹사이트입니다. 일부 영국 단어 철자를 미국식 단어와 동의어로 사용하고 싶을 수도 있습니다. 예를 들어, '고수' 허브는 미국에서 '실란트로'로 알려져 있습니다. Elasticsearch 동의어를 통해 '고수'와 '실란트로'를 모두 검색할 수 있습니다. 이를 달성하려면 먼저 분석기에서 사용할 동의어 사전을 만들어야 합니다. Elasticsearch는 동의어 사전 SOLR과 wordnet. 아래 예제 사전 파일에서 더 간단한 SOLR 구문을 사용합니다.

# This is a SOLR synonym file
# Save this in a file uk_us_food_names.txt

# The '=>' will perform replacement of the original token, replacing the token on the left with the one on the right
coriander => cilantro
rocket => arugula
chips => fries

# using a comma ',' will cause both tokens to show up in the stream at the same position
taters, potatoes
candy, sweets

# This syntax will replace either of the terms on the left with the one on the right
mayo, mayonaise => sandwich lube

# This syntax will replace the term on the left with both terms on the right
knife => slicer, chopper

동의어가 있는 필드에서 집계할 계획이라면 '=>' 구문을 사용하여 토큰을 완전히 대체하는 것이 좋습니다. 이렇게 하면 수많은 중복 항목이 집계에 표시되는 것을 방지할 수 있습니다. 또한 쿼리 관점에서 쿼리가 문서와 동일한 동의어 토큰 필터를 통해 실행되는 한(많은 쿼리 유형을 사용하는 경우 자동) 동의어의 '측면'을 모두 인덱싱하는 이점이 없습니다. 단일 토큰은 단어의 의미를 잘 포착할 수 있습니다. 그러나 분석되지 않은 필터 또는 쿼리를 사용하는 경우 색인에 두 용어를 모두 포함하는 것이 유용할 수 있습니다.

'=>' 동의어 필터의 또 다른 장점은 많은 관계가 양방향이 아니라는 것입니다. 예를 들어 모든 당근은 야채이지만 모든 야채가 당근은 아닙니다. 따라서 '당근 => 야채, 당근'과 같은 매핑이 유용하지만 '당근, 야채'는 사용자에게 엄청난 골칫거리가 될 것입니다.

이러한 동의어 목록은 물론 분석기가 사용하기 위해 실제로 어딘가에 있어야 합니다. Elasticsearch에서 동의어를 관리할 수 있는 두 가지 방법이 있습니다. 매우 작은 동의어 목록의 경우 아래의 구문을 사용하여 색인 설정에서 동의어를 설정할 수 있습니다.

{
  "settings": {
    "analysis": {
      "analyzer": {
        "product_name": {
          "type": "custom",
          "tokenizer": "whitespace",
          "filter": ["my_synonyms"]
        } 
    },
    "filter": {
      "my_synonyms": {
        "type": "synonym",
          "synonyms": [
            "foo => bar",
            "baz => bot, blah",
           ]
      }}}}}

예를 들어 수백 줄 이상의 더 큰 동의어 목록의 경우 synonyms_path옵션보다 옵션 을 사용하는 것이 훨씬 좋습니다 synonyms. 이 옵션은 Elasticsearch 인스턴스에 로컬인 파일을 가리키며, 이는 두 가지 이유로 우수합니다. 첫째, 인덱스에 대한 '설정'에 많은 양의 데이터가 있으면 인덱스 설정이 클러스터의 노드 간에 지속적으로 복제되기 때문에 클러스터 속도가 느려질 수 있습니다. 둘째, 설정 API를 통해 많은 양의 데이터를 반환하는 것은 클라이언트에게 상당히 번거로운 일입니다.

동의어 파일은 호스트 간에 정확히 복제되어야 합니다. 주의 깊게 관리하지 않으면 나쁜 일이 발생할 수 있습니다. 발견 시 동의어 파일이 포함된 사용자 정의 번들을 업로드하면 자동으로 수행됩니다. 자체 서버를 관리하는 경우 Ansible, Chef 또는 Puppet과 같은 구성 관리 도구를 사용하여 호스트 간에 이러한 파일을 동기화해야 합니다. 그렇지 않으면 동의어가 어떤 호스트에서 어떤 요청을 처리하는지에 따라 다르게 해석될 수 있습니다.

또한 동의어 사용을 계획할 때 동의어가 업데이트되면 새 동의어를 정확하게 반영하기 위해 모든 이전 문서를 다시 색인화해야 한다는 점을 이해하는 것이 중요합니다. 이러한 이유로 동의어 구현을 계획할 때는 주의해야 합니다.

아스키 접기

토큰 필터 는 asciifolding유니코드 텍스트를 다룰 때 종종 유용한 필터입니다. 유니코드 문자를 가장 가까운 ASCII 문자로 축소해야 하는 경우가 있습니다. 예를 들어 문자 'aáåä'를 'a'로 정규화합니다. asciifolding토큰 필터는 이를 수행하여 토큰의 모든 문자가 유니코드 기본 라틴 블록의 처음 127바이트에 포함되도록 합니다 . 국제 사용자와 함께 사용할 때는 혼란스러운 결과를 초래할 수 있으므로 주의하십시오.

Elastissearch 1.1.0에서는 preserve_original각 토큰을 원래 값으로 한 번 접힌 후 두 번 색인화하는 설정을 지원합니다. 이것은 약간의 저장 비용을 희생시키면서 두 가지 장점을 모두 제공할 수 있습니다.

경로 계층 토큰 필터로 풍부한 분류 처리

이 path_hierarchy분석기는 계층적 분류를 처리하는 Elasticsearch에 대한 보다 독창적이고 흥미로운 기능 중 하나를 활성화합니다. 이 토큰 필터는 간단하며 '/a/path/somewhere'와 같은 문자열을 사용하여 '/a', '/a/path', '/a/path/somewhere'로 토큰화합니다. 이 간단한 기술은 다양한 상황에서 유용합니다.

이 토큰 필터의 가장 확실한 용도는 파일/디렉토리 이름을 쉽게 집계하는 것입니다. 예를 들어 이러한 토큰을 패싯하면 '/usr/bin' 경로 아래에 얼마나 많은 파일이 있는지 쉽게 볼 수 있습니다. path_hierarchy사실, 토큰 필터 를 사용하여 인덱싱된 필드에서 빈도별로 정렬을 집계 하면 가장 큰 상위 디렉토리를 다시 얻을 수 있습니다.

그러나 path_hierarchy토큰 필터는 단순히 파일 경로를 분리하는 것으로 제한되지 않습니다. 예를 들어 도메인 이름은 계층 구조 측면에서 오른쪽에서 왼쪽으로 구성되므로 delimiter옵션을 로 .설정 reverse하고 로 설정하여 도메인 이름과 함께 사용할 수 있습니다.true

다른 모든 것이 실패할 때

이 기사는 Elasticsearch 분석기에 대한 완전한 설명이 결코 아닙니다. 우리는 문자 필터 에 대해 이야기 하거나 분석기와 같은 다른 흥미로운 분석기를 다룰 공간조차 없었습니다 compound_word. 독자가 시간을 내어 분석을 위해 Elasticsearch 문서를 스캔하여 최소한 다른 도구가 무엇인지에 대한 기본적인 지식을 갖추는 것이 좋습니다 .

배울 '완전한' 분석기 세트는 없습니다. Elasticsearch와 함께 번들로 제공되는 것은 일반적인 문제에 대한 일반적인 솔루션일 뿐입니다. 특정 애플리케이션에 Elasticsearch에 포함된 분석기 제품군으로 수행할 수 없는 추가 분석이 필요하다는 것을 알 수 있습니다.

미리 빌드된 옵션이 부족할 때 두 가지 기본 솔루션이 있습니다. 1.) 애플리케이션 코드에서 일부 분석을 수행하고, 2.) 사용자 지정 Elasticsearch 분석기를 작성합니다. 첫 번째 옵션은 생각보다 나쁘지 않습니다. 예를 들어 소스 데이터가 Elasticsearch의 분석기가 구문 분석할 수 없는 이상한 형식으로 저장되어 있다면 Elasticsearch로 들어가기 전에 변환하는 것이 부끄러운 일이 아닙니다. 그러나 Elasticsearch를 실행하는 여러 애플리케이션이 있고 특히 데이터가 인덱싱되는 것과 동일한 프로세스를 통해 쿼리를 분석해야 하는 경우 적절한 분석기를 직접 작성하는 것이 좋습니다. 마지막으로 분석 기능을 확장하는 Elasticsearch 및 Lucene용 플러그인이 많이 있음을 기억하십시오. 귀하의 문제는 이미 다른 사람이 해결했을 수 있습니다. 즐거운 검색!

 

 

 

 

https://www.elastic.co/kr/blog/found-text-analysis-part-1

All About Analyzers, Part One