1-05-4. Search Lite

There are two forms of the search API: a "lite" query-string version that expects all its parameters to be passed in the query string, and the full request body version that expects a JSON request body and uses a rich search language called the query DSL.

search API에는 두 가지 형식이 있다. 하나는 query-string 의 "아류(lite)" 버전이다. 이 버전은 모든 매개변수가 query string에 전달된다. 다른 하나는 full request body 버전이다. 이 버전은 JSON request body를 사용하고, query DSL이라 불리는 풍부한 검색 언어를 사용한다.

The query-string search is useful for running ad hoc queries from the command line. For instance, this query finds all documents of type tweet that contain the word elasticsearch in the tweet field:

query-string 검색은 command line에서, 바로 query를 실행하는데 유용하다. 예를 들면, 아래 query는 tweet field에 elasticsearch 라는 단어를 포함하고 있는, tweet type의 모든 document를 검색한다.

GET /_all/tweet/_search?q=tweet:elasticsearch

COPY AS CURLVIEW IN SENSE 

The next query looks for john in the name field and mary in the tweet field. The actual query is just

다음 query는 name field의 john 과 tweet field의 mary 를 찾는다. 실제 query는 아래이다.

+name:john +tweet:mary

but the percent encoding needed for query-string parameters makes it appear more cryptic than it really is:

그러나, query-string 매개변수에 필요한 percent encoding 으로 인해, 실제보다 더 어렵게 보인다.

GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary

COPY AS CURLVIEW IN SENSE 

The + prefix indicates conditions that must be satisfied for our query to match. Similarly a - prefix would indicate conditions that must not match. All conditions without a + or - are optional—the more that match, the more relevant the document.

+ 접두어는 query에 반드시 일치해야 하는 조건을 나타낸다. 유사하게, - 접두어는 반드시 일치하지 않아야 하는 조건을 나타낸다. + 나 - 이 없는, 모든 조건은 선택적이다. 더 많이 일치할수록 더 관련 있는 document가 된다.

The _all Fieldedit

This simple search returns all documents that contain the word mary:

아래의 간단한 search는 mary 라는 단어를 포함하는 모든 document를 반환한다.

GET /_search?q=mary

COPY AS CURLVIEW IN SENSE 

In the previous examples, we searched for words in the tweet or name fields. However, the results from this query mention mary in three fields:

이전의 예에서, tweet 이나 name field에서 단어를 검색했다. 그러나, 이 query의 결과는 3개의 다른 field에서 mary 를 언급한다.

• A user whose name is Mary

  사용자의 이름(name)이 Mary이다.

• Six tweets by Mary

  Mary가 6번 tweet했다.

• One tweet directed at @mary

  누군가가 @Mary를 tweet했다.

How has Elasticsearch managed to find results in three different fields?

3개의 다른 field에서 결과를 찾기 위해 Elasticsearch는 어떻게 할까?

When you index a document, Elasticsearch takes the string values of all of its fields and concatenates them into one big string, which it indexes as the special _all field. For example, when we index this document:

document를 색인할 때, Elasticsearch는 모든 field의 문자열 값을 가져와, 하나의 큰 문자열로 만들어, 특별히 _all field에 색인 한다. 예를 들어, 아래 document를 색인 했을 경우,

{
    "tweet":    "However did I manage before Elasticsearch?",
    "date":     "2014-09-14",
    "name":     "Mary Jones",
    "user_id":  1
}

it’s as if we had added an extra field called _all with this value:

그것은 아래 값을 가진 _all 이라 불리는 추가 field를 추가한 것처럼 보인다.

"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1"

The query-string search uses the _all field unless another field name has been specified.

query-string 검색은 다른 field 이름이 지정되지 않으면, _all field를 사용한다.

The _all field is a useful feature while you are getting started with a new application. Later, you will find that you have more control over your search results if you query specific fields instead of the _all field. When the _all field is no longer useful to you, you can disable it, as explained in Metadata: _all Field.

새로운 응용프로그램을 시작하는 경우에, _all field는 유용한 기능이다. 나중에, _all field 대신 특정 field를 query하면, 검색 결과를 보다 효율적으로 제어할 수 있음을 알게 될 것이다. _all field가 더 이상 필요 없다면, Metadata: _all Field에서 설명하겠지만, 비활성화할 수 있다.

More Complicated Queriesedit

The next query searches for tweets, using the following criteria:

다음 query는 아래 조건을 사용해, tweet을 검색한다.

• The name field contains mary or john

  mary 나 john 을 포함하고 있는 name field

• The date is greater than 2014-09-10

  date 가 2014-09-14 보다 큰

• The _all field contains either of the words aggregations or geo

  단어 aggregations 또는 geo 를 포함하는 _all field

+name:(mary john) +date:>2014-09-10 +(aggregations geo)

COPY AS CURLVIEW IN SENSE 

As a properly encoded query string, this looks like the slightly less readable result:

encoding된 query string은 조금 읽기 어렵다.

?q=%2Bname%3A(mary+john)+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo)

As you can see from the preceding examples, this lite query-string search is surprisingly powerful. Its query syntax, which is explained in detail in the Query String Syntax reference docs, allows us to express quite complex queries succinctly. This makes it great for throwaway queries from the command line or during development.

위의 예에서 볼 수 있듯이, lite query-string 검색은 놀라울 정도로 강력하다. Query String Syntax 참고 문서에 자세히 설명되어 있지만, 이것의 query 문법은 매우 복잡한 query를 간단하게 표현할 수 있다. command line에서 또는 개발 중일 때, 일회용 query에 아주 좋다.

However, you can also see that its terseness can make it cryptic and difficult to debug. And it’s fragile—a slight syntax error in the query string, such as a misplaced -, :, /, or ", and it will return an error instead of results.

그러나, 그 간결함이, debug를 아리송하고 복잡하게 만들 수 있다. -, :, /, " 를 올바르게 사용하지 않은 경우처럼, query string에 약간의 문법 error가 있으면, 결과 대신에 에러를 반환한다.

Finally, the query-string search allows any user to run potentially slow, heavy queries on any field in your index, possibly exposing private information or even bringing your cluster to its knees!

마지막으로, query-string 검색은 어떤 사용자에게는, index의 모든 field에 대해 잠재적으로 느리고 무거운 query가 될 수 있다. 개인정보를 노출하거나, 심지어 cluster를 내릴 수도 있다.

For these reasons, we don’t recommend exposing query-string searches directly to your users, unless they are power users who can be trusted with your data and with your cluster.

이런 이유 때문에, 데이터와 cluster를 맡길 수 있는 power user가 아니라면, query-string 검색을 사용자에게 직접적으로 노출하는 것을 권장하지 않는다.

Instead, in production we usually rely on the full-featured request body search API, which does all of this, plus a lot more. Before we get there, though, we first need to take a look at how our data is indexed in Elasticsearch.

대신에, 실전에서는, 일반적으로 모든 기능을 갖춘 request body 검색 API를 사용한다. 이것은 위의 모든 것을 할 수 있고, 훨씬 더 많은 것을 할 수 있다. 그것을 하기 전에, 먼저 데이터를 Elasticsearch에 색인 하는 방법을 살펴봐야 한다.