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做爲上下文來進行計算，能夠保證準確性，可是生產環境下，不推薦這個參數，由於性能不好。