jjeong

글 제목과 비슷할 수도 다를 수도 있습니다.

precision 과 recall 에 대한 설명이 짧게 잘 표현이 되어 있어서 기록해 봅니다.

원문링크)

원문 Snippet)

원래 이 문서는 언어에 대한 처리 목적 이였습니다.

그래서 정의한 5가지 title 만 정리해 봤습니다.

- Normalizing Tokens

추출 된 token 에서 필요 없는 character를 제거 합니다.

- Reducing Words To Their Root Form

Word 에 붙은 불필요한 정보를 제거 합니다. (word의 origin을 만든다고 보시면 쉽습니다.)

- Stopwords

불용어 처리를 합니다. (즉, 색인 대상에서 제외 시킵니다.)

- Synonyms

동의어 또는 유의어 처리를 합니다.

- Typoes and Mispelings

오타 처리를 합니다.

Relevance 관련 글이 많아서 일단 한번쯤은 꼭 읽어 봐야 하는 글만 모아 봤습니다.

원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/query-scoring.html

- 이 글에서는 bool query에 대한 query competition 에 대한 내용이 포함 되어 있습니다.

https://www.elastic.co/guide/en/elasticsearch/guide/current/not-quite-not.html

- 이 글에서는 boosting query에 대한 내용이 포함 되어 있습니다.

https://www.elastic.co/guide/en/elasticsearch/guide/current/ignoring-tfidf.html

- 이 글에서는 constant_score query에 대한 내용이 포함 되어 있습니다.

- 즉, 모든 점수가 1로 나오며, boosting 설정 값에 따라 score 를 부여하게 됩니다.

https://www.elastic.co/guide/en/elasticsearch/guide/current/boosting-by-popularity.html

- 이 글에서는 function_score query에 대한 내용이 포함 되어 있습니다.

가장 기본이 되는  TF/IDF Scoring 에 대한 설명 입니다.

복습 차원에서 기록해 봅니다.

원문링크)

원문 Snippet)

tf(t in d) = √frequency 

idf(t) = 1 + log ( numDocs / (docFreq + 1)) 

norm(d) = 1 / √numTerms 

가볍게 정리 하면)

- tf는 문서 내 발생한 term 빈도수 : term 빈도수가 클 수록 weight 가 높습니다.

- idf는 전체 문서에서 발생한 term 빈도수 : term 빈도수가 작을 수록 weight 가 높습니다.

- norm은 field내 text의 길이 : 길이가 짧을 수록 weight 가 높습니다.

더불어 mapping 설정도 살짝 살펴 보면)

필요한 정보만 저장할 경우 저장소 낭비를 방지 할 수 도 있으며, score 계산시 조금이나마 성능적 효과도 볼 수 있습니다.

모든 옵션을 다 사용해야 할지 선택적으로 사용해도 문제 없을지 잘 판단 하시면 좋을 것 같습니다.

- index_options

- norms: {enabled: <value>}

그냥 좋은 내용이라 기록 합니다.

원문링크)

원문 Snippet)

짧게 정리 하면)

- query-time operation 은 비용이 들지만 flexible 하다.

- index-time operation 은 색인 성능이 떨어지고 저장공간이 늘어 날 수 있지만 질의 성능이 좋아지고 더욱 유연하게 사용할 수 있게 해준다.

문서에 대한 relevance를 어떻게 구현해야 비용이 적게 들까? 고민 해보신 적이 있을 실겁니다.

꼭 이 글이 일치 하지는 않지만 match query 사용 시 비싼 비용을 지불하지 말고 indexing time 에 활용을 한번 해보면 어떨까 하는 아이디어에서 나온 글로 보시면 어떨까 합니다.

그런 의미에서 기록해 봤습니다.

원문링크)

원문 Snippet)

※ shingles 란? 쉽게 token(term)들에 대한 ngram 이라고 이해 하시면 쉽습니다.

결국 검색 질의 시 slop 이나 position_offset_gap 기능을 이용하는 것 보다 색인 시 shigles analyzed 를 통해 질의 비용을 줄이는 것이라고 보시면 됩니다.

단, 문서에도 있지만 저장 공간이 늘어 나게 됩니다.

검색 질의에 대한 성능 향상 관련 글 입니다.

한번 쯤 읽어 보시면 좋을 것 같아 기록 합니다.

원문링크)

요약)

- term query 가 match query 종류 보다 10배 에서 20배 빠릅니다.

- 그렇다고 해서 match query 종류가 느린것은 아닙니다. ( 수 밀리초 내 응답 합니다.)

- slop, position_offset_gap 과 같은 속성 사용에 대한 이해가 필요합니다.

Rescoring 이라는 것이 나오는데요.

