v2.0-04. Mapping changes

A number of changes have been made to mappings to remove ambiguity and to ensure that conflicting mappings cannot be created.

모호함을 제거하고, mapping의 충돌이 일어나지 않도록 하기 위해, mapping에 많은 변경이 있었다.

One major change is that dynamically added fields must have their mapping confirmed by the master node before indexing continues. This is to avoid a problem where different shards in the same index dynamically add different mappings for the same field. These conflicting mappings can silently return incorrect results and can lead to index corruption.

주요 변경 사항 중의 하나는, 동적으로 추가된 field는 index되기 전에, master node가 그것의 mapping을 확인한다는 것이다. 이것은 동일한 index에 있는 다른 shard에, 동일한 field가 다른 mapping을 가지고 동적으로 추가되는 것을 방지한다. 이러한 mapping의 충돌은 에러없이 잘못된 결과를 반환하고, index의 손상을 일으킬 수 있다.

This change can make indexing slower when frequently adding many new fields. We are looking at ways of optimising this process but we chose safety over performance for this extreme use case.

이러한 변경은 자주 많은 새로운 field를 추가할 때, indexing을 느리게 할 수 있다. 우리는 이 과정을 최적화하는 방법을 찾고 있지만, 이러한 극단적인 사용 사례에 대해, 성능보다는 안전을 선택했다.

Conflicting field mappingsedit

Fields with the same name, in the same index, in different types, must have the same mapping, with the exception of the copy_to, dynamic, enabled, ignore_above, include_in_all, and propertiesparameters, which may have different settings per field.

동일한 index, 다른 type에서, 각 field가 다른 설정을 가지게 하는 copy_to, dynamic, enabled, ignore_above, include_in_all 그리고 properties 매개변수를 제외하면, 동일한 name을 가진 field는 동일한 mapping을 가져야 한다.

PUT my_index
{
  "mappings": {
    "type_one": {
      "properties": {
        "name": { 
          "type": "string"
        }
      }
    },
    "type_two": {
      "properties": {
        "name": { 
          "type":     "string",
          "analyzer": "english"
        }
      }
    }
  }
}

2개의 name field는 mapping이 충돌하기 때문에, Elastisearch가 시작되지 않는다.

Elasticsearch will not start in the presence of conflicting field mappings. These indices must be deleted or reindexed using a new mapping.

field mapping의 충돌이 있으면, Elasticsearch는 시작되지 않는다. 이런 index는 제거되거나 새로운 mapping을 사용하여 다시 index해야 한다.

The ignore_conflicts option of the put mappings API has been removed. Conflicts can’t be ignored anymore.

put mapping API의 ignore_conflicts 옵션은 제거되었다. 충돌은 더 이상 무시할 수 없다.

Fields cannot be referenced by short nameedit

A field can no longer be referenced using its short name. Instead, the full path to the field is required. For instance:

filed는 더 이상 short name으로 참조될 수 없다. 대신, field의 full path가 요구된다. 예를 들면

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "title":     { "type": "string" }, 
        "name": {
          "properties": {
            "title": { "type": "string" }, 
            "first": { "type": "string" },
            "last":  { "type": "string" }
          }
        }
      }
    }
  }
}

	이 field는 title 로 참조된다.
	이 field는 name.title 로 참조된다.

Previously, the two title fields in the example above could have been confused with each other when using the short name title.

이전 버전에서는, 위의 예제에 있는 2개의 title field는 short name인 title 을 사용할 경우, 서로 혼동될 수 있었다.

Type name prefix removededit

Previously, two fields with the same name in two different types could sometimes be disambiguated by prepending the type name. As a side effect, it would add a filter on the type name to the relevant query. This feature was ambiguous — a type name could be confused with a field name — and didn’t work everywhere e.g. aggregations.

이전 버전에서는, 2개의 다른 type에서 동일한 name을 가진 2개의 field는 type name을 덧붙여 분명하게 할 수 있었다. 더하여, 적절한 query에 type name으로 filter를 추가하는 효과가 있었다. 이 기능은 애매했고 - type name이 field name과 혼동될 수 있었다 -, 모든 곳에서 동작하지는 않았다. – aggregation 같은 곳에서는 …

Instead, fields should be specified with the full path, but without a type name prefix. If you wish to filter by the _type field, either specify the type in the URL or add an explicit filter.

대신, field는 type name을 덧붙이지 않고, full path로 지정해야 한다. _type field로 filter하려면, URL에 type을 지정하거나 명시적으로 filter를 추가해야 한다.

