ES本地分片逆文档频率评分策略(Shard Local IDF)导致的评分异常原理解析

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: ES本地分片逆文档频率评分策略(Shard Local IDF)导致的评分异常原理解析

1、问题现象描述

假设有shard_local_idf索引(索引数据见文章末尾)

GET shard_local_idf/_search
{
  "query": {
    "match": {
      "title": "xiaomi shouji"
    }
  }
}


召回结果如下:

"hits" : [
      {
        "_index" : "shard_local_idf",
        "_type" : "_doc",
        "_id" : "11",
        "_score" : 1.9924302,
        "_routing" : "0",
        "_source" : {
          "title" : "xiaomi tv"
        }
      },
      {
        "_index" : "shard_local_idf",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 1.6282079,
        "_routing" : "1",
        "_source" : {
          "title" : "xiaomi shouji"
        }
      },
      {
        "_index" : "shard_local_idf",
        "_type" : "_doc",
        "_id" : "10",
        "_score" : 1.4816045,
        "_routing" : "1",
        "_source" : {
          "title" : "xiaomi tv"
        }
      }
      ...
    ]


2、原因分析

注意

如果对 相关性评分算法比较陌生,推荐先阅读以下文章:

Elasticsearch相关度评分算法(三):BM25(Okapi BM25)


2.1 词频得分(TF)相关性

对于_doc1和_doc11,两个文档词频都是1,他们在同一个索引,所以反词频一定相同,所以单就TF得分而言,这两个词得分肯定相同。


因此,对于上述问题,TF得分为常量,不是问题产生的主要原因。


2.2 反词频得分(IDF)相关性

假设对于搜索词“xiaomi”,两个文档的得分都是 x xx,对于_doc1 而言,由于假设 i d f idfidf 得分为 y yy 根据 i d f idfidf 计算函数可知 y yy > 0,而对于 _doc11 而言,tv 并未被命中,因此 i d f idfidf 得分为 0。


那么由此可计算两个文档的最终得分为:_doc1: x + y x + yx+y > _doc11: x xx

什么是逆文档频率评分(IDF)


2.3 eplain 查看执行计划

通过 explain 计算以下得分,如下

GET shard_local_idf/_search
{
  "explain": true, 
  "query": {
    "match": {
      "title": "xiaomi shouji"
    }
  }
}


对于 query:xiaomi shouji 查询结果如下:

微信截图_20221118202455.png


3、解决方案

3.1 开发和灰度环境或数据量不大的情况

search_type


dfs_query_then_fetch:使用从运行搜索的所有分片收集的信息,全局计算分布式词频。虽然此选项提高了评分的准确性,但它增加了每个分片的往返行程,这可能会导致搜索速度变慢。

query_then_fetch:(默认)为每个运行搜索的分片本地计算分布式词频。我们建议使用此选项进行更快的搜索,但评分可能不太准确。

测试环境设置:search_type = dfs_query_then_fetch 即表示在计算 i d f idfidf 的分值的时候,对全局进行计算,而不是 local_shard 。会牺牲一部分性能,换取准确性。这种方式适合于本地开发环境或者测试环境,或者生产环境中数据不对的情况下。


3.2 对于生产环境

对于生产环境,一般分布式数据库数据都不会太少,既然设计了多个分片,必然要考虑海量数据的情况。一般来说用 query_then_fetch 不太合适,会影响检索速度,牺牲用户体验。


生产环境真正的做法是避免分片不均衡,包括分片的大小、节点分片的分配数量、文档的均衡分配等。ES 本身通过 shard reblance 实现分片自动均衡策略,但是如果人工通过 routing 的方式分配数据,务必要保证数据按照某种机制,如分布式哈希表来控制数据的均衡分配,以避免这种情况的产生。


总结:在不了解分布式文档路由原理的前提下,不要随意使用 routing 来指定文档的分配机制。以免挖坑。

GET shard_local_idf/_search?search_type=dfs_query_then_fetch
{
  "explain": true, 
  "query": {
    "match": {
      "title": "xiaomi shouji"
    }
  }
}


4、测试数据

