ElasticSearch中的_source和store:既生瑜何生亮

本文探讨了Elasticsearch(_source)与Lucene(store属性)的存储机制,分析了不同配置下磁盘IO效率及存储冗余的影响,并对比了_source开启与字段store属性为true时的数据检索性能。

先介绍一个_source和store:                                     
(1):_source默认是打开的,将原始文档以JSON的形式存储在_source字段中,在lucene中_source只是一个字段,即在一个字段中存储了一个文档中所有字段的值。_source是es层面的设置,相当于给lucene多加了一个字段用于存储整个原始文档的值。

(2):字段中的store属性默认是false,即为不存储该字段;如果该字段的store属性设置为true,则在lucene中该字段的值被单独存储。

从以上可知,_source字段和字段属性store设置为true这两种情况都可以存储文档的字段值,如果同时都存储,岂不是重复存储了吗?那这两种情况有区别吗?
(1):在_source设置为打开,并且所有字段的store属性都设置为false的情况下,只在 _source字段中存储原始文档;当搜索时默认返回_source中的完整文档;如果只想返回某几个字段,则可以通过fields或者_source指定需要返回的字段,此时,es会自动从_source中抽取指定要返回的字段值。在这种情况下,无论是返回完整的文档,还是通过设置只返回某几个字段的值,都只需要一次磁盘IO,因为完整的文档都在_source一个字段中存储。

(2):在_source设置为关闭,并且所有字段的store都设置为true的情况下,_source字段中不再存储完整的原始文档了,文档的内容都以字段为单位,单独的被存储了。在这种情况下,查询结果中返回几个字段,就要进行几次磁盘IO,因为每个字段都是被单独存储的。

(3):在_source设置为打开,并且某几个字段的属性store被设置为true的情况下,_source字段中存储了原始文档,且那几个字段又被单独的存储了一次;在这种情况下,如果想返回这几个字段中的某一个或某几个时,es不会再从_source中抽取字段值了,而是直接从单独存储的字段中加载。

结论:
(1):即使文档中每个字段都设置成store=false:即不存储,es也把文档的原始内容在_source字段中存储了下来。

(2):如果字段被设置成store=true:即存储,则相当于字段值被存储了两次;如果考虑磁盘IO的性能和内容抽取方面的事情,存储两次可能有好处,但是在其他情况下存两次就是多余。

附加:
我们都知道es是基于lucene的,那么我们探讨一下lucene中的store属性;在lucene中如果字段的store属性被设置成true,就被存储;否则就不存储;不存储的字段,就不会出现在查询的返回结果中。ES自己加了一个_source,无论字段设置成是否存储,整个原始文档的内容都会被存储在_source字段中;这样以来,在绝大部分情况下,不用给每个字段的store属性设置成true,直接使用默认的false即不存储即可;因为可以从_source字段中返回文档的内容。

<think>好的,用户想了解Elasticsearch的搜索结果结构分析方法。首先,我需要回忆一下Elasticsearch的相关知识,确保信息准确。根据用户提供的引用内容,特别是引用[1]提到的相关性打分算法,应该在回答中包含评分机制的部分。 用户的问题分为两部分:搜索结果的结构分析方法。结构方面,我应该先列出主要的组成部分,比如分片信息、耗时、是否超时、命中文档数组聚合结果等。每个部分需要简要说明其作用,例如_total表示匹配总数,hits数组包含具体的文档数据,包括索引、类型、文档ID、评分源数据等。 然后是分析部分,用户可能需要知道如何解读这些结果。这里可以提到相关性评分,根据引用[1],需要说明ES5.0之前使用TF-IDF,之后改用BM25,两者在词频处理上的不同。同时,可以提到如何分析评分细节,比如使用explain参数或者Profile API,引用[2]中提到了Profile API的文档链接,可以引用这里。 另外,用户可能对聚合分析感兴趣,需要解释聚合结果的格式。结构优化方面,可能涉及分页源数据过滤,例如使用from/size或_source参数,这也是常见的优化手段。 最后,成相关问题时要覆盖用户可能进一步询问的点,比如评分算法、性能优化、聚合使用结果解析工具。确保问题与用户提供的引用内容相关联,比如引用[3]提到的IK分词器,可能影响搜索结果的解析,但用户当前问题不直接涉及,所以暂时不提。 需要检查是否有遗漏的部分,比如是否提到高亮显示或者排序参数,但根据用户提供的引用内容,可能不需要深入。保持回答结构清晰,分点说明,并正确引用相关来源。</think>Elasticsearch搜索结果结构解析及分析方法如下: ### 一、搜索结果核心结构 Elasticsearch返回的JSON格式搜索结果包含以下关键字段: ``` { "took": 5, "timed_out": false, "_shards": { "total": 3, "successful": 3, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 100, "relation": "eq" }, "max_score": 1.3862944, "hits": [ { "_index": "products", "_type": "_doc", "_id": "1", "_score": 1.3862944, "_source": { "title": "智能手机", "price": 2999 } } ] }, "aggregations": {...} } ``` ### 二、关键字段解析 1. **分片信息**: - `_shards.total`:参与查询的分片总数 - `_shards.successful`:成功返回结果的分片数量 - 异常情况需关注`failed`值是否大于0 2. **耗时指标**: - `took`:查询总耗时(单位:毫秒) - 性能优化时可结合Profile API分析各阶段耗时[^2] 3. **命中结果**: - `hits.total.value`:匹配文档总数 - `hits.max_score`:最高相关性得分,使用BM25算法计算[^1] - `hits.hits`数组包含实际文档数据,默认返回前10条 4. **相关性分析**: - `_score`字段表示文档匹配度,可通过`explain`参数查看评分细节: ```json GET /index/_search { "explain": true, "query": {...} } ``` ### 三、分析方法 1. **评分分析**: - 使用`explain`API查看TF-IDF/BM25计算过程[^1] - 对比不同文档的`_score`值优化查询条件 2. **聚合分析**: - 统计类聚合结果存储在`aggregations`字段 - 支持多级嵌套聚合分析 3. **性能分析**: - 结合`profile`参数获取查询执行细节: ```json GET /_search { "profile": true, "query": {...} } ``` 可分析rewrite、collector等阶段的性能瓶颈[^2] 4. **结构优化**: - 通过`_source`过滤减少网络传输 - 使用`stored_fields`指定返回字段 - 分页建议使用`search_after`替代`from/size`
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值