2-4-6. Improving Performance

Phrase and proximity queries are more expensive than simple match queries. Whereas a matchquery just has to look up terms in the inverted index, a match_phrase query has to calculate and compare the positions of multiple possibly repeated terms.

phrase와 proximity query는, 단순한 match query에 비해, 더 많은 비용이 든다. match query는 단어를 inverted index에서 찾는 반면에, match_phrase query는 가능한 한 여러 번, 반복해서 단어들의 위치를 계산하고 비교한다.

The Lucene nightly benchmarks show that a simple term query is about 10 times as fast as a phrase query, and about 20 times as fast as a proximity query (a phrase query with slop). And of course, this cost is paid at search time instead of at index time.

Lucene nightly benchmarks는, 간단한 term query가 phrase query보다 10배 정도 빠르고, proximity query(slop 을 사용한 phrase query)보다 20배 정도 빠르다는 것을 보여준다. 물론 이 비용은, 색인 시가 아닌, 검색 시에 지불된다.

Usually the extra cost of phrase queries is not as scary as these numbers suggest. Really, the difference in performance is a testimony to just how fast a simple termquery is. Phrase queries on typical full-text data usually complete within a few milliseconds, and are perfectly usable in practice, even on a busy cluster.

일반적으로, phrase query의 추가 비용은 위에서 제시한 숫자만큼 크지는 않다. 실제로 위의 성능의 차이는, 간단한 term query가 얼마나 빠른가에 대한 평가이다. 보통의 full-text 데이터에서, phrase query는 일반적으로 수 milliseconds안에 완료된다. 바쁜 cluster에서조차 실제로 완벽하게 사용 가능하다.

In certain pathological cases, phrase queries can be costly, but this is unusual. An example of a pathological case is DNA sequencing, where there are many many identical terms repeated in many positions. Using higher slop values in this case results in a huge growth in the number of position calculations.

걷잡을 수 없는 경우에, phrase query가 매우 비용이 높을 수 있는데, 이것은 일반적인 상황이 아니다. 걷잡을 수 없는 경우의 예는, 많은 곳에서 동일한 단어가 아주 많이 반복되는, DNA 염기 서열이 있다. 이런 경우에 높은 slop 값을 사용하면, 위치 계산의 횟수가 엄청나게 증가하게 된다.

So what can we do to limit the performance cost of phrase and proximity queries? One useful approach is to reduce the total number of documents that need to be examined by the phrase query.

그렇다면, phrase와 proximity query의 성능 비용을 제한하려면 어떻게 해야 할까? 한가지 유용한 방법은, phrase query가 확인해야 하는 document의 총 수를 줄이는 것이다.

Rescoring Resultsedit

In the preceding section, we discussed using proximity queries just for relevance purposes, not to include or exclude results from the result set. A query may match millions of results, but chances are that our users are interested in only the first few pages of results.

이전 부분에서, 결과 집합에 포함하거나 제외하기 위한 것이 아닌, relevance 목적으로만 proximity query를 사용하는 것에 대해 이야기했었다. 어떤 query는 수백만 개의 결과를 가질지도 있지만, 사용자는 결과의 처음 몇 page에만 관심이 있을 가능성이 있다.

A simple match query will already have ranked documents that contain all search terms near the top of the list. Really, we just want to rerank the top results to give an extra relevance bump to those documents that also match the phrase query.

간단한 match query는, 목록의 상위에, 모든 검색어를 가지고 있는 document를 이미 가질 것이다. 실제로, 우리는 단지 phrase query에도 일치하는 해당 document에, 추가 relevance를 부여하기 위해, 상위 결과의 순위를 다시 계산하기를 원한다.

The search API supports exactly this functionality via rescoring. The rescore phase allows you to apply a more expensive scoring algorithm—like a phrase query—to just the top K results from each shard. These top results are then resorted according to their new scores.

search API는 rescoring 을 통해 정확히 이 기능을 지원한다. phrase query와 마찬가지로, rescore 절은 각 shard의 상위 K 개의 결과에게만, 더 많은 비용이 소모되는, scoring algorithm을 적용할 수 있다. 이들 상위 결과는 그들의 새로운 score에 따라 재정렬된다.

The request looks like this:

request는 아래와 같다.

GET /my_index/my_type/_search
{
    "query": {
        "match": {  
            "title": {
                "query":                "quick brown fox",
                "minimum_should_match": "30%"
            }
        }
    },
    "rescore": {
        "window_size": 50, 
        "query": {         
            "rescore_query": {
                "match_phrase": {
                    "title": {
                        "query": "quick brown fox",
                        "slop":  50
                    }
                }
            }
        }
    }
}

COPY AS CURLVIEW IN SENSE 

	match query는 어떤 결과가 최종 결과 집합에 포함될 것인지를 결정하고, 순위는 TF/IDF에 따른다.
	windows_size 는 shard별로 rescore할 상위 결과의 수이다.
	현재 지원되는 유일한 rescoring algorithm은 또 다른 query이지만, 추후에 다른 algorithm을 추가할 계획이 있다.