2.X/3. Dealing with Human Language

3-5-3. Stopwords and Performance

drscg 2017. 9. 24. 13:00

The biggest disadvantage of keeping stopwords is that of performance. When Elasticsearch performs a full-text search, it has to calculate the relevance _score on all matching documents in order to return the top 10 matches.

불용어를 유지하는 경우의 가장 큰 단점은 성능이다. Elasticsearch가 full-text 검색을 수행할 경우, 상위 10개의 document를 반환하기 위해, 일치하는 모든 document의 relevance _score 를 계산해야 한다.

While most words typically occur in much fewer than 0.1% of all documents, a few words such as the may occur in almost all of them. Imagine you have an index of one million documents. A query for quick brown fox may match fewer than 1,000 documents. But a query for the quick brown foxhas to score and sort almost all of the one million documents in your index, just in order to return the top 10!

일반적으로, 대부분의 단어는 전체 document의 0.1%보다 훨씬 더 적게 나타나지만, the 같은 소수의 단어는 대부분 document에서 나타날 것이다. 백만 건의 document를 가진 index를 가정해 보자. quick brown fox 에 대한 query는 1,000건 보다 더 적게 일치할 것이다. 그러나, the quick brown fox 에 대한 query는 단지 상위 10건의 document를 반환하기 위해, index에 있는 백만 건의 document 거의 모두의 score를 계산하고 정렬해야 한다.

The problem is that the quick brown fox is really a query for the OR quick OR brown OR fox—any document that contains nothing more than the almost meaningless term the is included in the result set. What we need is a way of reducing the number of documents that need to be scored.

문제는, the quick brown fox 가 실제로는 the OR quick OR brown OR fox 에 대한 query라는 점이다. 거의 의미 없는 단어에 불과한 the 를 가지는 모든 document가 결과 집합에 포함된다. score를 계산할 document의 수를 줄이는 것이 필요하다.

and Operatoredit

The easiest way to reduce the number of documents is simply to use the and operator with the match query, in order to make all words required.

document의 수를 줄이는 가장 쉬운 방법은, 모든 단어가 필요하도록, match query에 and operator를 사용하는 것이다.

match query like this:

아래와 같은 match query는

{
    "match": {
        "text": {
            "query":    "the quick brown fox",
            "operator": "and"
        }
    }
}

is rewritten as a bool query like this:

아래와 같은 bool query로 다시 작성된다.

{
    "bool": {
        "must": [
            { "term": { "text": "the" }},
            { "term": { "text": "quick" }},
            { "term": { "text": "brown" }},
            { "term": { "text": "fox" }}
        ]
    }
}

The bool query is intelligent enough to execute each term query in the optimal order—it starts with the least frequent term. Because all terms are required, only documents that contain the least frequent term can possibly match. Using the and operator greatly speeds up multiterm queries.

bool query는, 최적의 순서로 각 term query를 실행할 만큼, 충분히 지능적이다. 그것은 가장 낮은 빈도의 단어로 시작한다. 모든 단어가 필요하기 때문에, 가장 낮은 빈도의 단어를 포함하고 있는 document만이 일치할 수 있다. and operator를 사용하면, 다중 단어 query 속도가 크게 향상된다.

minimum_should_matchedit

In Controlling Precision, we discussed using the minimum_should_match operator to trim the long tail of less-relevant results. It is useful for this purpose alone but, as a nice side effect, it offers a similar performance benefit to the and operator:

Controlling Precision에서, 덜 관련된 결과 중 불필요한 것을 제거하기 위하여, minimum_should_matchoperator를 사용하는 것에 대해 이야기했었다. 그것은 이 목적만으로도 유용하지만, 좋은 부작용으로, andoperator와 유사한 성능성의 이점을 제공한다.

{
    "match": {
        "text": {
            "query": "the quick brown fox",
            "minimum_should_match": "75%"
        }
    }
}

In this example, at least three out of the four terms must match. This means that the only docs that need to be considered are those that contain either the least or second least frequent terms.

이 예제에서, 네 단어 중 최소 셋은 반드시 일치해야 한다. 즉, 고려해야 할 document는, 최소 혹은 두 번째로, 낮은 빈도의 단어를 포함하는 document이다.

This offers a huge performance gain over a simple query with the default or operator! But we can do better yet…

이것은 기본인 or operator와 함께 사용되는 간단한 query에 비해, 엄청난 성능의 향상을 가져온다. 하지만, 아직 더 잘 할 수 있다.


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

3-5-1. Pros and Cons of Stopwords  (0) 2017.09.24
3-5-2. Using Stopwords  (0) 2017.09.24
3-5-4. Divide and Conquer  (0) 2017.09.24
3-5-5. Stopwords and Phrase Queries  (0) 2017.09.24
3-5-6. common_grams Token Filter  (0) 2017.09.24