PUT shard_local_idf
{
  "settings": {
    "number_of_shards": 2,
    "number_of_replicas": 0
  }
}
PUT shard_local_idf/_bulk?routing=1&refresh=true
{"index":{"_id":1,"_type":"_doc"}}
{"title":"xiaomi shouji"}
{"index":{"_id":2,"_type":"_doc"}}
{"title":"huawei shouji"}
{"index":{"_id":3,"_type":"_doc"}}
{"title":"pingguo shouji"}
{"index":{"_id":4,"_type":"_doc"}}
{"title":"zhongxing shouji"}
{"index":{"_id":5,"_type":"_doc"}}
{"title":"sanxing shouji"}
{"index":{"_id":6,"_type":"_doc"}}
{"title":"bodao shouji"}
{"index":{"_id":7,"_type":"_doc"}}
{"title":"oppo shouji"}
{"index":{"_id":8,"_type":"_doc"}}
{"title":"lg shouji"}
{"index":{"_id":9,"_type":"_doc"}}
{"title":"vivo shouji"}
{"index":{"_id":10,"_type":"_doc"}}
{"title":"xiaomi tv"}
PUT shard_local_idf/_bulk?routing=0&refresh=true
{"index":{"_id":11,"_type":"_doc"}}
{"title":"xiaomi tv"}
{"index":{"_id":12,"_type":"_doc"}}
{"title":"huawei 12"}
{"index":{"_id":3,"_type":"_doc"}}
{"title":"pingguo 13"}
{"index":{"_id":14,"_type":"_doc"}}
{"title":"zhongxing 14"}
{"index":{"_id":15,"_type":"_doc"}}
{"title":"sanxing 51"}
{"index":{"_id":16,"_type":"_doc"}}
{"title":"bodao 16"}
{"index":{"_id":17,"_type":"_doc"}}
{"title":"oppo 17"}
{"index":{"_id":18,"_type":"_doc"}}
{"title":"lg 18"}
{"index":{"_id":19,"_type":"_doc"}}
{"title":"vivo 19"}
{"index":{"_id":20,"_type":"_doc"}}
{"title":"meizu 20"}


相关文章
|
14天前
|
监控 关系型数据库 MySQL
MySQL自增ID耗尽应对策略:技术解决方案全解析
在数据库管理中,MySQL的自增ID(AUTO_INCREMENT)属性为表中的每一行提供了一个唯一的标识符。然而,当自增ID达到其最大值时,如何处理这一情况成为了数据库管理员和开发者必须面对的问题。本文将探讨MySQL自增ID耗尽的原因、影响以及有效的应对策略。
54 3
|
24天前
|
安全 前端开发 Java
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第26天】Web安全是现代软件开发的重要领域,本文深入探讨了XSS和CSRF两种常见攻击的原理及防御策略。针对XSS,介绍了输入验证与转义、使用CSP、WAF、HTTP-only Cookie和代码审查等方法。对于CSRF,提出了启用CSRF保护、设置CSRF Token、使用HTTPS、二次验证和用户教育等措施。通过这些策略,开发者可以构建更安全的Web应用。
63 4
|
23天前
|
安全 Go PHP
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第27天】本文深入解析了Web安全中的XSS和CSRF攻击防御策略。针对XSS,介绍了输入验证与净化、内容安全策略(CSP)和HTTP头部安全配置;针对CSRF,提出了使用CSRF令牌、验证HTTP请求头、限制同源策略和双重提交Cookie等方法,帮助开发者有效保护网站和用户数据安全。
51 2
|
24天前
|
算法 Java 数据库连接
Java连接池技术,从基础概念出发,解析了连接池的工作原理及其重要性
本文详细介绍了Java连接池技术,从基础概念出发,解析了连接池的工作原理及其重要性。连接池通过复用数据库连接,显著提升了应用的性能和稳定性。文章还展示了使用HikariCP连接池的示例代码,帮助读者更好地理解和应用这一技术。
37 1
|
4天前
|
JavaScript 前端开发 API
Vue.js响应式原理深度解析:从Vue 2到Vue 3的演进
Vue.js响应式原理深度解析:从Vue 2到Vue 3的演进
25 0
|
10天前
|
API 持续交付 网络架构
深入解析微服务架构:原理、优势与实践
深入解析微服务架构:原理、优势与实践
13 0
|
11天前
|
存储 供应链 物联网
深入解析区块链技术的核心原理与应用前景
深入解析区块链技术的核心原理与应用前景
|
11天前
|
存储 供应链 安全
深度解析区块链技术的核心原理与应用前景
深度解析区块链技术的核心原理与应用前景
20 0
|
11天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
39 2
|
1月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
70 0

推荐镜像

更多
下一篇
无影云桌面