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做为上下文来进行计算，能够保证准确性，可是生产环境下，不推荐这个参数，由于性能不好。