一文读懂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的演进史:

一文读懂elasticsearch版本升级type的变化_第1张图片

你可能感兴趣的:(elasticsearch,elasticsearch,type,版本升级,mapping,restful)