[Elasticsearch 7.x] Removal of mapping types

What are mapping types?

Elasticsearch 초창기에는 각 document 는 하나의 index 와 연결된 하나의 mapping 타입이 있었다.

mapping type 은 색인화(indexed) document 나 엔티티 유형을 나타낸다.

예를 들어 twitter index 는 user 타입과 tweet 타입을 가질 수 있다.

각 mapping type 에는 고유한 필드가 있을 수 있다.

user 타입의 필드는 full_name, user_name, email
tweet 타입의 필드는 content, tweeted_at, user_name

각 document 에는 타입 이름을 포함하는 _type meta-field 가 있고, URL 에서 type 이름을 지정할 수 있다.

GET twitter/user,tweet/_search
{
"query": {
"match": {
  "user_name": "kimchy"
}
}
}

_type 필드는 document 의 _id 와 결합하여 _uid 필드를 만들기 때문에, 동일한 _id 를 가진 다른 타입의 documents 가 같은 인덱스에 존재할 수 있다.

Mapping type 은 문서간 parent-child relationship 설정하는데에도 사용되고, question 타입의 문서는 answer 타입의 문서의 부모일 수 있다.

Why are mapping types being removed?

처음에는 "index" 는 SQL DB 의 "database" 와 유사하고, "type" 는 "table" 동일하다고 이야기 했다.

이것은 잘못된 가정이었다.

SQL 디비는 테이블간 서로 독립적이다.

한 테이블의 칼럼은 다른 테이블의 같은 이름의 칼럼과 관련이 없다.
mapping type 의 필드에는 해당되지 않는다.

Elasticsearch index 에서 다른 mapping type 에서 같은 이름의 필드는 Lucene 에서 동일한 필드로 간주 한다.

즉, 위 예에서 user 타입에서 user_name 필드는 tweet 타입의 user_name 필드는 정확히 동일한 필드에 저장되며, 두 user_name 필드는 같은 mapping(definition) 을 양쪽 타입에서 가져야 한다.

예를 들어, 하나의 타입에서 deleted 필드를 date 로 바꾸고자 하면, 같은 인덱스의 다른 타입에선 boolean 필드로 되고자 하면 좌절된다.

또한 동일한 인덱스에 공통 필드가 거의 없는 엔티티를 저장하면, 데이터가 희소해지고, 문서를 효율적으로 압축하는 Lucene 의 기능을 방해한다.

이러한 이유로, Elasticsearch 에서 mapping types 컨셉을 제거하기로 결정 했다.

Alternatives to mapping types

Index per document type

첫번째 대안은 document type 별로 index 를 갖는것

tweets, users 는 단일 twitter 인덱스에 저장 대신에, tweets 는 tweets 인덱스로 users 는 user 인덱스로 저장한다.
indices 가 완전히 독립적이라 indices 사이에 필드 타입이 충돌 나지 않는다.

이 방식은 두가지 이점이 있다.

Data 는 밀도가 높기때문에 Lucene 의 압축 기술 활용이 가능하다
full text search 에서 scoring 을 위한 통계에서 모든 문서가 단일 엔티티를 나타내기때문에 더 정확하다.

각 인덱스의 크기는 포함할 도큐먼트 수에 맞게 조절 가능하다.

users 는 줄이고, tweets 는 늘릴수 있다.
Custom type field

물론 클러스터에 존재할 수 있는 프라이머리 샤드 수는 제한이 있으므로, 수천개의 문서를 수집하기 위해 전체 샤드를 낭비하지 않는다.

이 경우 old _type 과 비슷하게 동작하는 커스텀 type 필드 정의가 가능하다.

위 user / tweet 예제를 보면 원래 워크플로우는 다음과 같다.


PUT twitter
{
"mappings": {
"user": {
  "properties": {
    "name": { "type": "text" },
    "user_name": { "type": "keyword" },
    "email": { "type": "keyword" }
  }
},
"tweet": {
  "properties": {
    "content": { "type": "text" },
    "user_name": { "type": "keyword" },
    "tweeted_at": { "type": "date" }
  }
}
}
}

PUT twitter/user/kimchy { "name": "Shay Banon", "user_name": "kimchy", "email": "shay@kimchy.com" }

PUT twitter/tweet/1 { "user_name": "kimchy", "tweeted_at": "2017-10-24T09:00:00Z", "content": "Types are going away" }