The following example query in 1.x:

1.x에서의 다음 예제 query는

GET my_index/_search
{
  "query": {
    "match": {
      "my_type.some_field": "quick brown fox"
    }
  }
}

would be rewritten in 2.0 as:

2.0에서 다음과 같이 다시 작성된다

GET my_index/my_type/_search 
{
  "query": {
    "match": {
      "some_field": "quick brown fox" 
    }
  }
}

	type name은 filter로서 동작하기 위해 URL에 지정될 수 있다.
	field name은 type 접두사 없이 지정해야 한다.

Field names may not contain dotsedit

In 1.x, it was possible to create fields with dots in their name, for instance:

1.x에서, field의 name에 dot(.)을 포함한 field를 생성하는 것이 가능했다. 예를 들자면

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "foo.bar": { 
          "type": "string"
        },
        "foo": {
          "properties": {
            "bar": { 
              "type": "string"
            }
          }
        }
      }
    }
  }
}

이들 2개의 field는 foo.bar 로 참조되어, 서로 구분할 수 없다.

You can no longer create fields with dots in the name.

더 이상 field의 name에 dot(.)을 포함한 field를 생성할 수 없다.

Type names may not start with a dotedit

In 1.x, Elasticsearch would issue a warning if a type name included a dot, e.g. my.type. Now that type names are no longer used to distinguish between fields in different types, this warning has been relaxed: type names may now contain dots, but they may not begin with a dot. The only exception to this is the special .percolator type.

1.x에서, type name에 dot(.)이 포함(예: my.type)되면, 경고가 발생한다. 이제, type name이 서로 다른 type에서 filed를 구분하는데 사용되지 않기 때문에, 이 경고는 발생하지 않는다. 이제 type name은 dot(.)을 포함할 수 있지만, dot(.)으로 시작 할 수는 없다. 이에 대한 유일한 예외는 .percolator type이다.

Type names may not be longer than 255 charactersedit

Mapping type names may not be longer than 255 characters. Long type names will continue to function on indices created before upgrade, but it will not be possible create types with long names in new indices.

mapping type name은 225자 이상을 지원하지 않는다. 긴 type name은 upgrade전에 생성된 index에는 계속 동작하지만, 새로운 index에 긴 name을 가진 type을 생성할 수는 없다.

Types may no longer be deletededit

In 1.x it was possible to delete a type mapping, along with all of the documents of that type, using the delete mapping API. This is no longer supported, because remnants of the fields in the type could remain in the index, causing corruption later on.

1.x에서, delete mapping API를 이용하여, 특정 type의 mapping과 해당 type의 모든 document를 함께 삭제하는 것이 가능하다. 이것은 더 이상 지원되지 않는다. 왜냐하면, type에 있는 field의 잔재가 index에 남아, 나중에 손상의 원인이 된다.

Instead, if you need to delete a type mapping, you should reindex to a new index which does not contain the mapping. If you just need to delete the documents that belong to that type, then use the delete-by-query plugin instead.

대신, type의 mapping을 삭제해야 한다면, mapping을 포함하지 않는 새로운 index에 다시 index해야 한다. 해당 type을 포함하는 document만 삭제해야 한다면, 대신에, delete-by-query plugin을 사용하자.

Type meta-fieldsedit

The meta-fields associated with had configuration options removed, to make them more reliable:

신뢰성을 높이기 위해, 설정 옵션과 관련된 meta-fields는 제거되었다.

• _id configuration can no longer be changed. If you need to sort, use the _uid field instead.

  _id 설정은 더 이상 변경될 수 없다. 정렬을 위해서라면, _uid field를 사용하자.

• _type configuration can no longer be changed.

  _type 설정은 더 이상 변경될 수 없다.

• _index configuration can no longer be changed.

  _index 설정은 더 이상 변경될 수 없다.

• _routing configuration is limited to marking routing as required.

  _routing 설정은, routing을 필수로 표시하는 것으로 제한된다.

• _field_names configuration is limited to disabling the field.

  _field_names 설정은 field를 비활성화하는 것으로 제한된다.

• _size configuration is limited to enabling the field.

  _size 설정은 field를 활성화하는 것으로 제한된다.

• _timestamp configuration is limited to enabling the field, setting format and default value.

  _timestamp 설정은 field를 활성화하고, format과 default vaule를 설정하는 것으로 제한된다.

• _boost has been removed.

  _boost 는 제거되었다.

