深入剖析Elasticsearch的内部数据结构和机制:行存储、列存储与倒排索引之 ...

王柳  金牌会员 | 2024-8-27 23:52:51 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题

主题 539|帖子 539|积分 1617

❃博主首页 :   「码到三十五」   ,同名公众号 :「码到三十五」,wx号 : 「liwu0213」   
  ☠博主专栏 :   <mysql高手>    <elasticsearch高手>    <源码解读>    <java核心>    <面试攻关>   
  ♝博主的话 :  搬的每块砖,皆为峰峦之基;公众号搜索「码到三十五」关注这个爱发技术干货的coder,一起筑基   
   在当今的大数据时代,高效的数据检索和分析本领已成为许多应用程序的核心需求。Elasticsearch,作为一款强大的分布式搜索和分析引擎,正是为了满足这些需求而诞生的。它之所以能够在海量数据中实现毫秒级的搜索相应,以及机动的数据分析,要归功于其内部精妙的数据结构和机制。本文将详细探究Elasticsearch中的行存储(Stored Fields)、列存储(Doc Values)和倒排索引(Inverted Index)这三种关键组件,并解释它们是如何协同工作的。
  
  
1、 什么是行存

在Lucene中索引文档时,原始字段信息经过分词、转换处置惩罚后形成倒排索引,而原始内容本身并不直接保留。因此,为了检索时能够获取到字段的原始值,我们需要依赖额外的数据结构。Lucene提供了两种解决方案:Stored Field和doc_values。
Stored Field的设计初衷就是为了存储那些未经分词的字段原始值。这样,在执行查询操作时,除了能够获取到文档ID之外,我们还能够方便地检索到这些原始字段信息。
es中每个文档都被视为一个JSON对象,包罗多个字段。当文档被索引时,其原始数据或特定字段可以被存储在es中,以便后续能够检索到原始的字段值。这种存储方式类似于传统的行存储数据库,由于它存储了每个文档的所有字段。
然而,需要注意的是,es并不建议大量使用Stored Fields。这是由于存储原始字段值会增加磁盘使用量,并可能降低性能。相反,es更倾向于使用Doc Values和倒排索引来高效地检索和分析数据。因此,Stored Fields通常只用于存储那些需要在搜索结果中直接返回的字段。
2、 使用场景

那么,什么时候应该使用Stored Fields呢?


  • 需要返回原始字段值:假如你的应用程序需要在搜索结果中返回文档的原始字段值,那么你应该将这些字段设置为Stored Fields。例如,你可能需要表现给用户文档的标题、形貌或内容等字段。
  • 不支持Doc Values的字段范例:并非所有字段范例都支持Doc Values。对于那些不支持Doc Values的字段范例,假如你需要在搜索结果中返回这些字段的值,那么你需要将它们设置为Stored Fields。
3、 如何使用

可以通过映射(Mapping)来定义哪些字段应该被存储为Stored Fields。映射是定义文档结构和字段属性的过程。
3.1 定义store字段

  1. PUT order
  2. {
  3.    "mappings": {
  4.       "_doc": {
  5.          "properties": {
  6.             "counter": {
  7.                "type": "integer",
  8.                "store": false        //默认值就是false
  9.             },
  10.             "tags": {
  11.                "type": "keyword",
  12.                "store": true      //修改值为true
  13.             }
  14.          }
  15.       }
  16.    }
  17. }
复制代码
我们创建了一个名为order的索引,并定义了两个字段:counter和tags。我们将tags字段的store属性设置为true,这意味着tags字段的值将被存储为Stored Fields。而counter字段的store属性设置为false,表示不存储该字段的值。
3.2 添加 document

  1. PUT order/_doc/1
  2. {
  3.     "counter" : 1,
  4.     "tags" : ["red"]
  5. }
复制代码
3.3 实验带stored_fields参数去检索

  1. GET twitter/_doc/1?stored_fields=tags,counter
  2. 以上get操作的结果是:
  3. {
  4.    "_index": "twitter",
  5.    "_type": "tweet",
  6.    "_id": "1",
  7.    "_version": 1,
  8.    "found": true,
  9.    "fields": {           //此时多了名称为fields的字段,并且没有了_source
  10.       "tags": [          //tags的stroe属性设置为true,因此显示在结果中
  11.          "red"
  12.       ]
  13.    }
  14. }
复制代码
从 document 中获取的字段的值通常是array。
由于counter字段没有存储,当实验获取stored_fields时get会将其忽略。
在Elasticsearch中,不论将字段的store属性设置为true还是false,这些字段都会被存储。但存储的方式有所不同:


  • 当store设置为false时(这是默认配置),字段值仅存储在文档的_source字段中。这意味着,字段值作为整个文档JSON结构体的一部分被保存。
  • 当store设置为true时,字段值不仅存储在_source字段中,还会被单独存储在一个与_source平级的独立字段中。这样,该字段就有了两份拷贝:一份在_source中,另一份在独立的字段中。