GET twitter/tweet/_search { "query": { "match": { "user_name": "kimchy" } } }

* 다음과 같이 커스텀 `type` 필드를 추가하여 동일한 결과를 얻을 수 있다. ```json PUT twitter { "mappings": { "_doc": { "properties": { "type": { "type": "keyword" }, "name": { "type": "text" }, "user_name": { "type": "keyword" }, "email": { "type": "keyword" }, "content": { "type": "text" }, "tweeted_at": { "type": "date" } } } } } PUT twitter/_doc/user-kimchy { "type": "user", "name": "Shay Banon", "user_name": "kimchy", "email": "shay@kimchy.com" } PUT twitter/_doc/tweet-1 { "type": "tweet", "user_name": "kimchy", "tweeted_at": "2017-10-24T09:00:00Z", "content": "Types are going away" } GET twitter/_search { "query": { "bool": { "must": { "match": { "user_name": "kimchy" } }, "filter": { "match": { "type": "tweet" } } } } }

명시적인 type 필드가 암시적인 type 필드를 대신한다.

Parent/Child without mapping types

이전에는 parent-child relationship 으로 상하위 다른 매핑 타입으로 관계 설정이 가능했다.

type이 없으면 이제는 더이상 구문을 사용할 수 없다.

parent-child 기능은 join field 로 바뀌었고, 이전과 같이 사용 가능하다.

Schedule for removal of mapping types

이는 사용자에게 큰 변화이며 가능한 고통을 없애려고 노력했다.

다음과 같이 변경 사항이 적용 될것이다.

Elasticsearch 5.6.0

인덱스에서 index.mapping.single_type: true 로 설정 되면, single-type-per-index 동작이 활성화 되고, 6.0 에서 시행될것이다.

parent-child 를 대체할수 있는 join field 를 이용할 수 있다.

Elasticsearch 6.x

5.x 에서 생성된 indices 는 6.x 에서도 계속 동작한다.

6.x 에서 생성된 indices 는 오로지 인덱스당 single-type 만 허용한다. 모든 type name 을 사용할 수 있으나, 하나만 있을 수 있다. 선호되는 type 이름은 _doc 이며, index APIs 7.0 에서와 같은 path 를 갖는다. : PUT {index}/_doc/{id} 과 POST {index}/_doc

_type 이름읋 더이상 _id 와 결합하여 _uid 필드를 생성하지 않는다. _uid 필드는 _id 필드의 alias 가 되었다.

새 indices 는 더이상 old-stype parent/child 를 지원하지 않으므로, join filed 를 대신 써야 한다.

_default_ 매핑 타입이 deprecated 되었다

6.8 에서 인덱스 생성, 인덱스 템플릿, 매핑 APIs 에서는 요청 및 응답에 type 이름을 포함해야한은지에 대한 쿼리 스트링 파라미터 (inclued_type_name) 를 지원한다. default 는 true 이며 7.0 로 업그레이드 할수 있도록 명시적인 값을 설정해야 한다. include_type_name 을 설정하지 않으면 deprecation warning 결과가 나온다. 명시적인 type 이 없는 indices 는 더미 타입 이름인 _doc 를 사용한다.

Elasticsearch 7.x

요청에 types 지정하는것은 deprecated 됐다. 예를 들어, 인덱싱 도큐먼트 시 더이상 도큐먼트 type 를 요구하지 않는다. 새 인덱스 APIs 는 명시적일 때에는 PUT {index}/_doc/{id} 이고, 자동 생성된 ids 에 대해서는 POST {index}/_doc 이다. 7.0 에서 _doc 는 path 의 영구적인 부분이며, 문서 타입이 아닌 엔드포인트 name 을 표현한다.

인덱스 생성, 인덱스 템플릿, 매핑 APIs 시 include_type_name 파라미터는 default false 이다. 파라미터를 설정하면 deprecation warning 이 발생한다.

_default_ 매핑 타입은 제거되었다.

Elasticsearch 8.x

요청에 types 지정은 더이상 지원하지 않는다.

include_type_name 파라미터는 제거 되었다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html#_migrating_multi_type_indices_to_single_type

Migrating multi-type indices to single-type

Reindex API 로 multi-type indices 를 single-type indices 로 변환할 수 있다.
다음 예제는 5.6 or 6.x 에서 사용할 수 있다.
- 6.x 에서는 default 로 index.mapping.single_type 를 설정안해도 된다.

Index per document type

첫번째 예는 twitter 인덱스를 tweets 인덱스와 users 인덱스로 나눈다


PUT users
{
"settings": {
"index.mapping.single_type": true
},
"mappings": {
"_doc": {
  "properties": {
    "name": {
      "type": "text"
    },
    "user_name": {
      "type": "keyword"
    },
    "email": {
      "type": "keyword"
    }
  }
}
}
}

PUT tweets { "settings": { "index.mapping.single_type": true }, "mappings": { "_doc": { "properties": { "content": { "type": "text" }, "user_name": { "type": "keyword" }, "tweeted_at": { "type": "date" } } } } }

POST _reindex { "source": { "index": "twitter", "type": "user" }, "dest": { "index": "users", "type": "_doc" } }

POST _reindex { "source": { "index": "twitter", "type": "tweet" }, "dest": { "index": "tweets", "type": "_doc" } }

### Custom type field
* 다음 예는 커스텀 `type` 필드를 추가하고 original `_type` 의 값을 입력한다.
* 또한 충돌하는 IDs 를 가진 다른 타입의 문서가 있다면, `_id` 타입에 추가한다.

```json
PUT new_twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": {
          "type": "keyword"
        },
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        },
        "content": {
          "type": "text"
        },
        "tweeted_at": {
          "type": "date"
        }
      }
    }
  }
}

