2.X/3. Dealing with Human Language

3-5-5. Stopwords and Phrase Queries

drscg 2017. 9. 24. 12:55

About 5% of all queries are phrase queries (see Phrase Matching), but they often account for the majority of slow queries. Phrase queries can perform poorly, especially if the phrase includes very common words; a phrase like "To be, or not to be" could be considered pathological. The reason for this has to do with the amount of data that is necessary to support proximity matching.

모든 query의 약 5%는 phrase query(Phrase Matching 참조)이다. 하지만, 그들이 slow query의 대부분을 차지한다. phrase query는, 특히 구문이 아주 흔한 단어를 포함하고 있으면, 신통치 않게 실행된다. "To be, or not to be" 같은 구문은 비정상적인 것으로 간주된다. 그 이유는, 근접(proximity) 일치를 지원하기 위해, 필요한 데이터의 양이 어마어마하기 때문이다.

In Pros and Cons of Stopwords, we said that removing stopwords saves only a small amount of space in the inverted index. That was only partially true. A typical index may contain, among other data, some or all of the following:

Pros and Cons of Stopwords에서, 불용어를 제거하는 것은 inverted index에서 적은 양의 디스크 공간을 절약할 뿐이라고 언급했었다. 이것은 부분적으로만 사실이다. 일반적으로 index는, 서로 다른 데이터 사이에, 다음의 일부나 전부를 포함할 수 있다.

Terms dictionary

A sorted list of all terms that appear in the documents in the index, and a count of the number of documents that contain each term.

index의 document에 나타나는 모든 단어의 정렬된 목록, 각 단어를 포함하고 있는 document의 수

Postings list

A list of which documents contain each term.

각 단어를 포함하고 있는 document의 목록

Term frequency

How often each term appears in each document.

각 document에 나타나는 각 단어의 수

Positions

The position of each term within each document, for phrase and proximity queries.

phrase나 proximity query를 위한, 각 document 내에서 각 단어의 위치

Offsets

The start and end character offsets of each term in each document, for snippet highlighting. Disabled by default.

하이라이트 정보를 위한, 각 document에서 각 단어의 시작과 종료 문자의 offset. 기본적으로 비활성화

Norms

A factor used to normalize fields of different lengths, to give shorter fields more weight.

더 짧은 field에 더 많은 비중을 주기 위해, 다른 길이를 가진 field의 정규화를 위해 사용되는 요소.

Removing stopwords from the index may save a small amount of space in the terms dictionary and the postings list, but positions and offsets are another matter. Positions and offsets data can easily double, triple, or quadruple index size.

index에서 불용어를 제거하는 것은, terms dictionary 와 posting list 에서, 적은 양의 공간을 절약할지는 모르겠지만, positions 와 offset 은 다른 문제이다. position과 offset 데이터는 index size를 쉽게 두 배, 세 배, 네 배로 만든다.

Positions Dataedit

Positions are enabled on analyzed string fields by default, so that phrase queries will work out of the box. The more often that a term appears, the more space is needed to store its position data. Very common words, by definition, appear very commonly, and their positions data can run to megabytes or gigabytes on large collections.

phrase query가 즉시 동작하도록 하기 위해, analyzed string field에서 위치(position)는 기본적으로 활성화되어 있다. 단어가 더 자주 나타날수록, 그것의 위치 데이터를 저장하기 위한 공간이 더 많이 필요하다. 매우 흔한 단어는, 당연히, 매우 자주 나타나고, 그들의 위치 데이터는 큰 집합에서 MB나 GB에 이를 수 있다.

Running a phrase query on a high-frequency word like the might result in gigabytes of data being read from disk. That data will be stored in the kernel filesystem cache to speed up later access, which seems like a good thing, but it might cause other data to be evicted from the cache, which will slow subsequent queries.

the 처럼 높은 빈도의 단어로 phrase query를 실행하면, 디스크에서 읽을 데이터가 GB로 나타날 수도 있다. 그 데이터는, 차후의 접근 시 속도를 올리기 위해, kernel file system cache에 저장될 것이다. 좋은 것처럼 보이지만, 후속 query의 속도 저하 때문에, 다른 데이터가 cache에서 제거되는 원인이 될 수 있다.

This is clearly a problem that needs solving.

이것은 해결해야 하는 문제임에 틀림없다.

Index Optionsedit

The first question you should ask yourself is: Do you need phrase or proximity queries?

