为什么Elasticsearch7.x把type给干掉了?

这篇具有很好参考价值的文章主要介绍了为什么Elasticsearch7.x把type给干掉了?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、介绍

ES7之前是有type的,属于index下,一个index可以有不同的type,ES7开始就把type这个显示概念给删除了,统一换成了_doc来表示type。也就是ES7开始一个index只能有一个type,而且这个type还是默认的_doc。

二、type的底层存储

1、概念讲解

什么是类型(type)?

从Elasticsearch的第一个发布版本以来,每一个文档都被存储在一个单独的索引里,并被赋予了一个type,一个映射类型代表着一个被索引的文档或实体的类型。

document中field的value在底层的lucene中建立索引的时候全部是二进制类型的,因为Lucene是没有type概念的,所以在document中,实际上将type作为一个document的field来存储(_type字段),然后ES通过_type来进行type的过滤和筛选。

也就是说一个index中的多个type实际上是放到一起存储的,所以一个index下不能有多个重名的type。

2、代码讲解

比如有如下两个结构的type:

{
   "test_index": {
      "mappings": {
         "mobile": {
            "properties": {
               "name": {
                  "type": "string",
               },
               "price": {
                  "type": "double"
               },
                 "xxx": {
                      "type": "string"
                 }            

            }
         },
         "computer": {
            "properties": {
               "name": {
                  "type": "string",
               },
               "price": {
                  "type": "double"
               },
                 "yyy": {
                      "type": "string"
                 }
            }
         }
      }
   }
}

type为mobile的下面有一条document如下:

{
  "name": "xiaomi",
  "price": 3999.99,
  "xxx": "abcd"
}

type为computer的下面有一条document如下:

{
  "name": "apple",
  "price": 9999.99,
  "yyy": "apple good"
}

上面那两条数据在底层存储mapping是下面这个样子的:

{
   "test_index": {
      "mappings": {
        "_type": {
          "type": "string",
          "index": "not_analyzed"
        },
        "name": {
          "type": "string"
        }
        "price": {
          "type": "double"
        }
        "xxx": {
          "type": "string"
        }
        "yyy": {
          "type": "string"
        }
      }
   }
}

可以看到type其实就是一个_type字段,字符串类型,不分词。

上面那两条数据在底层存储document是下面这个样子的:

{
  "_type": "mobile",
  "name": "xiaomi",
  "price": 3999.99,
  "xxx": "abcd",
  "yyy": ""
}
{
  "_type": "computer",
  "name": "apple",
  "price": 9999.99,
  "xxx": "",
  "yyy": "apple good"
}

3、总结

1、type是document中的一个字段_type,且类型是string,不进行分词。

2、底层会将当前index下所有type下的所有document的field都统一存放到了一个地方,对多个type的多个document进行了merge合并。

3、document1中没有yyy字段,但是也会将他放入其内,只是value为空字符串,document2同理。进一步证明了进行了merge。

4、同一个index下的不同type下的document字段名若相同,则类型一样要相同,否则会冲突报错,因为他在merge的时候不知道你这个字段是什么类型。

三、ES7.x为什么删除了type?

假设在一个index中建立很多type,并且这些type下的document都没有相同的字段,那么会导致数据极其稀疏(因为会合并,没有的字段是空字符串),影响ES的存储、检索效率。

在一个index中建立很多type,其中有两个document属于不同的type,但是这两个document的field名称一样,数据类型不一样。这时候就报错了。

四、

两种场景,大家都用过:

  • 同一个index下,不同的type,命名名称一样的字段名。

  • 同一个数据库下,不同的表,命名名称一样的字段名。

在关系型数据库中,不同的表中,包含相同的字段名是很常见的,而且它们可以做到互不干扰。

在ElasticSearch中,不同的type,如果包含相同的字段名,它们是一样的,es会认为是一个字段,模糊掉不同type的概念。所以在es里边,type这个概念没必要存在,所以es7就废弃了。

为什么Elasticsearch7.x把type给干掉了?

