1-10-07. The Root Object

The uppermost level of a mapping is known as the root object. It may contain the following:

mapping의 최상위 단계는 root object 로 알려져 있다. 아래와 같은 것을 포함하고 있다.

• A properties section, which lists the mapping for each field that a document may contain

  document가 가지게 될, 각 field의 mapping을 나열하는 properties 부분.

• Various metadata fields, all of which start with an underscore, such as _type, _id, and _source

  _type, _id, _source 같은, _(underscore)로 시작하는, 다양한 metadata field.

• Settings, which control how the dynamic detection of new fields is handled, such as analyzer, dynamic_date_formats, and dynamic_templates

  analyzer, dynalmic_date_formats, dynamic_templates 같은, 새로운 field의 동적 발견을 처리하는 방법을 제어할 설정.

• Other settings, which can be applied both to the root object and to fields of type object, such as enabled, dynamic, and include_in_all

  root 오브젝트와 enabled, dynamic, include_in_all 같은, object type의 field 모두에 적용되는 다른 설정.

Propertiesedit

We have already discussed the three most important settings for document fields or properties in Core Simple Field Types and Complex Core Field Types:

Core Simple Field Types와 Complex Core Field Types에서, document의 field나 properties를 위한, 가장 중요한 설정 3가지를 이미 언급한 바 있다.

type

The datatype that the field contains, such as string or date

string 또는 date 같은, field가 가지고 있는 데이터 type

index

Whether a field should be searchable as full text (analyzed), searchable as an exact value (not_analyzed), or not searchable at all (no)

field가 full text(analyzed)로 검색 가능한지, exact value(not_analyzed)로 검색 검색 가능한지, 전혀 검색되지 않을지(no)

analyzer

Which analyzer to use for a full-text field, both at index time and at search time

색인 시와 검색 시에, full-text field에 사용할 analyzer

We will discuss other field types such as ip, geo_point, and geo_shape in the appropriate sections later in the book.

나중에, 이 책의 적절한 부분에서, ip, get_point 그리고 geo_shape 같은, 다른 field type을 이야기할 것이다.

Metadata: _source Fieldedit

By default, Elasticsearch stores the JSON string representing the document body in the _source field. Like all stored fields, the _source field is compressed before being written to disk.

기본적으로, Elasticsearch는, _source field에 document의 body를 나타내는 JSON 문자열을 저장한다. 모든 저장되는 field와 마찬가지로, _source field는 디스크에 기록되기 전에 압축된다.

This is almost always desired functionality because it means the following:

이것은 다음과 같은 이유 때문에, 거의 항상 요구되는 기능이다.

• The full document is available directly from the search results—no need for a separate round-trip to fetch the document from another data store.

  전체 document는 검색 결과에서 바로 이용가능하다. 다른 데이터 저장소에서 document를 가져오기 위한, 또 다른 동작이 불필요하다.

• Partial update requests will not function without the _source field.

  부분적인 update request는, _source field 없이 동작하지 않는다.

• When your mapping changes and you need to reindex your data, you can do so directly from Elasticsearch instead of having to retrieve all of your documents from another (usually slower) data store.

  mapping이 변경되면 데이터를 다시 색인해야 한다. 다른 데이터 저장소(일반적으로 더 느린)에서 document 모두를 가져오는 대신 Elasticsearch에서 바로 가능하다.

• Individual fields can be extracted from the _source field and returned in get or searchrequests when you don’t need to see the whole document.

  개별 field는 _source field에서 추출할 수 있고, 전체 document가 필요하지 않은 경우에는 get 이나 search request로 반환될 수 있다.

• It is easier to debug queries, because you can see exactly what each document contains, rather than having to guess their contents from a list of IDs.

  ID의 목록에서 그것의 내용을 추측하는 것이 아니라, 각 document에 무엇이 포함되어 있는지 정확히 알 수 있기 때문에, query를 debug하기가 더 쉽다.

