v5.0-02. Mapping changes

string fields replaced by text/keyword fieldsedit

The string field datatype has been replaced by the text field for full text analyzed content, and the keyword field for not-analyzed exact string values. For backwards compatibility purposes, during the 5.x series:

string field datatype이 full text analyzed 내용에 대해서는 text field로, not-analyzed exact string 값에 대해서는 keyword field로 변경되었다. 이전 version과의 호환성을 위해, 5.x 시리즈에서

• string fields on pre-5.0 indices will function as before.

  5.0 이전의 indices에서 string field는 이전처럼 동작할 것이다.

• New string fields can be added to pre-5.0 indices as before.

  5.0 이전의 indices에서 새로운 string field는 이전처럼 추가될 수 있다.

• text and keyword fields can also be added to pre-5.0 indices.

  또한, 5.0 이전의 indices에 text 와 keyword field는 추가될 수 있다.

• When adding a string field to a new index, the field mapping will be rewritten as a text or keyword field if possible, otherwise an exception will be thrown. Certain configurations that were possible with string fields are no longer possible with text/keyword fields such as enabling term_vectors on a not-analyzed keyword field.

  새로운 index에 string field를 추가할 경우, 가능하다면 field mapping은 text 또는 keyword field로 다시 작성될 것이다. 그렇지 않으면 예외가 발생한다. not-analyzed keyword field에서 term_vectors 를 활성화하는 것과 같은, string field로 가능한 특정 설정은 text/keyword field에서는 더 이상 가능하지 않다.

Default string mappingsedit

String mappings now have the following default mappings:

이제 string mapping은 다음과 같은 기본 mapping을 가진다.

{
  "type": "text",
  "fields": {
    "keyword": {
      "type": "keyword",
      "ignore_above": 256
    }
  }
}

This allows to perform full-text search on the original field name and to sort and run aggregations on the sub keyword field.

이렇게 하면 원래의 field name으로 full-text search를 수행하고, 하위 keyword field로 정렬과 aggregation을 실행할 수 있다.

Numeric fieldsedit

Numeric fields are now indexed with a completely different data-structure, called BKD tree, that is expected to require less disk space and be faster for range queries than the previous way that numerics were indexed.

numeric field는 이제 BKD tree라는 완전히 다른 데이터 구조로 index된다. 이 구조는 disk 공간을 덜 필요로하고, 이전에 numeric을 index했던 방식보다 range query에 있어 더 빠를 것으로 예상된다.

Term queries will return constant scores now, while they used to return higher scores for rare terms due to the contribution of the document frequency, which this new BKD structure does not record. If scoring is needed, then it is advised to map the numeric fields as keyword too.

term 쿼리는, 이 새로운 BKD 구조가 기록하지 않는 document frequency의 기여로 인해 드문 용어에 대해 더 높은 score를 return하는 것에 비해, 지금은 constant score를 return한다. score 계산이 필요한 경우, numeric field를 keyword로 매핑하는 것이 좋다.

Note that this keyword mapping do not need to replace the numeric mapping. For instance if you need both sorting and scoring on your numeric field, you could map it both as a number and a keyword using fields:

이 keyword mapping이 numeric mapping을 대체할 필요가 없다는 점을 기억하자. 예를 들어, numeric field에 정렬과 score 계산이 모두 필요하면 fields를 사용하여 숫자와 keyword 로 mapping할 수 있다.

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "my_number": {
          "type": "long",
          "fields": {
            "keyword": {
              "type":  "keyword"
            }
          }
        }
      }
    }
  }
}

COPY AS CURLVIEW IN CONSOLE 

Also the precision_step parameter is now irrelevant and will be rejected on indices that are created on or after 5.0.

또한, precision_step parameter는 이제 무의미하며, 5.0 이후에 생성된 indices에서 거부된다.

geo_point fieldsedit

Like Numeric fields the Geo point field now uses the new BKD tree structure. Since this structure is fundamentally designed for multi-dimension spatial data, the following field parameters are no longer needed or supported: geohash, geohash_prefix, geohash_precision, lat_lon. Geohashes are still supported from an API perspective, and can still be accessed using the .geohash field extension, but they are no longer used to index geo point data.

numeric field와 마찬가지로 geo point field는 이제 새 BKD tree 구조를 사용한다. 이 구조는 기본적으로 다차원 공간 데이터용으로 설계되어, 이어지는 field parameter가 더 이상 필요하지 않거나 지원되지 않는다: geohash, geohash_prefix, geohash_precision, lat_lon. geohashes는 여전히 API 관점에서 지원되며, .geohash 필드 확장을 사용하여 access할 수 있지만, 더 이상 geo point 데이터를 index하는데 사용되지 않는다.

