一文读懂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对标关系型数据库中的概念，这样便于理解，也便于处理问题，于是就有了下面的关系：

elasticsearch	rdbms	description
index	db	数据库
type	table	数据表
document	row	数据行
field	column	数据列
mapping	schema	数据结构/类型

 

 

 

 

 

 

 

看上面的对照关系，一切都很完美，完全匹配，但是这也是一把双刃剑，玩惯了rdbms的人可能“误会”了elasticsearch，并按照rdbms的思想去构建elasticsearch，结果很快就发现了无数的坑，比如：

在关系型数据库里,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，这种场景详见一文讲解Elasticsearch java restful api 跨版本兼容解决方案)，如果id相同，则数据会被覆盖，但是type保持原来的值，不会出现一个id对应多条数据的情况；如果id不相同，则会新写入一条type为_doc的数据
• 如果为了将来兼容和支持高版本的elasticsearch，建议使用restful client去支持elasticsearch相关的操作，并且尽量不要在api中有type这个参数，就算必须要需要，也建议在源生api中再封装一层，否则后续版本升级，适配的工作量会让你崩溃

最后贴一张图来说明type的演进史：