That said, storing the _source field does use disk space. If none of the preceding reasons is important to you, you can disable the _source field with the following mapping:

그렇지만, _source field를 저장하는 것은 디스크 공간을 사용하는 것이다. 위의 여러 가지 이유가 중요하지 않다면, 다음 mapping처럼 _source field를 비활성화 할 수 있다.

PUT /my_index
{
    "mappings": {
        "my_type": {
            "_source": {
                "enabled":  false
            }
        }
    }
}

In a search request, you can ask for only certain fields by specifying the _source parameter in the request body:

검색 request에서, request body에 _source 매개변수를 지정하여, 특정 field만을 요청할 수 있다.

GET /_search
{
    "query":   { "match_all": {}},
    "_source": [ "title", "created" ]
}

COPY AS CURLVIEW IN SENSE 

Values for these fields will be extracted from the _source field and returned instead of the full _source.

이들 field의 값은 _source field에서 추출되고, 전체 _source 대신 반환된다.

저장된 field

Besides indexing the values of a field, you can also choose to store the original field value for later retrieval. Users with a Lucene background use stored fields to choose which fields they would like to be able to return in their search results. In fact, the _source field is a stored field.

field의 값을 색인 하는 것 외에도, 나중에 가져오기 위해, 원래의 field 값을 저장(store) 하는 것을 선택할 수도 있다. background로 Lucene을 이용하는 사용자들은, 검색 결과를 반환할 수 있도록 하기 위해, 특정 field를 선택하여, 저장된 field로 사용한다. 사실, _source field는 저장된 field이다.

In Elasticsearch, setting individual document fields to be stored is usually a false optimization. The whole document is already stored as the _source field. It is almost always better to just extract the fields that you need by using the _source parameter.

Elasticsearch에서, 저장될 개별 document의 field를 설정하는 것은, 일반적으로 잘못된 최적화이다. 전체 document는 이미 _source field에 저장되어 있다. _source 매개변수를 사용해, 필요한 field를 추출하는 것이, 거의 항상 더 낫다.

Metadata: _all Fieldedit

In Search Lite, we introduced the _all field: a special field that indexes the values from all other fields as one big string. The query_string query clause (and searches performed as ?q=john) defaults to searching in the _all field if no other field is specified.

Search Lite에서 _all field(하나의 아주 큰 문자열로서, 다른 모든 field의 값을 색인하는 특별한 field)를 소개했었다. query 절의 query_string 은(그리고 ?q=john 로 검색울 수행하는 것), 기본적으로 다른 field가 지정되지 않으면, _all field를 검색한다.

The _all field is useful during the exploratory phase of a new application, while you are still unsure about the final structure that your documents will have. You can throw any query string at it and you have a good chance of finding the document you’re after:

_all field는 document가 가지고 있는 최종적 구조를 확신할 수 없을 때, 새로운 응용프로그램의 탐색 단계에서 유용하다. _all field에 어떤 query string이라도 던질 수 있고, 나중에 document를 찾을 좋은 기회이다.

GET /_search
{
    "match": {
        "_all": "john smith marketing"
    }
}

As your application evolves and your search requirements become more exacting, you will find yourself using the _all field less and less. The _all field is a shotgun approach to search. By querying individual fields, you have more flexbility, power, and fine-grained control over which results are considered to be most relevant.

응용프로그램이 발전하고 검색 request가 더 명확해짐에 따라, _all field를 점점 덜 사용하게 될 것이다. _all field는 검색을 한 방에 해결하는 접근 방식이다. 개별 field를 query하면, 더 많은 유연성, 힘 그리고 가장 관련 있을 것으로 간주되는 결과에 대한 세밀한 제어를 할 수 있다.

One of the important factors taken into account by the relevance algorithm is the length of the field: the shorter the field, the more important. A term that appears in a short title field is likely to be more important than the same term that appears somewhere in a long content field. This distinction between field lengths disappears in the _all field.