• _analyzer has been removed.

  _analyzer 는 제거되었다.

Importantly, meta-fields can no longer be specified as part of the document body. Instead, they must be specified in the query string parameters. For instance, in 1.x, the routing could be specified as follows:

중요한 것은, meta-fields는 더 이상 document body의 일부로서 지정될 수 없다는 점이다. 대신, 그것들은 query string 매개변수에 지정되어야 한다. 예를 들어, 1.x에서 routing 은 다음처럼 지정될 수 있다.

PUT my_index
{
  "mappings": {
    "my_type": {
      "_routing": {
        "path": "group" 
      },
      "properties": {
        "group": { 
          "type": "string"
        }
      }
    }
  }
}

PUT my_index/my_type/1 
{
  "group": "foo"
}

	이 1.x의 mapping은 elasticsearch가 document body의 group field에서 routing value를 가져오도록 설정했다.
	이 index request는 routing 값으로 foo 를 사용한다.

In 2.0, the routing must be specified explicitly:

2.x에서, routing은 명시적으로 지정해야 한다.

PUT my_index
{
  "mappings": {
    "my_type": {
      "_routing": {
        "required": true 
      },
      "properties": {
        "group": {
          "type": "string"
        }
      }
    }
  }
}

PUT my_index/my_type/1?routing=bar 
{
  "group": "foo"
}

	routing은 index 중에 잊지 않도록 하기 위해, 필수로 표시될 수 있다.
	이 index request는 routing value로 bar 를 사용한다.

_timestamp and _ttl deprecatededit

The _timestamp and _ttl fields are deprecated, but will remain functional for the remainder of the 2.x series.

_timestamp 와 _ttl field는 deprecate되었다. 하지만, 2.x 시리즈의 나머지를 위해, 기능은 남아 있다.

Instead of the _timestamp field, use a normal date field and set the value explicitly.

_timestamp field 대신에, 일반적인 date field를 사용하고, 명시적으로 그 값을 설정하자.

The current _ttl functionality will be replaced in a future version with a new implementation of TTL, possibly with different semantics, and will not depend on the _timestamp field.

현재의 _ttl 기능은 나중 버전에서, 아마도 다른 의미를 가진, _timestamp field에 의존하지 않는, 새롭게 구현된 TTL로 대체될 것이다.

Analyzer mappingsedit

Previously, index_analyzer and search_analyzer could be set separately, while the analyzer setting would set both. The index_analyzer setting has been removed in favour of just using the analyzersetting.

이전 버전에서, index_analyzer 와 search_analyzer 는 따로 설정할 수 있었고, 반면에, analyzer 설정은 둘 모두를 설정했다. index_analyzer 설정은 analyzer 설정만을 사용하는데 유리하도록 제거되었다.

If just the analyzer is set, it will be used at index time and at search time. To use a different analyzer at search time, specify both the analyzer and a search_analyzer.

analyzer 만 설정되면, 그것은 index시와 search시에 사용된다. search시에 다른 analyzer를 사용하려면, analyzer 와 search_analyzer 를 모두 설정해야 한다.

The index_analyzer, search_analyzer, and analyzer type-level settings have also been removed, as it is no longer possible to select fields based on the type name.

type-level의 index_analyzer, search_analyzer, analyzer 설정도 제거되었다. 따라서, type name을 기반으로 field를 선택하는 것은 불가능하다.

The _analyzer meta-field, which allowed setting an analyzer per document has also been removed. It will be ignored on older indices.

document별로 analyzer를 설정할 수 있었던, analyzer meta-field 또한 제거되었다. 이것은 기존의 index에서 무시된다.

Date fields and Unix timestampsedit

Previously, date fields would first try to parse values as a Unix timestamp — milliseconds-since-the-epoch — before trying to use their defined date format. This meant that formats like yyyyMMdd could never work, as values would be interpreted as timestamps.

이전 버전에서, date field는 값을, 해당 field에 정의된 date format 을 사용하기 전에, 먼저 Unix timestamp — milliseconds-since-the-epoch --로 parsing하려 한다. 이것은 값이 timestamp로 해석되면, yyyyMMdd 같은 format으로는 동작하지 않을 수 있다는 것을 의미한다.

In 2.0, we have added two formats: epoch_millis and epoch_second. Only date fields that use these formats will be able to parse timestamps.

2.0에서, 2가지 format(epoch_mills, epoch_second)이 추가되었다. 이들 format이 사용되는 date field만 timestamp를 parsing할 수 있을 것이다.