_timestamp and _ttledit

The _timestamp and _ttl fields were deprecated and are now removed. As a replacement for _timestamp, you should populate a regular date field with the current timestamp on application side. For _ttl, you should either use time-based indices when applicable, or cron a delete-by-query with a range query on a timestamp field

_timestamp, _ttl field는 deprecate되었으며, 이제 제거되었다. _timestamp 대신에 응용프로그램쪽에서 현재 timestamp로 보통의 date field를 채워야합니다. _ttl 의 경우, 적용 가능한 경우 time-based indices을 사용하거나 timestamp field에 대한 range query로 delete-by-query를 cron해야 한다

index propertyedit

On all field datatypes (except for the deprecated string field), the index property now only accepts true/false instead of not_analyzed/no. The string field still accepts analyzed/not_analyzed/no.

deprecate된 string field를 제외한 모든 field datatype에서 index property는 not_analyzed/no 대신에 true/false 만을 허용한다. string field는 여전히 analyze/not_analyzed/no 를 허용한다.

Doc values on unindexed fieldsedit

Previously, setting a field to index:no would also disable doc-values. Now, doc-values are enabled by default on all types but text and binary, regardless of the value of the index property.

이전 version에서, field를 index:no 로 설정하면 doc-values도 비활성화된다. 이제 doc-values는 text 와 binary 를 제외한 모든 type에서 index property의 값에 관계없이 기본적으로 활성화된다.

Floating points use float instead of doubleedit

When dynamically mapping a field containing a floating point number, the field now defaults to using float instead of double. The reasoning is that floats should be more than enough for most cases but would decrease storage requirements significantly.

부동 소수점 숫자(floating point number)를 포함하는 field를 동적으로 mapping할 경우, field의 기본값은 double 대신에 float 이다. 그 이유는 대부분의 경우 float으로 충분하고, 저장소가 크게 줄어들 것이다.

normsedit

norms now take a boolean instead of an object. This boolean is the replacement for norms.enabled. There is no replacement for norms.loading since eager loading of norms is not useful anymore now that norms are disk-based.

norms 는 이제 object 대신 boolean을 갖는다. 이 boolean은 norms.enabled 를 대체한다. norms은 디스크 기반이어서 eager loading of norms이 더 이상 유용하지 않으므로 norms.loading 을 대체할 수 없다.

fielddata.formatedit

Setting fielddata.format: doc_values in the mappings used to implicitly enable doc-values on a field. This no longer works: the only way to enable or disable doc-values is by using the doc_valuesproperty of mappings.

field에서 doc-values를 암묵적으로 활성화하는데 사용되는 mapping에서 fielddata.format: doc_values 를 설정합니다. 이것은 더 이상 작동하지 않는다. doc-values를 활성화/비활성화하는 유일한 방법은 mapping의 doc_values property를 사용하는 것이다.

fielddata.filter.regexedit

Regex filters are not supported anymore and will be dropped on upgrade.

Regex filter는 더 이상 지원되지 않으며 upgrade시 제거된다.

Source-transform removededit

The source transform feature has been removed. Instead, use an ingest pipeline.

source transform 기능이 제거되었다. 대신 ingest pipeline을 사용하자.

Field mapping limitsedit

To prevent mapping explosions, the following limits are applied to indices created in 5.x:

mapping explosion을 방지하기 위해 5.x에서 생성된 indices에는 다음 제한 사항이 적용된다.

• The maximum number of fields in an index is limited to 1000.

  특정 index에서 field의 최대 수는 1000으로 제한된다.

• The maximum depth for a field (1 plus the number of object or nested parents) is limited to 20.

  filed의 최대 depth(1 + object or nested parents의 수)는 20으로 제한된다.

• The maximum number of nested fields in an index is limited to 50.

  특정 index에서 nested field의 최대 수는 50으로 제한된다.

See Settings to prevent mappings explosionedit for more.

자세한 사항은 Settings to prevent mappings explosionedit을 참고하자.

_parent field no longer indexededit

The join between parent and child documents no longer relies on indexed fields and therefore from 5.0.0 onwards the _parent field is no longer indexed. In order to find documents that refer to a specific parent id, the new parent_id query can be used. The GET response and hits inside the search response still include the parent id under the _parent key.

parent document와 child document간의 결합은 더 이상 index된 field에 의존하지 않으므로 5.0.0 이후부터 _parent 필드는 더 이상 index되지 않는다. 특정 parent ID를 참조하는 document를 찾으려면 새로운 parent_id query를 사용할 수 있다. GET response와 search response 안의 hit는 여전히 _parent key 아래에 parent id를 포함한다.

Source format optionedit