relevance 알고리즘에 의해 고려되는, 중요한 요소 중 하나는 field의 길이이다. field가 짧을수록 더 중요하다. 짧은 title field에 나타나는 어떤 단어는, 긴 content field 어딘가에서 나타나는 동일한 단어보다 더 중요하다고 간주된다. field 길이 사이의 이 차이점은 _all field에서는 아무런 의미가 없다.

If you decide that you no longer need the _all field, you can disable it with this mapping:

더 이상 _all field가 필요 없다고 판단이 되면, mapping에서 비활성화할 수 있다.

PUT /my_index/_mapping/my_type
{
    "my_type": {
        "_all": { "enabled": false }
    }
}

Inclusion in the _all field can be controlled on a field-by-field basis by using the include_in_allsetting, which defaults to true. Setting include_in_all on an object (or on the root object) changes the default for all fields within that object.

_all field에 포함되는 filed는, include_in_all 설정을 사용하여, field 단위로 제어할 수 있다. 기본값은 true 이다. 오브젝트 또는 root 오브젝트에 include_in_all 을 설정하는 것은, 해당 오브젝트내의 모든 field의 기본값을 변경하는 것이다.

You may find that you want to keep the _all field around to use as a catchall full-text field just for specific fields, such as title, overview, summary, and tags. Instead of disabling the _all field completely, disable include_in_all for all fields by default, and enable it only on the fields you choose:

title, overview, summary, tag 같은 특정 field를 범용 full-text field로 사용하기 위해, _all filed를 유지하려 할 수도 있다. _all field를 완전히 비활성화하는 대신에, 기본적으로 모든 field에 include_in_all 을 비활성하고, 선택한 field만 활성화한다.

PUT /my_index/my_type/_mapping
{
    "my_type": {
        "include_in_all": false,
        "properties": {
            "title": {
                "type":           "string",
                "include_in_all": true
            },
            ...
        }
    }
}

Remember that the _all field is just an analyzed string field. It uses the default analyzer to analyze its values, regardless of which analyzer has been set on the fields where the values originate. And like any string field, you can configure which analyzer the _all field should use:

_all field는 분석된 string field라는 점을 기억하자. 원래의 값이 있던 field에 어떤 analyzer가 설정되어 있더라도, _all field의 값을 분석하기 위해 기본 analyzer를 사용한다. 하지만, 다른 string field와 마찬가지로, _all field에 사용하고자 하는 analyzer를 설정할 수 있다.

PUT /my_index/my_type/_mapping
{
    "my_type": {
        "_all": { "analyzer": "whitespace" }
    }
}

Metadata: Document Identityedit

There are four metadata fields associated with document identity:

document의 구분과 관련된 4개의 metadata field가 있다.

_id

The string ID of the document

document의 문자열 ID

_type

The type name of the document

document의 type 이름

_index

The index where the document lives

document가 존재하는 index

_uid

The _type and _id concatenated together as type#id

_type 과 _id 를 함께 연결, type#id

By default, the _uid field is stored (can be retrieved) and indexed (searchable). The _type field is indexed but not stored, and the _id and _index fields are neither indexed nor stored, meaning they don’t really exist.

기본적으로, _uid field는 저장(가져올 수 있다)되고, 색인(검색할 수 있다)된다. _type field는 색인되지만, 저장되지 않는다. _id 와 _index field는 저장되지도, 색인 되지도 않는다. 즉 실제로 존재하지 않는다.

In spite of this, you can query the _id field as though it were a real field. Elasticsearch uses the _uidfield to derive the _id. Although you can change the index and store settings for these fields, you almost never need to do so.

이럼에도 불구하고, _id field가 실제 field인 것처럼, query할 수 있다. Elasticsearch는 _id 를 유도하기 위해 _uid field를 사용한다. 이들 field에 대한, index 및 store 설정을 변경할 수 있지만, 거의 그렇게 할 필요가 없다.