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作为上下文来进行计算，可以保证准确性，但是生产环境下，不推荐这个参数，因为性能很差。