本文已参与「新人创作礼」活动，一起开启掘金创作之路。
背景
上文曾经留下了一个问题未详细说明，那就是ElasticSearch在对应RDS的概念中少了数据库这一曾经的对应关系，大家想想这是为什么呢？
其实不管是为了兼容RDS的使用习惯，还是为了将来能够平滑的承接RDS无法解决的业务场景，ElasticSearch在初始版本中已经有过类似的尝试，并且持续到了6.X版本。但是由于性能和效果未能达到预期，而且有一种画蛇添足的感觉，所以从7.X版本开始慢慢放弃type，type这个属性也开始退出ElasticSearch的舞台走向了落幕。
下面就来详细说说type相关的内容。
type属性的由来
从Elasticsearch的第一个发布版本以来，每一个document都被存储在一个单独的index里，并被赋予了一个type，一个mapping代表一个type相关的数据类型以及索引类型。
例如，一个twitter索引可能有一个user类型和tweet类型。
每种type都有他自己的字段，所以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": "nicola"
}
}
}
type为什么被干掉了
但是不知道何时起，有人将elasticsearch对标关系型数据库中的概念，这样便于理解，也便于处理问题，于是就有了下面的关系：
| SQL | ElasticSearch | Description |
|---|---|---|
| index | db | 数据库 |
| type | table | 数据表 |
| document | row | 数据行 |
| field | column | 数据列 |
| mapping | schema | 数据结构/类型 |
在关系型数据库里,table是相互独立的,一个table里的column和另外一个table的同名column没有关系，互不影响。但在type里字段却不是这样的。在一个Elasticsearch的index里，所有不同type的同名column内部使用的是同一个lucene字段存储。
举例来说，user类型的user_name字段和tweet类型的user_name字段是存储在一个field里的，两个类型里的user_name必须有一样的field定义。
这可能导致一些问题，例如你希望同一个索引中"create_time"字段在一个类型里是存储日期值，在另外一个类型里存储字符串。
另外，按照Lucene存储的方式和特点，如果按照此种方式组织数据，会影响到底层的压缩比例和存储效率。
基于上面的原因，type在被误解后处于尴尬的地位，慢慢的版本迭代就被干掉了，在干掉一层数据结构后，es的数据结构变的简单明了，便于理解。
type的版本迭代
- 5.x及以前版本一个index有一个或者多个type
- 6.X版本一个index只有一个index
- 7.X版本移除了type，type相关的所有内容全部变成Deprecated，为了兼容升级和过渡，所有的7.X版本es数据写入后type字段都默认被置为_doc
- 8.X版本完全废弃type
type跨版本适配
- 针对6.X版本升级到7.X的数据，使用restful api查询es时不需要指定type即可以进行查询、结果与指定对应的type进行查询、type使用_doc进行查询效果是一样的
- 针对6.X版本升级到7.X的数据，使用restful api写入es时，不能指定type，如果处于某种原因必须指定type,则可以将type指定为_doc(比如使用6.X的restful api，这种场景详见加链接)，如果id相同，则数据会被覆盖，但是type保持原来的值，不会出现一个id对应多条数据的情况；如果id不相同，则会新写入一条type为_doc的数据
- 如果为了将来兼容和支持高版本的elasticsearch，建议使用restful client去支持elasticsearch相关的操作，并且尽量不要在api中有type这个参数，就算必须要需要，也建议在源生api中再封装一层，否则后续版本升级，适配的工作量会让你崩溃
最后贴一张图来说明type的演进史：
文章到这里就结束了，最后路漫漫其修远兮，大数据之路还很漫长。如果想一起大数据的小伙伴，欢迎点赞转发加关注，下次学习不迷路，我们在大数据的路上共同前进！
