[ElasticSearch] prefix,match_phrase_prefix 쿼리, index_prefixes 설정

Prefix Query

• 필드에 대해 접두어(prefix) 검색하는 쿼리
  • 자동완성, 검색어 추천(Suggestion) 등에 사용

GET /_search
{
  "query": {
    "prefix" : { "user" : "ki" }
  }
}

• 성능 이슈
  • 역색인(inverted index) 를 사용한 검색이 아닌, 필드 값을 모두 검사
  • -> 문서 수가 많아질수록 속도 저하
  • 그렇기에 search.allow_expensive_queries 설정이 false 일 경우 prefix 쿼리는 사용 불가
• 문서 색인시 index_prefixes 설정을 통해 성능 향상
  • index_prefixes 설정된 경우 search.allow_expensive_queries 가 false 여도 실행 가능

index_prefixes

• index_prefixes: 필드 값에 대해 prefix를 별도의 인덱스로 저장
  • min_chars: 저장할 최소 prefix 길이. 1 이상으로 제한, default 2
  • max_chars: 저장할 최대 prfix 길이. 20 미만으로 제한, default 값 5

PUT my_index
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "index_prefixes": {
          "min_chars": 2, 
          "max_chars": 5
        }
      }
    }
  }
}

match_phrase_prefix query

• 앞 단어들은 구문(phrase) 매칭, 마지막 단어만 prefix 쿼리

• ex) quick brown 은 match_phrase와 같이 매칭, 마지막 단어인 f 만 prefix 쿼리와 같이 동작

GET /_search
{
  "query": {
    "match_phrase_prefix": {
      "message": {
        "query": "quick brown f"
      }
    }
  }
}

• 문제점
  • 앞 단어들로 match_phrase 매칭한 후, 매칭된 50개 문서에 대해서만 prefix 매칭
  • -> 50개 안에서만 prefix 검색하기 때문에, 문서가 누락될 수 있음

하지만 자동완성 서비스에 적용하지 않은 이유

• 사용자들은 문서의 첫 단어부터 입력하는 경우보단 그렇지 않은 경우가 많다.
  • prefix 쿼리도, match_phrase_prefix 도 성능이 그리 좋지 않았다.
  • 검색 로그에서도, 사용자 경험에서도 생각나는 중간 단어부터 입력하는 경우가 많았다
• 그렇기에 필드에 edge 하위 필드를 두고 edge ngram 를 적용하여 매칭하는 것이 자동완성에 훨씬 유리했다.
  • nDCG 스코어도, 서비스 반영 후 CTR 도 높게 나왔고. (6~70%)
  • 특수 문자가 많은 특성상 analyzer 적용도 크게 작용했다고 판단

reference

• ElasticSearch docs - Prefix query
• ElasticSearch docs - Match phrase prefix query
• ElasticSearch docs - index_prefixes