转载

elasticsearch学习笔记高级篇(九)——多shard场景下相关度分数不准确问题

场景分析:

在某个shard中,有很多个document包含了title中有java这个关键字,比如说10个doc的title中包含了java。

当一个搜索title包含java的请求到这个shard的时候,应该会这么计算relevance score相关度分数。TF/IDF算法:

(1)在一个document的title中java出现了几次

(2)在所有的document的title中,java出现了几次

(3)这个document的title的长度

由于shard只是一部分的document,默认情况下就在shard本地计算IDF。当有多个shard的时候,比如在一个shard中,只有一个document title包含java,此时计算shard local IDF就会分数很高,导致相关度分数很高。这就有可能导致出现的搜索结果,似乎不太是你想要的结果。也许相关度很高的doc排在了后面,分数不高,而相关度很低的doc排在了前面,分数很高。

如何解决该问题

(1)在生产环境下,数据量大,尽可能实现均匀分配

数据量很大的话,在概率学的背景下,elasticsearch都是在多个shard中均匀路由数据的,路由的时候根据_id,实现负载均衡。

比如说有10个document,title都包含java,一共有5个shard,那么在概率学的背景下,如果负载均衡的话,其实每个shard都应该有2个doc,title包含java。如果说数据分布均匀的话,其实就没有因为IDF不准确导致相关度分数不准确的问题。

(2)测试环境下,将索引的primary shard设置为1个

如果说只有一个shard,那么当然所有的document都在这个shard里面,也就没有没有因为IDF不准确导致相关度分数不准确的问题。

(3)测试环境下,搜索附带search_type=dfs_query_then_fetch参数

带上search_type=dfs_query_then_fetch参数,就会将local IDF取出来计算global IDF。也就是在计算一个doc的相关度分数的时候,就会将所有shard对local IDF计算一下,获取出来在本地进行global IDF分数的计算,此时会将所有shard的doc作为上下文来进行计算,可以保证准确性,但是生产环境下,不推荐这个参数,因为性能很差。

原文  https://segmentfault.com/a/1190000019363398
正文到此结束
Loading...