The _source mapping no longer supports the format option. It will still be accepted for indices created before the upgrade to 5.0 for backwards compatibility, but it will have no effect. Indices created on or after 5.0 will reject this option.

_source mapping은 더 이상 format option을 지원하지 않는다. 이전 version과의 호환성을 위해, 5.0으로 upgrade하기 전에 만든 index는 여전히 허용하지만 아무 효과가 없다. 5.0 이후에 만들어진 indices는 이 option을 거부한다.

Object notationedit

Core types no longer support the object notation, which was used to provide per document boosts as follows:

core type은 더 이상 객체 표기법(object notation)을 지원하지 않는다. 이는 다음과 같이 document 별로 boost를 제공하는 데 사용되었다.

{
  "value": "field_value",
  "boost": 42
}

Boost accuracy for queries on _alledit

Per-field boosts on the _all are now compressed into a single byte instead of the 4 bytes used previously. While this will make the index much more space-efficient, it also means that index time boosts will be less accurately encoded.

_all 에 대한 field별 boost는 이전에 사용된 4 byte 대신 1 byte로 압축되었다. 이렇게 하면 index의 공간 효율성은 향상되지만 index시 boost가 덜 정확하게 인코딩될 수 있다.

_ttl and _timestamp cannot be creatededit

You can no longer create indexes with _ttl or _timestamp enabled. Indexes with them enabled created before 5.0 will continue to work.

_ttl 또는 _timestamp 가 활성화된 index를 더 이상 생성할 수 없다. 5.0 이전에 그것을 활성화하여 생성된 index는 계속 작동한다.

You should replace _timestamp in new indexes by adding a field to your source either in the application producing the data or with an ingest pipeline like this one:

새로운 index에서 _timestamp 를 대체하려 응용프로그램에서 데이터를 생성하거나 아래처럼 ingest pipeline으로 source에 field를 추가해야 한다.

PUT _ingest/pipeline/timestamp
{
  "description" : "Adds a timestamp field at the current time",
  "processors" : [ {
    "set" : {
      "field": "timestamp",
      "value": "{{_ingest.timestamp}}"
    }
  } ]
}

PUT newindex/type/1?pipeline=timestamp
{
  "example": "data"
}

GET newindex/type/1

COPY AS CURLVIEW IN CONSOLE 

Which produces

아래를 생성한다.

{
  "_source": {
    "example": "data",
    "timestamp": "2016-06-21T18:48:55.560+0000"
  },
  ...
}

If you have an old index created with 2.x that has _timestamp enabled then you can migrate it to a new index with the a timestamp field in the source with reindex:

_timestamp 가 활성화된 2.x 로 생성된 기존 index를 가지고 있다면 reindex를 사용하여 소스의 timestamp field를 사용하여 그것을 새로운 index로 migration할 수 있다:

POST _reindex
{
  "source": {
    "index": "oldindex"
  },
  "dest": {
    "index": "newindex"
  },
  "script": {
    "lang": "painless",
    "source": "ctx._source.timestamp = ctx._timestamp; ctx._timestamp = null"
  }
}

COPY AS CURLVIEW IN CONSOLE 

You can replace _ttl with time based index names (preferred) or by adding a cron job which runs a delete-by-query on a timestamp field in the source document. If you had documents like this:

_ttl 을 time based index 이름으로 대체하거나 source document의 timestamp field에서 delete-by-query를 실행하는 cron 작업을 추가할 수 있다. 다음과 같은 문서가 있다면 :

POST index/type/_bulk
{"index":{"_id":1}}
{"example": "data", "timestamp": "2016-06-21T18:48:55.560+0000" }
{"index":{"_id":2}}
{"example": "data", "timestamp": "2016-04-21T18:48:55.560+0000" }

COPY AS CURLVIEW IN CONSOLE 

Then you could delete all of the documents from before June 1st with:

6월 1일 이전의 모든 document를 삭제할 수 있다.

POST index/type/_delete_by_query
{
  "query": {
    "range" : {
      "timestamp" : {
        "lt" : "2016-05-01"
      }
    }
  }
}

COPY AS CURLVIEW IN CONSOLE 

Keep in mind that deleting documents from an index is very expensive compared to deleting whole indexes. That is why time based indexes are recommended over this sort of thing and why _ttl was deprecated in the first place.

index에서 document를 삭제하는 것은 전체 index를 삭제하는 것보다 비용이 많이 드는 작업이라는 점을 기억하자. 이것이 time based index가 이런 종류의 것들에 추천되고 _ttl 이 우선적으로 deprecate된 이유이다.

Blank field names is not supportededit

Blank field names in mappings is not allowed after 5.0.

5.0 이후에 mapping에서 비어있는 field 이름은 허용되지 않는다.