标签：name 字段 版本升级 elasticsearch user 类型 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中再封装一层，否则后续版本升级，适配的工作量会让你崩溃

在ElasticSearch升级到8.x之后，在自己使用kibana测试添加索引得时候，按照
正常得添加的时候，发现一直会报一个400错误，no handler found for uri。。。后来发现用系统默认的类型添加的时候就没问题，整整困扰了一天的原因是在el8以后不在支持索引，换成低版本的测试就没问题了

标签：name,字段,版本升级,elasticsearch,user,类型,type
来源： https://www.cnblogs.com/yuarvin/p/16658155.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。