同志们,可以试一下,在同一个index中,不同的type,创建一个同名的字段,但是类型不要弄成一样的,看能否成功创建。答案是不可以,它会提示你,不可以将这个字段的类型更改为这个类型。

illegla_argument_exception

mapper [create_time_] cannot be changed from type [date] to [keyword]

所以,结论就是,es确实把不同type中的同名字段,当成了一个字段

在设计索引库的时候,同名问题一定要注意,最简单的方法就是一个index,一个type,想要其他类型,另外创建index,当然你可以用别的字段名。

注意:ES7废弃,但还在用,ES8才真正的去掉了type。

五、Elastic最新的8.6已经发布了

ES在8.x引入了很多新特性,这个系列我就来一一为大家分享下。

8.0是一个大版本,ES历经3年终于从7.x来到了8.x时代。

8.x最主要的一个变化是,终于将type从ES代码中去掉了。

关于type,是es的一个老特性。之前在ES的概念中,type定位成数据库的表。如下:

为什么Elasticsearch7.x把type给干掉了?

但是在ES实际的设计中,Type只是Index中的一个字段。这个怎么理解呢?

ES在实际的数据存储是以Index为单位,Index有很多shard,每个shard对应了一个lucene文件结构。

而Type只是lucene中的一个字段。这会带来很多使用上的问题:

  • type并不像数据库那样,每个type会独立文件结构,而是都在一个lucene中,这样对于一个Index中有很多 type的情况下,这些type的性能是会相互收到影响的。一些小type,本来应该查询很快,但是由于跟大type放在一起,查询就不一定快了。

  • type由于只是lucene中的一个字段,而type里的字段,es并没有加上type前缀。这带来一个types之间类型互相影响的问题,比如type a有一个foo字段是keyword类型,另一个type b如果也有foo字段,是无法定义其他类型的,写入其他类型就会报错。因为foo字段在lucene也是唯一字段,只能定义一种类型。

  • 一个type的字段可能不多,但是一个Index定位了太多type,这些type的字段不断叠加,就会导致Index字段爆炸,引发很多元数据方面的问题。

出于这些考虑,ES就在考虑去掉type。

但是去掉type,是个非常复杂的任务,主要出于对历史版本的兼容性,ES无法暴力的从功能中把type去掉。ES的读写API、mapping设置等都包含了type。如果直接去掉,历史版本的用户就无法平滑升级了。

为此ES想到了一个好办法。ES在6.x开始逐步去掉type,在8.x正式完成。中间给用户一些兼容性的过渡时间。

大概的思路如下:

  • 在6.x,ES加上了index.mapping.single_type: true的默认设置,强制用户只能使用一个type字段。如果用户还需要有多个type的需求,那么需要显式把index.mapping.single_type设置为false。

  • 在6.x,type建议用户设置为_doc,这是为接下来_doc作为一个常量准备的,ES的思路是API从PUT {index}/{type}/{id},这种改成{index}/_doc/{id}。

  • 7.x去掉了index.mapping.single_type配置,type只能设置一个,且为_doc。

  • 7.x 在mapping中把type这层去掉,这时候如果用户有兼容性问题,支持加上include_type_name为true,增加type这层,但是名称只能为_doc。

  • 8.x去掉include_type_name参数,且代码中不在依赖多 type能力。

所以到现在8.x的版本,用户再也看不到type的痕迹了。

参考:https://www.jianshu.com/p/25743ad5dd6f

 https://blog.51cto.com/u_12132623/3027241 

https://blog.csdn.net/numbbe/article/details/109656567文章来源地址https://www.toymoban.com/news/detail-459610.html

