2-5-2. prefix Query

To find all postcodes beginning with W1, we could use a simple prefix query:

W1 로 시작하는 우편번호를 검색하기 위해, 간단한 prefix query를 사용할 수 있다.

GET /my_index/address/_search
{
    "query": {
        "prefix": {
            "postcode": "W1"
        }
    }
}

COPY AS CURLVIEW IN SENSE 

The prefix query is a low-level query that works at the term level. It doesn’t analyze the query string before searching. It assumes that you have passed it the exact prefix that you want to find.

prefix query는 단어 단계에서 동작하는 low-level query이다. 검색하기 전에 query string을 분석하지 않는다. 검색하려는 정확한 prefix를 넘겼다고 가정한다.

By default, the prefix query does no relevance scoring. It just finds matching documents and gives them all a score of 1. Really, it behaves more like a filter than a query. The only practical difference between the prefix query and the prefix filter is that the filter can be cached.

기본적으로, prefix query는 relevance score를 계산하지 않는다. 단지, 일치하는 document를 찾고, 그들 모두에게 score 1 을 준다. 실제로 query보다 filter에 더 가깝게 동작한다. prefix query와 prefix filter의 유일한 실질적인 차이점은 filter는 cache된다는 점이다.

Previously, we said that "you can find only terms that exist in the inverted index", but we haven’t done anything special to index these postcodes; each postcode is simply indexed as the exact value specified in each document. So how does the prefix query work?

이전에, "inverted index에 존재하는 단어만을 검색할 수 있다" 라고 언급한 바 있다. 그러나, 이런 우편번호를 색인 하기 위해, 특별히 어떤 것도 한 적이 없다. 각 우편번호는 각 document에서 지정된 exact value로 단순히 색인되었다. 그러면, 어떻게 prefix query가 동작할까?

Remember that the inverted index consists of a sorted list of unique terms (in this case, postcodes). For each term, it lists the IDs of the documents containing that term in the postings list. The inverted index for our example documents looks something like this:

inverted index는 유일한 단어(이 경우에는 우편번호)의 정렬된 목록으로 구성되어 있다는 것을 기억하자. 각 단어에 대해, 우편번호 목록 에서 해당 단어를 포함하고 있는 document의 ID를 나열하고 있다. 예제 document의 inverted index는 아래처럼 보일 것이다.

Term:          Doc IDs:
-------------------------
"SW5 0BE"    |  5
"W1F 7HW"    |  3
"W1V 3DG"    |  1
"W2F 8HW"    |  2
"WC1N 1LZ"   |  4
-------------------------

To support prefix matching on the fly, the query does the following:

prefix 일치를 제공하기 위해, query는

1. Skips through the terms list to find the first term beginning with W1.

   W1 로 시작하는 첫 번째 단어를 찾아, 단어 목록을 건너 뛴다.

2. Collects the associated document IDs.

   관련된 document ID를 모은다.

3. Moves to the next term.

   다음 단어로 이동한다.

4. If that term also begins with W1, the query repeats from step 2; otherwise, we’re finished.

   해당 단어가 W1 로 시작한다면, 2 단계를 반복한다. 그렇지 않으면 끝낸다.

While this works fine for our small example, imagine that our inverted index contains a million postcodes beginning with W1. The prefix query would need to visit all one million terms in order to calculate the result!

이것은 이 작은 예제에서는 잘 동작하겠지만, inverted index가 W1 으로 시작하는 백만 건의 우편번호를 가지고 있다고 가정해 보자. prefix query는 결과를 계산하기 위해 백만 단어 모두를 확인해야 한다.

And the shorter the prefix, the more terms need to be visited. If we were to look for the prefix Winstead of W1, perhaps we would match 10 million terms instead of just one million.

그리고 prefix가 더 짧다면, 더 많은 단어를 확인해야 한다. W1 대신에 prefix W 를 찾는다면, 아마도 백만 건이 아닌 천만 건을 찾을 것이다.

The prefix query or filter are useful for ad hoc prefix matching, but should be used with care. They can be used freely on fields with a small number of terms, but they scale poorly and can put your cluster under a lot of strain. Try to limit their impact on your cluster by using a long prefix; this reduces the number of terms that need to be visited.

prefix query나 filter는 즉석 prefix 일치에 유용하지만, 주의해서 사용해야 한다. 그들은 작은 수의 단어를 가진 field에 대해서는 마음놓고 사용할 수 있지만, 확장성이 좋지 않고, cluster에 많은 부하를 줄 수 있다. 긴 prefix를 사용함으로써, 그들이 cluster에 영향을 주는 것을 제한해야 한다. 긴 prefix는 확인해야 할 단어의 수를 줄인다.

Later in this chapter, we present an alternative index-time solution that makes prefix matching much more efficient. But first, we’ll take a look at two related queries: the wildcard and regexp queries.

나중에 이 장에서, 훨씬 더 효율적으로 prefix 일치를 할 수 있는, 대체 가능한 index-time solution을 살펴볼 것이다. 그러나 먼저, 관련된 2개의 query, wildcard 와 regexp query를 살펴 보도록 하자.