2-5-3. wildcard and regexp Queries

The wildcard query is a low-level, term-based query similar in nature to the prefix query, but it allows you to specify a pattern instead of just a prefix. It uses the standard shell wildcards: ?matches any character, and * matches zero or more characters.

wildcard query는 prefix query와 근본적으로 유사한 low-level의 단어 기반의 query이다. 그러나, 이것은 단지 prefix가 아닌 pattern을 지정할 수 있다. 이것은 표준 shell wildcard를 사용한다. ? 는 모든 문자와 일치하고, * 는 0개 이상의 문자와 일치한다.

This query would match the documents containing W1F 7HW and W2F 8HW:

아래 query는 W1F 7HW 그리고 W2F 8HW 를 포함하는 document와 일치할 것이다.

GET /my_index/address/_search
{
    "query": {
        "wildcard": {
            "postcode": "W?F*HW" 
        }
    }
}

COPY AS CURLVIEW IN SENSE 

? 는 1 과 2 에 일치하고, 반면에 * 는 공백, 7, 8 에 일치한다.

Imagine now that you want to match all postcodes just in the W area. A prefix match would also include postcodes starting with WC, and you would have a similar problem with a wildcard match. We want to match only postcodes that begin with a W, followed by a number. The regexp query allows you to write these more complicated patterns:

이제, W 지역(area)에 있는 모든 우편번호와 일치하기를 원한다고 가정해 보자. prefix 일치는 WC 로 시작하는 우편번호도 포함할 것이다. 그리고 wildcard 일치와 유사한 문제를 가지게 될 것이다. 숫자가 따라오는 W 로 시작하는 우편번호만 일치하기를 원한다. regexp query는 이런 더 복잡한 pattern을 가능하게 한다.

GET /my_index/address/_search
{
    "query": {
        "regexp": {
            "postcode": "W[0-9].+" 
        }
    }
}

COPY AS CURLVIEW IN SENSE 

정규식에 의해, 단어는 W 로 시작해야 하고, 0 ~ 9 사이의 숫자가 뒤따라야 하고, 하나 이상의 문자가 뒤따라야 한다.

The wildcard and regexp queries work in exactly the same way as the prefix query. They also have to scan the list of terms in the inverted index to find all matching terms, and gather document IDs term by term. The only difference between them and the prefix query is that they support more-complex patterns.

wildcard 와 regexp query는 prefix query와 정확히 동일한 방식으로 동작한다. 그들은 일치하는 모든 단어를 찾기 위해, inverted index에서 단어의 목록을 검색하고, 단어 별로 document ID를 수집한다. 그들과 prefix query 사이의 유일한 차이점은 더 복잡한 pattern을 지원한다는 점이다.

This means that the same caveats apply. Running these queries on a field with many unique terms can be resource intensive indeed. Avoid using a pattern that starts with a wildcard (for example, *foo or, as a regexp, .*foo).

즉, 동일한 주의 사항이 적용된다. 많은 유일한 단어를 가진 field에 이 query를 실행하면, 매우 집중적인 자원 사용이 될 수 있다. wildcard로 시작하는(예: *foo 나 .*foo 같은 regexp) pattern의 사용을 피하는 것이 좋다.

Whereas prefix matching can be made more efficient by preparing your data at index time, wildcard and regular expression matching can be done only at query time. These queries have their place but should be used sparingly.

prefix 일치는 색인 시에 데이터를 준비할 때 더 효율적이지만, wildcard와 regexp 일치는 query 시에만 할 수 있다. 이러한 query는 적당히 드물게 사용해야 한다.

The prefix, wildcard, and regexp queries operate on terms. If you use them to query an analyzed field, they will examine each term in the field, not the field as a whole.

prefix, wildcard, regexp query는 단어를 기준으로 연산한다. 그들을, analyzed field를 query하는데 사용하면, 전체 field가 아닌, field의 각 단어를 확인한다.

For instance, let’s say that our title field contains "Quick brown fox" which produces the terms quick, brown, and fox.

예를 들어, "Quick brown fox" 를 포함하는 title field는 quick, brown, fox 라는 단어를 만들어 낸다.

This query would match:

아래 query는 일치할 것이다.

{ "regexp": { "title": "br.*" }}

But neither of these queries would match:

그러나, 아래 두 query 모두는 일치하지 않을 것이다.

{ "regexp": { "title": "Qu.*" }} 
{ "regexp": { "title": "quick br*" }} 

	index에 있는 단어는 Quick 이 아닌 quick 이다.
	quick 과 brown 은 별개의 단어이다.