ES에서 mapping types가 없어지는 이유

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

[ES에서 mapping types가 없어지는 이유?]

elasticsearch 초기 버전에서는 "index"는 SQL에서의 "database"와 "type"은 "table"과 유사하다고 설명하였다. 하지만 이는 좋지 못한 비유였고 오해를 일으켰다. SQL DB 내 tables은 서로 독립적인데 반해, 한 table 내에 존재하는 column은 심지어 같은 column명을 가졌다고 하더라도 다른 table과는 전혀 무관했다. 하지만 mapping type 내에 존재하는 fields는 그러한 성격을 가지고 있지 않다.

ES index에서는 mapping types이 다르더라도 fields의 이름이 같다면 같은 Lucene field로 처리 되었다. 예를 들면 user type에 저장된 user_name field와 tweet type에 저장된 user_name field는 같은 field로 인식되었고, 그에 따라 field의 mapping(definition/맵핑정보) 또한 반드시 같아야만 했다.

이 떄문에 많은 문제가 발생하는데, 예를 들어 한 type에 있는 date field를 지우게 되면 다른 type에 존재하는 모든 date field 또한 제거 되었다. 이것 외에도 공통적인 fields가 거의 없는 index를 저장하는 것은 sparse data를 초래하고 Lucene이 효과적으로 documents를 압축하는 것을 방해한다.

이러한 이유들 때문에 ElasticSearch에서 mapping types라는 콘셉트는 사라지게 되었다.


[mapping types의 대안]

1) index 당 하나의 document type
첫번째 대안은 index 당 하나의 document type을 갖게하는 것이다. 위에서 설명한 tweet 정보, user 정보를 하나의 index에 저장하는 것이 아니라 각각 별도의 index를 두어 저장하는 것이다. 이렇게 되면 indices는 완전하게 독립적이게 되어 field types간 어떠한 충돌도 일으키지 않는다. (twitter -> tweets / user)

이러한 방법은 2가지 장점을 가진다.
- data가 dense 해져서 Lucene이 효과적으로 documents를 압축할 수 있도록 도와준다
- 같은 index 내 엤는 모든 documents는 하나의 entity를 나타기 때문에, 더욱 정확해질 가능성이 높아진다.

각각의 index는 documents의 수에 따라 적절하게 사이즈를 설정 될 수 있다. users는 tweets 보다 수가 적으므로 users는 적은 shard 수를 사용하고, tweets는 좀 더 많은 shard를 할당한다.

2) Custom type field
한 cluster에 존재할 수 있는 총 shard수는 제한되어있다. 그래서 적은 수의 documents 때문에 사용 가능한 shard의 수를 줄이고 싶지 않을 것이다. 이러한 일을 방지하기 위해 type이라는 field를 만들어서 수 있고, 이전의 _type과 유사하게 작동시킬 수 있다.

3) Parent/Child without mapping types
이전에는 부모 자식 관계를 표현하기위해 하나의 부모 type을 만들고 한개 이상의 자식 types를 만들었다. types이 없으면 더이상 이 문법을 사용할 수 없다. 이를 이전과 같이 계속 사용하기 위해 새로운 join field를 이용하여 documents간의 관계를 표현한다.


[다수의 types을 하나의 type으로 통합하기]

1) index 당 하나의 document type : twitter -> tweets, users
2) Custom type field