v2.0-06. Query DSL changes

Queries and filters mergededit

Queries and filters have been merged — all filter clauses are now query clauses. Instead, query clauses can now be used in query context or in filter context:

query와 filter는 통합되었다. 모든 filter절은 이제 query절이다. 대신, 이제 query절은 query context 나 filter context 에서 사용된다.

Query context

A query used in query context will calculate relevance scores and will not be cacheable. Query context is used whenever filter context does not apply.

query context에서 사용되는 query는 relevance score를 계산하고, cache되지 않는다. query context는 filter context가 적용되지 않는 경우에 사용된다.

Filter context

A query used in filter context will not calculate relevance scores, and will be cacheable. Filter context is introduced by:

filter context에서 사용되는 query는 relevance score를 계산하지 않고, cache된다. filter context는 다음과 같은 경우에서 볼 수 있다.

• the constant_score query

• the must_not and (newly added) filter parameter in the bool query

  bool query에서 must_not 과 (새로 추가된) filter parameter

• the filter and filters parameters in the function_score query

  function_score query에서 filter 와 filters parameter

• any API called filter, such as the post_filter search parameter, or in aggregations or index aliases

  post_filter search parameter 처럼 filter 라 불리는 모든 API, 또는 aggregation, index alias에서

terms query and filteredit

The execution option of the terms filter is now deprecated and is ignored if provided. Similarly, the terms query no longer supports the minimum_should_match parameter.

terms filter의 execution option은 이제 deprecate되었고, 주어지더라도 무시된다. 마찬가지로, termsquery는 minimum_should_match 매개변수를 더 이상 지원하지 않는다.

or and and now implemented via booledit

The or and and filters previously had a different execution pattern to the bool filter. It used to be important to use and/or with certain filter clauses, and bool with others.

이전 버전에서, or 와 and filter는 bool filter에서 다른 실행 pattern을 가지고 있었다. and/or 를 특정 filter 절과 사용하고, bool 을 다른 filter와 사용하는 것이 중요했다.

This distinction has been removed: the bool query is now smart enough to handle both cases optimally. As a result of this change, the or and and filters are now sugar syntax which are executed internally as a bool query. These filters may be removed in the future.

이러한 차이점은 제거되었다. bool query는 이제 두 가지 경우 모두를 최적으로 다룰 수 있을 만큼 충분히 smart하다. 이 변경의 결과로, or 와 and filter는 이제 내부적으로 bool query로 실행되는 문법이다. 이들 filter는 향후에 제거될 것이다.

filtered query and query filter deprecatededit

The query filter is deprecated as is it no longer needed — all queries can be used in query or filter context.

query filter는 더 이상 필요하지 않아 deprecate되었다. 모든 query는 query나 filter context에서 사용될 수 있다.

The filtered query is deprecated in favour of the bool query. Instead of the following:

filtered query는 bool query로 대체되고, deprecate되었다. 다음의 예는

GET _search
{
  "query": {
    "filtered": {
      "query": {
        "match": {
          "text": "quick brown fox"
        }
      },
      "filter": {
        "term": {
          "status": "published"
        }
      }
    }
  }
}

move the query and filter to the must and filter parameters in the bool query:

query와 filter는 bool query의 must 와 filter 매개변수로 옮겨진다.

GET _search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "text": "quick brown fox"
        }
      },
      "filter": {
        "term": {
          "status": "published"
        }
      }
    }
  }
}

Filter auto-cachingedit

It used to be possible to control which filters were cached with the _cache option and to provide a custom _cache_key. These options are deprecated and, if present, will be ignored.

_cache option과 사용자 정의 _cache_key 를 이용하여 filter의 cache 여부를 제어하는 것이 가능했었다. 이들 option은 deprecate되었고, 만약 있어도, 무시된다.

Query clauses used in filter context are now auto-cached when it makes sense to do so. The algorithm takes into account the frequency of use, the cost of query execution, and the cost of building the filter.

filter context에서 사용되는 query 절은 그렇게 하는 것이 의미가 있을 경우, 자동으로 cache된다. 이 알고리즘은 사용 빈도, query 실행 비용, filter 생성 비용을 고려한다.

The terms filter lookup mechanism no longer caches the values of the document containing the terms. It relies on the filesystem cache instead. If the lookup index is not too large, it is recommended to replicate it to all nodes by setting index.auto_expand_replicas: 0-all in order to remove the network overhead as well.