These formats cannot be used in dynamic templates, because they are indistinguishable from long values.

이들 format은 dynamic template에서는 사용될 수 없다. 왜냐하면, 그들을 long values와 구분할 수 없기 때문이다.

Default date formatedit

The default date format has changed from date_optional_time to strict_date_optional_time, which expects a 4 digit year, and a 2 digit month and day, (and optionally, 2 digit hour, minute, and second).

기본 data format이 date_optional_time 에서 strict_date_optional_time 으로 변경되었다. 이것은 4자리 수 년도, 2자리 수 월과 날짜(그리고, 선택적으로, 두 자리 수 시, 분, 초)로 구성된다.

A dynamically added date field, by default, includes the epoch_millis format to support timestamp parsing. For instance:

기본적으로 동적으로 추가된 date field는 timestamp parsing을 지원하는 epoch_mills format을 포함한다.

PUT my_index/my_type/1
{
  "date_one": "2015-01-01" 
}

다음과 같은 format 을 가진다. "strict_date_optional_time||epoch_millis".

mapping.date.round_ceil settingedit

The mapping.date.round_ceil setting for date math parsing has been removed.

date 연산 parsing을 위한 mapping.date.round_ceil 설정은 제거되었다.

Boolean fieldsedit

Boolean fields used to have a string fielddata with F meaning false and T meaning true. They have been refactored to use numeric fielddata, with 0 for false and 1 for true. As a consequence, the format of the responses of the following APIs changed when applied to boolean fields: 0/1 is returned instead of F/T:

boolean field는 false 를 의미하는 F, true 를 의미하는 T 를 가진, string fielddata를 가지는데 사용되곤 한다. 이것은 false 를 위한 0, true 를 위한 1 을 가진 numeric fielddata로 다시 작성되었다. 그 결과, 다음 API의 응답 format이 변경되었다. boolean field를 적용하면, F/T 대신에 0/1 이 return 된다.

• fielddata fields
• sort values
• terms aggregations

In addition, terms aggregations use a custom formatter for boolean (like for dates and ip addresses, which are also backed by numbers) in order to return the user-friendly representation of boolean fields: false/true:

추가로, terms aggregation은, boolean(date나 ip address와 마찬가지로, 이것 또한 숫자로 표현)의 경우, 사용자에게 익숙한 boolean field의 표현(false/true)을 return하기 위해, 사용자 정의 formatter를 사용한다.

"buckets": [
  {
     "key": 0,
     "key_as_string": "false",
     "doc_count": 42
  },
  {
     "key": 1,
     "key_as_string": "true",
     "doc_count": 12
  }
]

index_name and path removededit

The index_name setting was used to change the name of the Lucene field, and the path setting was used on object fields to determine whether the Lucene field should use the full path (including parent object fields), or just the final name.

index_name 설정은 Lucene field의 name을 변경하기 위해 사용되었다. 그리고, path 설정은 Lucene field가 full path(parent object field 포함)를 사용해야 하는지, 단지 마지막의 name 만을 사용하는지를 결정하기 위한 object field에 사용되었다.

These setting have been removed as their purpose is better served with the copy_to parameter.

이들 설정은, 설정의 목적이 copy_to 매개변수로 더 잘 제공되기 때문에, 제거되었다.

Murmur3 Fieldsedit

Fields of type murmur3 can no longer change doc_values or index setting. They are always mapped as follows:

murmur3 type의 field는 doc_values 나 index 설정으로 더 이상 변경할 수 없다. 이것은 항상 아래처럼 mapping되어야 한다.

{
  "type":       "murmur3",
  "index":      "no",
  "doc_values": true
}

Attachment Fieldsedit

Fields of type attachment used to index their content in the "main" multi-field — a sub-field with the same name as the main field, e.g. my_attachment.my_attachment. This sub-field will be renamed tomy_attachment.content. Any mapping settings (e.g. analyzer) on the oldmy_attachment.my_attachment field will be lost. In this case, the index needs to be reindexed in 2.x.

attachment type의 field는 "main" multi-field에 그것의 내용을 index하는데 사용되곤 한다. — main field와 동일한 이름을 가진 sub-field, 예를 들어, my_attachment.my_attachment. 이 sub-field는 my_attachment.content 로 변경될 것이다. 기존의 my_attachment.my_attachment field에서 모든 mapping 설정은 없어질 것이다. 이 경우, index는 2.x에서 다시 index해야 한다.

