ES
Elasticsearch 是一种NoSQL数据库（非关系型数据库），和常规的关系型数据库（比如：MySQL，Oralce等）的基本概念，对应关系如下：
Elasticsearch：index –> type –> doc –> field
MySQL: 数据库 –> 数据表 –> 行 –> 列
因为关系型数据库比非关系型数据库的概念提出的早，而且很成熟，应用广泛。
所以，后来很多NoSQL（包括：MongoDB，Elasticsearch等）都参考并延用了传统关系型数据库的基本概念。
一个客观的现象和事实如下：
Elasticsearch 官网提出的近期版本对 type 概念的演变情况如下：
在 5.X 版本中，一个 index 下可以创建多个 type；
在 6.X 版本中，一个 index 下只能存在一个 type；
在 7.X 版本中，直接去除了 type 的概念，就是说 index 不再会有 type。
为何要去除 type 的概念？
为何不是在 6.X 版本开始就直接去除 type，而是要逐步去除type？
Why？!
原因分析
1、为何要去除 type 的概念？
答： 因为 Elasticsearch 设计初期，是直接查考了关系型数据库的设计模式，存在了 type（数据表）的概念。
但是，其搜索引擎是基于 Lucene 的，这种 “基因”决定了 type 是多余的。 Lucene 的全文检索功能之所以快，是因为 倒序索引 的存在。
而这种 倒序索引 的生成是基于 index 的，而并非 type。多个type 反而会减慢搜索的速度。
为了保持 Elasticsearch “一切为了搜索” 的宗旨，适当的做些改变（去除 type）也是无可厚非的，也是值得的。
所以，Why not？！
2、为何不是在 6.X 版本开始就直接去除 type，而是要逐步去除type？
答：因为历史原因，前期 Elasticsearch 支持一个 index 下存在多个 type的，而且，有很多项目在使用 Elasticsearch 作为数据库。
如果直接去除 type 的概念，不仅是很多应用 Elasticsearch 的项目将面临 业务、功能和代码的大改，
而且对于 Elasticsearch 官方来说，也是一个巨大的挑战（这个是伤筋动骨的大手术，很多涉及到 type 源码是要修改的）。
1、index、type的初衷
之前es将index、type类比于关系型数据库（例如mysql）中database、table，这么考虑的目的是“方便管理数据之间的关系”。
2、为什么现在要移除type？
2.1 在关系型数据库中table是独立的（独立存储），但es中同一个index中不同type是存储在同一个索引中的（lucene的索引文件），因此不同type中相同名字的字段的定义（mapping）必须一致。
2.2 不同类型的“记录”存储在同一个index中，会影响lucene的压缩性能。
3、替换策略
3.1 一个index只存储一种类型的“记录”
这种方案的优点：
a）lucene索引中数据比较整齐（相对于稀疏），利于lucene进行压缩。
b）文本相关性打分更加精确（tf、idf，考虑idf中命中文档总数）
3.2 用一个字段来存储type
如果有很多规模比较小的数据表需要建立索引，可以考虑放到同一个index中，每条记录添加一个type字段进行区分。
这种方案的优点：
a）es集群对分片数量有限制，这种方案可以减少index的数量。
4、迁移方案
之前一个index上有多个type，如何迁移到3.1、3.2方案？
4.1 先针对实际情况创建新的index，[3.1方案]有多少个type就需要创建多少个新的index，[3.2方案]只需要创建一个新的index。
4.2 调用_reindex将之前index上的数据同步到新的索引上。