那么,在什么情况下需要将字段的store属性设置为true呢?通常有两种情况:


  • _source字段在索引的映射中被禁用(disabled)
    在这种情况下,假如某个字段没有被定义为store=true,那么该字段将不会出现在查询结果中。因此,为了确保能够在查询结果中访问这些字段,需要将其设置为store=true。
  • _source字段的内容非常大
    当文档包罗大量数据时,例如一本书的内容,而查询时只需要访问此中的部分字段(如标题和日期),而不是整个_source字段,那么将这些字段设置为store=true可以进步查询效率。这样做可以避免在查询时解释整个_source字段,从而减少开销。当然,另一种选择是使用source filtering来减少网络开销,但将特定字段设置为store=true也是一种有效的优化方法。
4、 行存储与_source字段

行存储中,占比最大的通常是_source字段,它负责保存文档的原始数据。在数据写入阶段,Elasticsearch会将整个文档的JSON结构体作为字符串存储在_source字段中。在查询时,我们可以通过_source字段检索到原始写入的完整JSON结构体。

  1. {
  2.     "_index": "order",
  3.     "_type": "_doc",
  4.     "_id": "1",
  5.     "_version": 1,
  6.     "_seq_no": 0,
  7.     "_primary_term": 1,
  8.     "found": true,
  9.     "_source": {      //默认查询数据,返回的属性字段都在_source中
  10.         "user": "kimchy",
  11.         "post_date": "2009-11-15T14:12:12",
  12.         "message": "trying out Elasticsearch"
  13.     }
  14. }
复制代码
4.1 _source字段



  • _source字段的脚色:在Elasticsearch中,每个索引的文档都有一个特殊的字段叫做_source。这个字段包罗了文档的原始JSON表示。当你索引一个文档时,Elasticsearch会将这个文档的JSON形式存储为_source字段的内容。这意味着,无论你的文档包罗什么字段(例如,标题、形貌、日期等),它们都会被打包进这个_source字段中。
  • 存储与检索:由于_source字段存储了文档的完整原始数据,因此它通常是索引中最大的字段之一。当你执行一个检索操作时,Elasticsearch默认会返回匹配文档的_source字段,从而允许你访问到文档的原始数据。
  • 用途:拥有文档的原始数据非常有用,特别是在你需要重新构建文档的上下文时(例如,在搜索结果中表现文档的内容)。此外,许多Elasticsearch的功能,如高亮表现或字段提取,都依赖于_source字段的内容。
4.2 优化_source字段的使用



  • 关闭_source:假如你确定不需要文档的原始数据,可以在索引的映射中关闭_source字段的存储。这样做可以节省存储空间并进步索引速度。然而,这样做有一个重要的限制:关闭_source字段后,你将无法使用update、update_by_query和reindex等API,由于这些操作需要访问文档的原始数据。
  • 包罗/清除字段:另一种优化方法是选择性地包罗或清除_source字段中的某些数据。例如,你可能只想存储文档的某些关键字段,而不是整个JSON结构体。这可以通过在索引文档时使用特定的参数或在映射中定义_source字段的包罗/清除规则来实现。
4.3 注意事项



  • 在决定关闭_source字段或修改其包罗的内容之前,务必仔细考虑你的应用程序的需求。假如你在未来需要使用文档的原始数据,或者需要使用依赖于_source字段的Elasticsearch功能,那么关闭或修改_source字段可能会导致标题。
  • 只管关闭_source字段可以节省存储空间,但这通常不是优化Elasticsearch性能的首选方法。在大多数情况下,通过优化查询、选择符合的分析器、合理设置映射和使用硬件资源等方式,可以获得更好的性能提升。
5、 总结

行存储有几个重要的长处:


  • 完整性:由于_source字段存储了文档的完整原始数据,因此可以重新构建文档的上下文,这对于搜索结果展示、高亮表现等功能至关重要。
  • 机动性:拥有文档的原始数据使得ES能够提供多种功能,如字段提取、动态映射更改等,这些功能都依赖于_source字段的内容。
  • 便于调试:对于开发者而言,能够直接访问文档的原始数据有助于调试和验证索引的准确性。
然而,行存储也有一些潜在的开销和限制:


  • 存储本钱:由于每个文档的完整原始数据都被存储在索引中,这可能会增加存储空间的需求,尤其是对于大量文档或大型文档而言。
  • 写入性能:在写入大量文档时,将每个文档的完整JSON结构体存储到_source字段可能会对写入性能产生肯定的影响。
   在使用ES时,开发者需要根据详细的应用场景和需求来权衡行存储的利弊,并合理地配置和优化索引结构。例如,在某些场景下,可能只需要存储文档的部分字段而不是完整的JSON结构体,这可以通过在映射中关闭_source字段或只包罗须要的字段来实现。然而,需要注意的是,关闭_source字段后将无法使用依赖于_source字段的ES功能,如更新、重新索引等。因此,在做出决定时需要仔细考虑。
  
    关注公众号[码到三十五]获取更多技术干货 !   


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

王柳

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表