이건 function_score 랑도 비슷합니다.

하지만 두 개의 목적은 비슷하지만 사용법은 다르죠.

결과적으로 두 API 다 개별 shard 에서의 top N 개의 문서를 가지고 다시 rescoring 하게 된다는 것입니다.

match query type 중 phrase 에 대한 이해를 돕기 위해 기록 합니다.

원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/phrase-matching.html

원문 Snippet)

What Is a Phraseedit

For a document to be considered a match for the phrase “quick brown fox,” the following must be true:

• quick, brown, and fox must all appear in the field.
• The position of brown must be 1 greater than the position of quick.
• The position of fox must be 2 greater than the position of quick.

If any of these conditions is not met, the document is not considered a match.

Internally, the match_phrase query uses the low-level span query family to do position-aware matching. Span queries are term-level queries, so they have no analysis phase; they search for the exact term specified.

Thankfully, most people never need to use the span queries directly, as the match_phrasequery is usually good enough. However, certain specialized fields, like patent searches, use these low-level queries to perform very specific, carefully constructed positional searches.

다시 한번 정리 하면,

- position-aware matching 을 이용하는 span query

- 첫번째 term 에 대한 position에 의해 나머지 term 들의 matching position 은 quick의 position 보다 커야 합니다.

주의 사항이라 기록해 봅니다.

원문링크)

원문 Snippet)

multi match query 에서 사용하는 type 설명 입니다.

그냥 소스코드에서 발췌 했습니다.

[MultiMatchQueryBuilder.java]

/**
 * Uses the best matching boolean field as main score and uses
 * a tie-breaker to adjust the score based on remaining field matches
 */
BEST_FIELDS(MatchQuery.Type.BOOLEAN, 0.0f, new ParseField("best_fields", "boolean")),

/**
 * Uses the sum of the matching boolean fields to score the query
 */
MOST_FIELDS(MatchQuery.Type.BOOLEAN, 1.0f, new ParseField("most_fields")),

/**
 * Uses a blended DocumentFrequency to dynamically combine the queried
 * fields into a single field given the configured analysis is identical.
 * This type uses a tie-breaker to adjust the score based on remaining
 * matches per analyzed terms
 */
CROSS_FIELDS(MatchQuery.Type.BOOLEAN, 0.0f, new ParseField("cross_fields")),

/**
 * Uses the best matching phrase field as main score and uses
 * a tie-breaker to adjust the score based on remaining field matches
 */
PHRASE(MatchQuery.Type.PHRASE, 0.0f, new ParseField("phrase")),

/**
 * Uses the best matching phrase-prefix field as main score and uses
 * a tie-breaker to adjust the score based on remaining field matches
 */
PHRASE_PREFIX(MatchQuery.Type.PHRASE_PREFIX, 0.0f, new ParseField("phrase_prefix"));

bulk indexing 을 하다 보면 색인 하는 과정에서 느려지는 현상을 경험 할 수 있습니다.

여러가지 원인이 있을 수 있지만 간단하게 설정을 통해서 성능 향상을 시킬수 있는 방법을 소개해 드립니다.

기본적인 정보는 이미 Elasticsearch Reference 에서 제공하고 있기 때문에 관련 내용을 찾아 보시면 이해 하시는데 도움이 됩니다.

참고문서)

Elasticsearch 역시 lucene 기반의 검색 엔진이기 때문에 과거부터 전해져 오는 segment merge 시 발생 하는 성능 저하 문제는 피해 갈 수가 없습니다.

이를 좀 더 효율적으로 사용하기 위해 아래 설정을 활용 하시면 됩니다.

Merge throttle 은 두 가지 방법을 제공해 주고 있습니다.

1. Node level throttle

이것은 merge 동작은 shard 단위로 발생을 하기 때문에 같은 node 에 있는 shard 들은 동일한 자원을 사용하게 됩니다.

즉, disk i/o 에 대한 경합을 할 수 밖에 없는 것인데요.

이런 이유로 node level 설정을 사용하게 됩니다.

※ 여기서 수정이 필요한 부분은 색인 데이터의 크기를 감안해서 max_bytes_per_sec 을 적합한 크기로 설정해 주시면 됩니다.

2. Index level throttle

특정 index 에 대해서 관리를 하고 싶을 때 node level throttle 설정을 무시 하고 설정을 하도록 해주는 것입니다.

설정 방법은 index update settings 를 통해서 할 수 있습니다.

※ 여기서 수정이 필요한 부분은 색인 데이터의 크기를 감안해서 max_bytes_per_sec 을 적합한 크기로 설정해 주시면 됩니다.

※ throttle type을 none 으로 할 경우  disable merge 설정이 됩니다.