以下为官网原文 链接
Why are mapping types being removed?edit
Initially, we spoke about an “index” being similar to a “database” in an SQL database, and a “type” being equivalent to a “table”.
This was a bad analogy that led to incorrect assumptions. In an SQL database, tables are independent of each other. The columns in one table have no bearing on columns with the same name in another table. This is not the case for fields in a mapping type.
In an Elasticsearch index, fields that have the same name in different mapping types are backed by the same Lucene field internally. In other words, using the example above, the user_name field in the user type is stored in exactly the same field as the user_name field in the tweet type, and both user_name fields must have the same mapping (definition) in both types.
This can lead to frustration when, for example, you want deleted to be a date field in one type and a boolean field in another type in the same index.
On top of that, storing different entities that have few or no fields in common in the same index leads to sparse data and interferes with Lucene’s ability to compress documents efficiently.
For these reasons, we have decided to remove the concept of mapping types from Elasticsearch.Elasticsearch7.X为什么移除类型(type)
在Elasticsearch7.0.0及以后版本不再接受_default_ 映射。在6.x里创建的索引依然像在Elasticsearch6.X之前一样起作用。Types在7.0的API里是被舍弃的，在创建索引,设置映射,获取映射，设置模板，获取模板,获取字段映射API有着不兼容的改变。
index、type的初衷
之前es将index、type类比于关系型数据库（例如mysql）中database、table，这么考虑的目的是“方便管理数据之间的关系”。
【本来为了方便管理数据之间的关系，类比database-table 设计了index-type模型】
什么是类型(type)？
从Elasticsearch的第一个发布版本以来，每一个文档都被存储在一个单独的索引里，并被赋予了一个type，一个映射类型代表着一个被索引的文档或实体的类型,例如，一个twitter索引可能有一个user类型和tweet类型。
每种映射类型都有他自己的字段，所以user类型可能有一个full_name字段，一个user_name字段和一个email字段，而一个tweet类型可能有一个content字段，一个tweet_at字段，和user类型一样一个user_name字段。
每一个文档类型都有一个_type元字段来存储type名称,并且根据URL里指定的类型名称，查询（搜索）被限定在一个或多个类型(type)里:
GET twitter/user,tweet/_search { "query": { "match": { "user_name": "kimchy" } } }_type字段用来和文档的_id字段联合生成_uid字段，所以有着相同_id的不同类型的文档可以存在同一个索引里。类型也用来建立文档间的父子关系，所以question类型的文档可能是anser类型文档的父文档。
1、我们经常把二维数据库与ES作类比的方式是不正确的假设。把“index”类比为数据库，“type”类比为表。具体原因是，数据库的表是物理独立的，一个表的列跟另外一张表相同名称的列没有关系，而ES中并非如此，不同type映射类型中具有相同名称的字段在内部由相同的Lucene字段支持。
2、当您想要索引一个deleted字段在不同的type中数据类型不一样。一个类型中为日期字段，另外一个类型中为布尔字段时，这可能会导致ES的存储失败,因为这影响了ES的初衷设计。
3、另外，在一个index中建立很多实体，type，没有相同的字段，会导致数据稀疏，最终结果是干扰了Lucene有效压缩文档的能力，说白了就是影响ES的存储、检索效率。
为什么现在要移除type？
2.1 在关系型数据库中table是独立的（独立存储），但es中同一个index中不同type是存储在同一个索引中的（lucene的索引文件），因此不同type中相同名字的字段的定义（mapping）必须一致。
2.2 不同类型的“记录”存储在同一个index中，会影响lucene的压缩性能。
【总结：
es基于Lucene的索引文件扩展type结构，也受限制与同一个index里的不同的type存储再同样一个索引文件里
这样不同type里的相同名字的field mapping必须一致，事实上上数据库中的不同的table表是独立存储的，不同的table里的字段是 独立设计的
于是type的用途非常有限，比如下面的替换方案】替换策略
3.1 一个index只存储一种类型的“记录”
这种方案的优点：
a）lucene索引中数据比较整齐（相对于稀疏），利于lucene进行压缩。
b）文本相关性打分更加精确（tf、idf，考虑idf中命中文档总数）
3.2 用一个字段来存储type
如果有很多规模比较小的数据表需要建立索引，可以考虑放到同一个index中，每条记录添加一个type字段进行区分。
这种方案的优点：
a）es集群对分片数量有限制，这种方案可以减少index的数量。
方案1：去掉type，全部使用独立的index；问题：index太多影响es集群分片效果。
方案2：如果数据量不大，可以把一个index下不同的type 合并成一个index；通过一个field字段比如就叫 _type 来区分之前的index-type迁移方案
之前一个index上有多个type，如何迁移到3.1、3.2方案？
- 先针对实际情况创建新的index，[3.1方案]有多少个type就需要创建多少个新的index，[3.2方案]只需要创建一个新的index。
- 调用_reindex将之前index上的数据同步到新的索引上；第二个方案通过_reindex 配合脚本区分不同的type字段
Elasticsearch 移除 type 之后的新姿势
随着 7.0 版本的即将发布，type 的移除也是越来越近了，在 6.0 的时候，已经默认只能支持一个索引一个 type 了，7.0 版本新增了一个参数 include_type_name ，即让所有的 API 是 type 相关的，这个参数在 7.0 默认是 true，不过在 8.0 的时候，会默认改成 false，也就是不包含 type 信息了，这个是 type 用于移除的一个开关。