스스로 해봐야 할 첫 번째 질문은 phrase나 proximity query가 필요한가? 이다.

Often, the answer is no. For many use cases, such as logging, you need to know whether a term appears in a document — information that is provided by the postings list—but not where it appears. Or perhaps you need to use phrase queries on one or two fields, but you can disable positions data on all of the other analyzed string fields.

흔히, 대답은 no 이다. logging 같은, 많은 사용 사례에서, 단어가 어디에 나타나느냐가 아닌 단어가 document에 나타나는지 여부를 알 필요가 있다. 이것이 posting list가 가진 정보이다. 또는 한두 개의 field에 phrase query를 사용해야 한다면, 다른 analyzed string field 모두에게 위치 데이터를 비활성화 할 수 있다.

The index_options parameter allows you to control what information is stored in the index for each field. Valid values are as follows:

index_options 매개변수를 통해, 각 field에 대해 index에 저장할 정보가 무엇인지를 제어할 수 있다. 유효한 값은 아래와 같다.

docs

Only store which documents contain which terms. This is the default for not_analyzed string fields.

단어를 포함하는 document만을 저장한다. 이것이 not_analyzed string field의 기본값이다.

freqs

Store docs information, plus how often each term appears in each document. Term frequencies are needed for complete TF/IDF relevance calculations, but they are not required if you just need to know whether a document contains a particular term.

docs 의 정보와 추가로 각 단어가 각 document에 얼마나 자주 나타나는지를 저장한다. term Frequency는 TF/IDF relevance의 완벽한 계산을 위해 필요하다. 그러나, document가 특정 단어를 포함하는지 여부만 알아야 한다면, 불필요하다.

positions

Store docs and freqs, plus the position of each term in each document. This is the default for analyzed string fields, but can be disabled if phrase/proximity matching is not needed.

docs 와 freqs, 추가로 각 document에서 각 단어의 위치를 저장한다. 이것이 analyzed string field의 기본값이다. 그러나 phrase나 proximity 일치가 필요하지 않다면, 비활성화할 수 있다.

offsets

Store docsfreqspositions, and the start and end character offsets of each term in the original string. This information is used by the unified highlighter but is disabled by default.

docsfreqspositions 그리고 원래 문자열에서 각 단어의 시작과 마지막 문자의 offset을 저장한다. 이 정보는 unified highlighter에 사용된다. 기본적으로 비활성화되어 있다.

You can set index_options on fields added at index creation time, or when adding new fields by using the put-mapping API. This setting can’t be changed on existing fields:

index 생성시에 또는 put-mapping API를 사용하여 새로운 field를 추가하는 경우, field에 추가로 index_options 를 설정할 수 있다. 이 설정은 기존 field를 변경할 수는 없다.

PUT /my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "title": { 
          "type":          "string"
       },
        "content": { 
          "type":          "string",
          "index_options": "freqs"
      }
    }
  }
}

title field는 positions 의 기본 설정을 사용한다. 따라서 phrase/proximity query에 적합하다.

content field는 positions을 비활성화하였다. 따라서, phrase/proximity query를 사용할 수 없다.

Stopwordsedit

Removing stopwords is one way of reducing the size of the positions data quite dramatically. An index with stopwords removed can still be used for phrase queries because the original positions of the remaining terms are maintained, as we saw in Maintaining Positions. But of course, excluding terms from the index reduces searchability. We wouldn’t be able to differentiate between the two phrases Man in the moon and Man on the moon.

불용어를 제거하는 것은 위치 데이터의 크기를 상당히 축소하는 방법 중의 하나이다. 불용어가 제거된 index는, Maintaining Positions에서 알 수 있듯이, 남아 있는 단어의 원래 위치가 유지되기 때문에, 여전히 phrase query를 사용할 수 있다. 그러나 물론, index에서 단어를 제외하는 것은 검색 가능성을 축소하는 것이다. Man in the moon 과 Man on the moon 을 구별할 수 없을 것이다.

Fortunately, there is a way to have our cake and eat it: the common_grams token filter.

다행스럽게도 아직 common_grams token filter라는 방법이 있다.


'2.X > 3. Dealing with Human Language' 카테고리의 다른 글

3-5-3. Stopwords and Performance  (0) 2017.09.24
3-5-4. Divide and Conquer  (0) 2017.09.24
3-5-6. common_grams Token Filter  (0) 2017.09.24
3-5-7. Stopwords and Relevance  (0) 2017.09.24
3-6. Synonyms  (0) 2017.09.24