POST _reindex
{
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter"
  },
  "script": {
    "source": """
      ctx._source.type = ctx._type;
      ctx._id = ctx._type + '-' + ctx._id;
      ctx._type = '_doc';
    """
  }
}

Typeless APIs in 7.0

Elasticsearch 7.0 에서는 typeless 한 API 요청을 지원하며, type을 지정할 경우 deprecation warning 이 발생한다.

대상 인덱스에 커스텀 type 이 포함되어 있어도, typeless API 는 동작한다. 예를들어, 인덱스가 my_type 이라는 커스텀 타입 이름을 가졌을시, typeless index 호출로 인덱스를 추가하고, typeless get 호출로 문서를 읽을 수 있다.

Index APIs
인덱스 생성, 인덱스 템플릿, 매핑 APIs 는 요청과 응답에 type 이름이 포함되어야 하는지 정하는 새로운 include_type_name URL 파라미터를 지원한다.
- 버전 6.8 에서 파라미터 defaut 는 true 이며, 매핑에서 type 이름을 사용하는 pre-7.0 동작과 일치한다.
- 버전 7.0 에서는 default false 이며, 8.0 에서는 제거될것이다.
6.8 에서 7.0 으로 업그레이드를 준비하려면 명시적으로 설정해야 한다.
- 6.8 에서는 deprecation warning 을 피하기 위해 true or false 설정 가능하다.
- 7.0 에서 include_type_name 를 설정하면 deprecation warning 이 발생한다.

이 옵션을 false 로 하고 Elasticsearch 와 상호작용 하는 몇가지 예를 보여준다.

PUT index?include_type_name=false
{
"mappings": {
"properties": { 
  "foo": {
    "type": "keyword"
  }
}
}
}

매핑은 type 이름 없이, mappings 키 바로 아래 포함됩니다.

PUT index/_mappings?include_type_name=false
{
"properties": { 
"bar": {
  "type": "text"
}
}
}

매핑은 type 이름 없이, mappings 키 바로 아래 포함됩니다.

GET index/_mappings?include_type_name=false


"index": {
"mappings": {
  "properties": { 
    "foo": {
      "type": "keyword"
    },
    "bar": {
      "type": "text"
    }
  }
}
}
}

매핑은 type 이름 없이, mappings 키 바로 아래 포함됩니다.

Document APIs

7.0 index APIs 는 자동 생성된 {index}/_doc path 와 명시적인 ids 를 가진 {index}/_doc/{id} 로 호출 되어야 한다.

PUT index/_doc/1
{
  "foo": "baz"
}