terms filter의 검색 mechanism은 terms를 포함하고 있는 document의 값을 더 이상 cache하지 않는다. 대신 filesystem cache에 의존한다. 검색 index가 너무 크지 않다면, network overhead를 줄이기 위해index.auto_expand_replicas: 0-all 을 설정하여, 모든 node에 해당 index를 replicate하는 것을 권장한다.

Numeric queries use IDF for scoringedit

Previously, term queries on numeric fields were deliberately prevented from using the usual Lucene scoring logic and this behaviour was undocumented and, to some, unexpected.

이전 버전에서, numeric field에 대한 term query는 일반적인 Lucene scoring 로직의 사용을 의도적으로 막았었고, 이런 방식은 문서화하지 않았었다.

Single term queries on numeric fields now score in the same way as string fields, using IDF and norms (if enabled).

이제, numeric field에 대한 단일 term query는 string field와 동일한 방식으로 IDF와 norms(만약 활성화되어 있다면)를 사용하여, score를 계산한다.

To query numeric fields without scoring, the query clause should be used in filter context, e.g. in the filter parameter of the bool query, or wrapped in a constant_score query:

scoring 없이 numeric field를 query하려면, query절은 filter context, 예를 들어, bool query에서 filterparameter 또는 constant_score query로 감싼 곳에서 사용되어야 한다.

GET _search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": { 
            "numeric_tag": 5
          }
        }
      ],
      "filter": [
        {
          "match": { 
            "count": 5
          }
        }
      ]
    }
  }
}

	이 절은 relevance score 계산시 IDF를 포함한다.
	이 절은 relevance score 계산과 무관하다.

Fuzziness and fuzzy-like-thisedit

Fuzzy matching used to calculate the score for each fuzzy alternative, meaning that rare misspellings would have a higher score than the more common correct spellings. Now, fuzzy matching blends the scores of all the fuzzy alternatives to use the IDF of the most frequently occurring alternative.

fuzzy matching은 각 fuzzy의 alternative에 대한 score를 계산하는데 사용되었다. 이것은 드문 오자(誤字, misspellings)가 다수의 일반적으로 정확한 철자보다 더 높은 score를 가진다는 것을 의미한다. 이제 fuzzy matching은 가장 빈번하게 나타나는 alternative의 IDF를 사용하여, 모든 fuzzy alternative의 score를 조합한다.

Fuzziness can no longer be specified using a percentage, but should instead use the number of allowed edits:

fuzziness는 더 이상 percentage를 사용하여 지정할 수 없고, 대신 허용되는 숫자를 사용해야 한다.

• 0, 1, 2, or

• AUTO (which chooses 0, 1, or 2 based on the length of the term)

  AUTO (term의 길이에 따라, 0, 1 또는 2 를 선택)

The fuzzy_like_this and fuzzy_like_this_field queries used a very expensive approach to fuzzy matching and have been removed.

fuzzy_like_this 와 fuzzy_like_this_field query는 fuzzy matching에 매우 비싼 접근 방식을 사용했기에 제거되었다.

More Like Thisedit

The More Like This (mlt) API and the more_like_this_field (mlt_field) query have been removed in favor of the more_like_this query.

more_like_this query를 위하여, More Like This(mlt) API와 more_like_this_field(mlt_field) query는 제거되었다.

The parameter percent_terms_to_match has been removed in favor of minimum_should_match.

minimum_should_match 를 위하여 percent_terms_to_match parameter는 제거되었다.

limit filter deprecatededit

The limit filter is deprecated and becomes a no-op. You can achieve similar behaviour using the terminate_after parameter.

limit filter는 deprecate되었고, 더 이상 동작하지 않는다. terminate_after parameter를 사용하여 유사한 효과를 얻을 수 있다.

Java plugins registering custom queriesedit

Java plugins that register custom queries can do so by using theIndicesQueriesModule#addQuery(Class<? extends QueryParser>) method. Other ways to register custom queries are not supported anymore.

사용자 정의 query를 등록하는 java plugin은 IndicesQueriesModule#addQuery(Class<? extends QueryParser>) method를 사용하여 할 수 있다. 사용자 정의 query를 등록하는 다른 방법은 이제 지원되지 않는다.