elasticsearch的store属性跟_source字段

众所周知_source字段存储的是索引的原始内容,那store属性的设置是为何呢?es为什么要把store的默认取值设置为no?设置为yes是否是重复的存储呢?

我们将一个field的值写入es中,要么是想在这个field上执行search操作(不知道具体的id),要么执行retrieve操作(根据id来检索)。但是,如果不显式的将该field的store属性设置为yes,同时_source字段enabled的情况下,你仍然可以获取到这个field的值。这就意味着在一些情况下让一个field不被index或者store仍然是有意义的。

当你将一个field的store属性设置为true,这个会在lucene层面处理。lucene是倒排索引,可以执行快速的全文检索,返回符合检索条件的文档id列表。在全文索引之外,lucene也提供了存储字段的值的特性,以支持提供id的查询(根据id得到原始信息)。通常我们在lucene层面存储的field的值是跟随search请求一起返回的(id+field的值)。es并不需要存储你想返回的每一个field的值,因为默认情况下每一个文档的的完整信息都已经存储了,因此可以跟随查询结构返回你想要的所有field值。

有一些情况下,显式的存储某些field的值是必须的:当_source被disabled的时候,或者你并不想从source中parser来得到field的值(即使这个过程是自动的)。请记住:从每一个stored field中获取值都需要一次磁盘io,如果想获取多个field的值,就需要多次磁盘io,但是,如果从_source中获取多个field的值,则只需要一次磁盘io,因为_source只是一个字段而已。所以在大多数情况下,从_source中获取是快速而高效的。

es中默认的设置_source是enable的,存储整个文档的值。这意味着在执行search操作的时候可以返回整个文档的信息。如果不想返回这个文档的完整信息,也可以指定要求返回的field,es会自动从_source中抽取出指定field的值返回(比如说highlighting的需求)。

你可以指定一些字段store为true,这意味着这个field的数据将会被单独存储。这时候,如果你要求返回field1(store:yes),es会分辨出field1已经被存储了,因此不会从_source中加载,而是从field1的存储块中加载。

哪些情形下需要显式的指定store属性呢?大多数情况并不是必须的。从_source中获取值是快速而且高效的。如果你的文档长度很长,存储_source或者从_source中获取field的代价很大,你可以显式的将某些field的store属性设置为yes。缺点如上边所说:假设你存储了10个field,而如果想获取这10个field的值,则需要多次的io,如果从_source中获取则只需要一次,而且_source是被压缩过的。
还有一种情形:reindex from some field,对某些字段重建索引的时候。从source中读取数据然后reindex,和从某些field中读取数据相比,显然后者代价更低一些。这些字段store设置为yes比较合适。
 
总结:
如果对某个field做了索引,则可以查询。如果store:yes,则可以展示该field的值。
但是如果你存储了这个doc的数据(_source enable),即使store为no,仍然可以得到field的值(client去解析)。
所以一个store设置为no 的field,如果_source被disable,则只能检索不能展示。
<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`
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值