到了这里,关于为什么Elasticsearch7.x把type给干掉了?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Elasticsearch:什么是向量和向量存储数据库,我们为什么关心?

    Elasticsearch 从 7.3 版本开始支持向量搜索。从 8.0 开始支持带有 HNSW 的 ANN 向量搜索。目前 Elasticsearch 已经是全球下载量最多的向量数据库。它允许使用密集向量和向量比较来搜索文档。 向量搜索在人工智能和机器学习领域有许多重要的应用。 有效存储和检索向量的数据库对于

    2024年02月08日
    浏览(51)
  • ElasticSearch(七):ES查询速度为什么那么快

    介绍给大家一个开源SpringCloud项目。整合了大部分开源中间件,详情信息可以查看文档: spring cloud开源组件开发 另外自己以后博客所讲解的代码内容,都会我的Git上同步(GitHub同步)GIT地址 ES使用的数据结构是倒排索引,在对搜索内容进行分词的时候,会根据搜索内容分词结

    2023年04月08日
    浏览(78)
  • 为什么选择elasticsearch分布式搜索引擎

    elasticsearch是一款非常强大的开源搜索引擎,具备非常多强大功能,可以帮助我们从海量数据中快速找到需要的内容 例如: 在CSDN上搜索代码 在电商网站搜索商品 在百度搜索答案 elasticsearch结合kibana、Logstash、Beats,也就是elastic stack(ELK)。被广泛应用在日志数据分析、实时监

    2024年02月12日
    浏览(49)
  • Elasticsearch 为什么会产生文档版本冲突?如何避免?

    先让大家直观的看到 Elasticsearch 文档版本冲突。 1.1 场景1:create 场景 1.2 场景2:批量更新场景模拟 模拟脚本1:循环写入数据 index.sh。 模拟脚本2:循环update_by_query 批量更新数据 update.sh。 由于:写入脚本 index.sh 比更新脚本 update.sh (执行一次,休眠1秒)执行要快,所以更新

    2023年04月08日
    浏览(43)
  • 入门ElasticSearch :为什么选择ES作为搜索引擎?

    随着数据量的不断增长,搜索和分析大规模数据集变得越来越重要。传统数据库在面对这种需求时往往表现不佳,这时候就需要一种专门用于搜索和分析的引擎。ElasticSearch (简称ES)就是这样一款强大的搜索引擎,它具有许多优势,使得它成为许多企业和开发者的首选。 简

    2024年02月09日
    浏览(46)
  • ElasticSearch第七讲 ES查询速度为什么那么快

    介绍给大家一个开源SpringCloud项目。整合了大部分开源中间件,详情信息可以查看文档: spring cloud开源组件开发 另外自己以后博客所讲解的代码内容,都会我的Git上同步(GitHub同步)GIT地址 ES使用的数据结构是倒排索引,在对搜索内容进行分词的时候,会根据搜索内容分词结

    2023年04月25日
    浏览(54)
  • ElasticSearch第七讲:ES查询速度为什么那么快

    介绍给大家一个开源SpringCloud项目。整合了大部分开源中间件,详情信息可以查看文档: spring cloud开源组件开发 另外自己以后博客所讲解的代码内容,都会我的Git上同步(GitHub同步)GIT地址 ES使用的数据结构是倒排索引,在对搜索内容进行分词的时候,会根据搜索内容分词结

    2023年04月19日
    浏览(48)
  • 【Elasticsearch专栏 02】深入探索:Elasticsearch为什么使用倒排索引而不是正排索引

    Elasticsearch选择使用倒排索引而不是正排索引,主要是基于倒排索引在处理全文搜索和大规模数据集时的优势。下面将详细解释为什么Elasticsearch更倾向于使用倒排索引,并提供一些简化的代码片段来说明这两种索引结构的基本差异。 正排索引是一种将文档映射到其包含的单词

    2024年02月22日
    浏览(44)
  • Elasticsearch 为什么能做到快速检索?秘密在这里!,Java全栈知识体系

    如果你了解 ES 应该知道,ES 可以说是对 Lucene 的一个封装,里面关于倒排索引的实现就是通过 lucene 这个 jar 包提供的 API 实现的,所以下面讲的关于倒排索引的内容实际上都是 lucene 里面的内容。 三、倒排索引 首先我们还不能忘了我们之前提的搜索需求,先看下建立倒排索引

    2024年04月12日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包