1-06. Mapping and Analysis

While playing around with the data in our index, we notice something odd. Something seems to be broken: we have 12 tweets in our indices, and only one of them contains the date 2014-09-15, but have a look at the total hits for the following queries:

index에 있는 데이터를 살펴보다 보면, 이상한 점을 발견할 수 있다. 뭔가 깨진 것 같다. index에는 12개의 tweet이 있다. 그 중의 단 하나만 2014-09-15 를 포함하고 있다. 그런데 아래 query의 total hits를 보면

GET /_search?q=2014              # 12 results
GET /_search?q=2014-09-15        # 12 results !
GET /_search?q=date:2014-09-15   # 1  result
GET /_search?q=date:2014         # 0  results !

COPY AS CURLVIEW IN SENSE 

Why does querying the _all field for the full date return all tweets, and querying the date field for just the year return no results? Why do our results differ when searching within the _all field or the date field?

_all field에 대해, 전체 날짜를 query했는데, 왜 모든 tweet을 반환하는가? date field를 년도로만 query했는데 왜 아무런 결과도 반환하지 않는가? _all field와 date field를 검색했을 때, 결과가 왜 다른가?

Presumably, it is because the way our data has been indexed in the _all field is different from how it has been indexed in the date field. So let’s take a look at how Elasticsearch has interpreted our document structure, by requesting the mapping (or schema definition) for the tweet type in the gbindex:

아마도, 데이터를 _all field에 색인하는 방법이, date field에 색인하는 방법과 다르기 때문일 것이다. gbindex의 tweet type의 mapping (또는 schema 정의)을 request하여, Elasticsearch가 document 구조를 해석하는 방법을 살펴보자.

GET /gb/_mapping/tweet

COPY AS CURLVIEW IN SENSE 

This gives us the following:

결과는 아래와 같다.

{
   "gb": {
      "mappings": {
         "tweet": {
            "properties": {
               "date": {
                  "type": "date",
                  "format": "strict_date_optional_time||epoch_millis"
               },
               "name": {
                  "type": "string"
               },
               "tweet": {
                  "type": "string"
               },
               "user_id": {
                  "type": "long"
               }
            }
         }
      }
   }
}

Elasticsearch has dynamically generated a mapping for us, based on what it could guess about our field types. The response shows us that the date field has been recognized as a field of type date. The _all field isn’t mentioned because it is a default field, but we know that the _all field is of type string.

Elasticsearch는 field type을 추측하여, mapping을 동적으로 생성한다. response는 date field가 datetype의 field로 인식된다는 것을 나타낸다. _all field는 default field이기 때문에 언급되지 않는다. 그러나 _all field가 string type인 것을 알고 있다.

So fields of type date and fields of type string are indexed differently, and can thus be searched differently. That’s not entirely surprising. You might expect that each of the core data types—strings, numbers, Booleans, and dates—might be indexed slightly differently. And this is true: there are slight differences.

따라서, date type의 field와 string type의 field는 다르게 색인 된다. 따라서 다르게 검색될 수 있다. 놀라운 일도 아니다. 기본(core) 데이터 type(string, number, Boolean, date) 각각은 약간 다르게 색인된다는 것을 예상할 수 있다. 그리고 이것은 사실이다.(약간의 차이가 있다.)

But by far the biggest difference is between fields that represent exact values (which can include string fields) and fields that represent full text. This distinction is really important—it’s the thing that separates a search engine from all other databases.

그러나, 지금까지의 가장 큰 차이점은 exact value (string field를 포함할 수 있다)를 나타내는 field와, full text 를 나타내는 field의 차이이다. 이 차이점은 매우 중요하다. 다른 모든 데이터베이스와 검색 엔진을 구분하는 점이다.