The attachment sub-fields do not support copy_to.

attachment sub-field는 copy_to 를 지원하지 않는다.

Mappings in config files not supportededit

The ability to specify mappings in configuration files has been removed. To specify default mappings that apply to multiple indexes, use index templates instead.

설정 파일에서 mapping을 지정하는 기능은 제거되었다. 다수의 index에 적용하기 위한 default mapping을 지정하려면, index templates을 사용하자.

Along with this change, the following settings have been removed:

이 변경으로 인해, 다음과 같은 설정이 제거되었다.

• index.mapper.default_mapping_location
• index.mapper.default_percolator_mapping_location

Fielddata formatsedit

Now that doc values are the default for fielddata, specialized in-memory formats have become an esoteric option. These fielddata formats have been removed:

이제 doc values는 fielddata의 기본이어서, in-memory에 특화된 format은 소수만이 알고 있는 option이 되었다. 이들 fielddata format은 제거되었다.

• fst on string fields

  string field에서 fst

• compressed on geo points

  geo point에서 compressed

The default fielddata format will be used instead.

기본 fielddata format이 대신 사용될 것이다.

Posting and doc-values codecsedit

It is no longer possible to specify per-field postings and doc values formats in the mappings. This setting will be ignored on indices created before 2.0 and will cause mapping parsing to fail on indices created on or after 2.0. For old indices, this means that new segments will be written with the default postings and doc values formats of the current codec.

mapping에서 field별 posting과 doc values format을 지정하는 것은 더 이상 불가능하다. 이 설정은, 2.0 이전에 생성된 indices에서는 무시되며, 2.0 이후 버전에서는 mapping parsing 실패의 원인이 된다. 기존 indices에서, 이것은 새로운 segment가 현재 codec의 기본 posting과 doc values format을 가지고 작성된다는 것을 의미한다.

It is still possible to change the whole codec by using the index.codec setting. Please however note that using a non-default codec is discouraged as it could prevent future versions of Elasticsearch from being able to read the index.

index.code 설정을 통해, 전체 codec을 변경하는 것은 여전히 가능하다. 하지만, 기본이 아닌 codec을 사용하는 것은, Elasticsearch의 향후 version이 index를 읽는 것을 방해할 수 있어, 권장하지 않는다는 것을 명심하자.

Compress and compress thresholdedit

The compress and compress_threshold options have been removed from the _source field and fields of type binary. These fields are compressed by default. If you would like to increase compression levels, use the new index.codec: best_compression setting instead.

compress 와 compress_threshold option은 _soorce field와 binary type의 field에서 제거되었다. 이들 field는 기본적으로 압축된다. 압축 수준을 높이려면, index.codec: best_compression 설정을 대신 사용하자.

position_offset_gapedit

The position_offset_gap option is renamed to position_increment_gap. This was done to clear away the confusion. Elasticsearch’s position_increment_gap now is mapped directly to Lucene’s position_increment_gap

position_offset_gap option은 position_increment_gap 으로 이름이 변경되었다. 이것은 혼란을 없애기 위해 이루어졌다. Elasticsearch의 position_increment_gap 은 이제 Lucene의 position_increment_gap으로 직접 mapping된다.

The default position_increment_gap is now 100. Indexes created in Elasticsearch 2.0.0 will default to using 100 and indexes created before that will continue to use the old default of 0. This was done to prevent phrase queries from matching across different values of the same term unexpectedly. Specifically, 100 was chosen to cause phrase queries with slops up to 99 to match only within a single value of a field.

position_increment_gap 의 기본값은 이제 100이다. Elasticsearch 2.0.0 에서 생성된 index는 100을 사용하는 것이 기본이고, 이전 버전에서 생성되어 계속 사용하는 index는 기존의 기본값인 0이다. 이것은 phrase query가 예기치 않게 동일한 term을 다른 값에 일치하는 것을 막기 위함이다. 특히, 100은 99까지의 slop을 가진 phrase query가 field의 단일 값 내에서만 일치하도록 하기 위해 선택되었다.

copy_to and multi fieldsedit

A copy_to within a multi field is ignored from version 2.0 on. With any version after 2.1 or 2.0.1 creating a mapping that has a copy_to within a multi field will result in an exception.

multi field 내에서 copy_to는 2.0에서 무시된다. 2.0.1 이나 2.1 이후 버전에서 multi field 내에 copy_to를 가진 mapping은 exception을 발생시킬 것이다.