{
  "_index": "index",
  "_id": "1",
  "_type": "_doc",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

유사하게 get 과 delete APIs 는 {index}/_doc/{id} path 를 사용한다.
```
GET index/_doc/1
```
7.0 에서 _doc 는 document 타입이 아니라 endpoint 를 나타낸다. _doc 컴포넌트는 document 의 index, get, delete API 의 영구적인 부분이며, 8.0 에서 제거되지 않는다.
_update 와 같은 endpoint 를 포함하는 API paths 는, 7.0 에서는 index 이름을 즉시 따른다.
```
POST index/_update/1
{
"doc" : {
    "foo" : "qux"
}
}
```

GET /index/_source/1

* 요청 본문에 type 이 더이상 나타나지 않아야 한다. 다음의 bulk indexing 예제에서는, URL 과 개별 bulk 명령어에서 type 이 생략된다.
```json
POST _bulk
{ "index" : { "_index" : "index", "_id" : "3" } }
{ "foo" : "baz" }
{ "index" : { "_index" : "index", "_id" : "4" } }
{ "foo" : "qux" }

Search APIs

_search, _msearch, _explain 와 같은 search API 를 호출할때, type 이 URL 에 포함되어서는 안된다. 또한, _type 필드는 queries, aggregations, scripts 에도 사용되서는 안된다.

Types in responses

document, search APIs 에서는 응답에서 _type key 를 계속 반환하는데, 이는 응답 파싱 실패를 피해기 위함이다.
- 그런데, 이 key 는 deprecated 됐고, 더이상 참조해선 안된다. 8.0 에서 type 은 응답에서 제거된다.
deprecated type API 를 쓰면, 인덱스의 mapping type 이 정상 반환 되지만, typeless APIs 는 응딥에서 더미 _doc type 를 반환한다.
- 예를들어, typeless get 호출은 mapping 에 커스텀 타입인 my_type 같은게 있더라도, _doc type 을 항상 반환한다.
```
PUT index/my_type/1
{
"foo": "baz"
}
```

GET index/_doc/1

{ "_index" : "index", "_type" : "_doc", "_id" : "1", "_version" : 1, "_seq_no" : 0, "_primary_term" : 1, "found": true, "_source" : { "foo" : "baz" } }


### Index templates
* `include_type_name` 을 `false` 로 설정하여, typeless index 템플릿을 re-adding 으로 만드는것을 추천한다.
  * hood 에서 typeless 템플릿은 index 를 만들때 더미 type `_doc` 를 사용한다.
* typeless 템플릿이 typed index 생성 호출과 함께 사용되거나, typed 템플릿이 typeless index 생성 호출과 함께 사용되면, 템플릿은 계속 적용되지만, idex 생성 호출은 type 이 있는지 없는지 결정해야 한다.
  * 아래 예를 보면, `index-1-01` 는 typeless 템플릿과 일치하지만 type이 있고, `index-2-01` 는 type 정의 템플릿과 일치하지만 typeless 이다.
  * `index-1-01`, `index-2-01` 둘다 일치 하는 템플릿에서 `foo` 필드를 상속한다.
```json
PUT _template/template1
{
  "index_patterns":[ "index-1-*" ],
  "mappings": {
    "properties": {
      "foo": {
        "type": "keyword"
      }
    }
  }
}

PUT _template/template2?include_type_name=true
{
  "index_patterns":[ "index-2-*" ],
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT index-1-01?include_type_name=true
{
  "mappings": {
    "type": {
      "properties": {
        "bar": {
          "type": "long"
        }
      }
    }
  }
}

PUT index-2-01
{
  "mappings": {
    "properties": {
      "bar": {
        "type": "long"
      }
    }
  }
}

implicit 인덱스 생성의 경우, 아직 존재하지 않는 index 에서 indexed 된 document 가 항상 템플릿을 적용받는다.
- typeless index 호출은 typed indices 에서만 동작하기 때문에 일반적으로 문제 되지 않는다.

Mixed-version clusters

6.8, 7.0 노드로 구성된 클러스터에서, include_type_name 파라미터는 index 생성과 같은 index APIs 에서 꼭 지정해야 한다.
- 이는 파라미터 default 가 6.8 과 7.0 사이에 다르고, 같은 mapping 정의가 두 노드 버전간 유효하지 않기 때문이다.
bulk, update 와 같은 typeless document APIs 는 7.0 에서만 사용할 수 있고, 6.8 노드에선 동작하지 않는다.
- terms 과 같은 document lookup 도 typeless 일 경우 동일하다.

Pyohwan / english-study