原文地址在這里，我進行了重新排版和措辭修正潤色，覺得算是比較好的科普文章。最近在進行業務的查詢優化，有必要學習一下 ES 的查詢，所以就轉載了，其實本人真的特別覺得轉載是對原文作者的不尊重，不過原文這排版真惡心。

作者：好記性不如爛筆頭！
出處：http://www.cnblogs.com/zlslch/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利。

Elasticsearch Client 發送搜索請求，某個索引庫，一般默認是5個分片（shard），它返回的時候，由各個分片匯總結果回來，附上官網API。

在查詢 ES 時，可以指定的搜索類型為下面四種：

• QUERY_THEN_FETCH
• QUERY_AND_FEATCH
• DFS_QUERY_THEN_FEATCH
• DFS_QUERY_AND_FEATCH

那么這 4 種搜索類型有什么區別？在講這四種搜索類型的區別之前， 先說明一下分布式搜索背景。

分布式搜索面對的共性問題

ES 天生就是為分布式而生， 但分布式有分布式的缺點。 比如要搜索某個單詞， 但是數據卻分別在 5 個分片（Shard)上面， 這 5 個分片可能在 5 臺主機上面。 因為全文搜索天生就要排序（ 按照匹配度進行排名） ,但數據卻在 5 個分片上， 如何得到最后正確的排序呢？ ES是這樣做的， 大概分兩步：

1. ES 客戶端將會同時向 5 個分片發起搜索請求。
2. 這 5 個分片基于本分片的內容獨立完成搜索， 然后將符合條件的結果全部返回。

客戶端將返回的結果進行重新排序和排名，最后返回給用戶。也就是說，ES的一次搜索，是一次 scatter/gather 過程（這個跟mapreduce也很類似）

然而這其中有兩個問題：

1. 數量問題。 比如， 用戶需要搜索"衣服"， 要求返回符合條件的前 10 條。 但在 5個分片中， 可能都存儲著衣服相關的數據。 所以 ES 會向這 5 個分片都發出查詢請求， 并且要求每個分片都返回符合條件的 10 條記錄。當ES得到返回的結果后，進行整體排序，然后取最符合條件的前10條返給用戶。 這種情況， ES 中 5 個 shard 最多會收到 10*5=50條記錄， 這樣返回給用戶的結果數量會多于用戶請求的數量。
2. 排名問題。 上面說的搜索， 每個分片計算符合條件的前 10 條數據都是基于自己分片的數據進行打分計算的。計算分值使用的詞頻和文檔頻率等信息都是基于自己分片的數據進行的， 而 ES 進行整體排名是基于每個分片計算后的分值進行排序的(相當于打分依據就不一樣， 最終對這些數據統一排名的時候就不準確了)， 這就可能會導致排名不準確的問題。如果我們想更精確的控制排序， 應該先將計算排序和排名相關的信息（ 詞頻和文檔頻率等打分依據） 從 5 個分片收集上來， 進行統一計算， 然后使用整體的詞頻和文檔頻率為每個分片中的數據進行打分， 這樣打分依據就一樣了。

ES 需要解決的問題

所以，Elasticsearch 在搜索過程中需要解決的問題也類似：

1. 返回數據量問題，如果數據分散在默認的5個分片上，ES會向5個分片同時發出請求，每個分片都返回10條數據，最終會返回總數據為：5 * 10 = 50條數據，遠遠大于用戶請求。
2. 返回數據排名問題，每個分片計算符合條件的前10條數據都是基于自己分片的數據進行打分計算的。計算分值（score）使用的詞頻和文檔頻率等信息都是基于自己分片的數據進行的，而ES進行整體排名是基于排名是基于每個分片計算后的分值進行排序的（打分依據就不一致，最終對這些數據統一排名的時候就不準確了）

舉個例子闡述下 排名問題 ，一個獎學金的判定的 Case：

假設某學校有一班和二班兩個班級。期末考試之后， 學校要給全校前十名學員發獎金。但是一班和二班考試的時候使用的不是一套試卷。

一班： 使用的是 A 卷【 A 卷偏容易】

二班： 使用的是 B 卷【 B 卷偏難】

結果就是一班的最高分是 100 分， 最低分是 80 分。二班的最高分是 70 分， 最低分是 30 分。這樣全校前十名就都是一班的學員了。 這顯然是不合理的。因為一班和二班的試卷難易程度不一樣， 也就是打分依據不一樣， 所以不能放在一塊排名。這就解釋了剛才的排名問題，如果想要保證排名準確的話， 需要保證一班和二班使用的試卷內容一樣。可以這樣做， 把 A 卷和 B 卷的內容組合到一塊， 作為 C 卷。一班和二班考試都使用 C 卷， 這樣他們的打分依據就一樣了， 最終再根據所有學員的成績進行排名。

ES 的解決方案

這兩個問題， ES 也沒有什么較好的解決方法， 最終把選擇的權利交給用戶， 方法就是在搜索的時候指定 search type。

Elasticsearch在搜索問題的解決思路

1. 數量問題
   • 先從每個分片匯總查詢的數據id，進行排名，取前10條數據；
   • 第二步：根據這10條數據id，到不同分片獲取數據；
2. 排名問題：將各個分片打分標準統一

Elasticsearch的搜索類型（SearchType）

query and fetch

向索引的所有分片 （ shard）都發出查詢請求， 各分片返回的時候把元素文檔 （ document）和計算后的排名信息一起返回。這種搜索方式是最快的。 因為相比下面的幾種搜索方式， 這種查詢方法只需要去 shard查詢一次。 但是各個 shard 返回的結果的數量之和可能是用戶要求的 size 的 n 倍。

• 優點：這種搜索方式是最快的。因為相比后面的幾種es的搜索方式，這種查詢方法只需要去shard查詢一次。

• 缺點：返回的數據量不準確， 可能返回(N*分片數量)的數據并且數據排名也不準確，同時各個shard返回的結果的數量之和可能是用戶要求的size的n倍。

query then fetch（ default ）

如果你搜索時， 沒有指定搜索方式， 就是使用的這種搜索方式。 這種搜索方式， 大概分兩個步驟：

1. 先向所有的 shard 發出請求， 各分片只返回文檔 id(注意， 不包括文檔 document)和排名相關的信息(也就是文檔對應的分值)， 然后按照各分片返回的文檔的分數進行重新排序和排名， 取前 size 個文檔。
2. 根據文檔 id 去相關的 shard 取 document。 這種方式返回的 document 數量與用戶要求的大小是相等的。

• 優點：返回的數據量是準確的。
• 缺點：性能比 query and fetch 差，并且數據排名不準確。

DFS query and fetch

這種方式比 query and fetch 多了一個 DFS 步驟，有這一步，可以更精確控制搜索打分和排名。也就是在進行查詢之前， 先對所有分片發送請求， 把所有分片中的詞頻和文檔頻率等打分依據全部匯總到一塊， 再執行后面的操作。

• 優點：數據排名準確
• 缺點：性能比 query then fetch 差，返回的數據量不準確， 可能返回 (N*分片數量) 的數據

DFS query then fetch

比 query then fetch 多了一個 DFS 步驟。也就是在進行查詢之前， 先對所有分片發送請求， 把所有分片中的詞頻和文檔頻率等打分依據全部匯總到一塊， 再執行后面的操作。

• 優點：數據量是準確、數據排名準確
• 缺點：性能最差

DFS 是一個什么樣的過程？
從 es 的官方網站我們可以發現， DFS 其實就是在進行真正的查詢之前， 先把各個分片的詞頻率和文檔頻率收集一下， 然后進行詞搜索的時候， 各分片依據全局的詞頻率和文檔頻率進行搜索和排名。 顯然如果使用 DFS_QUERY_THEN_FETCH 這種查詢方式， 效率是最低的，因為一個搜索， 可能要請求 3 次分片。 但， 使用 DFS 方法， 搜索精度是最高的。

小結

從性能考慮 QUERY_AND_FETCH 是最快的， DFS_QUERY_THEN_FETCH 是最慢的。從搜索的準確度來說， DFS 要比非 DFS 的準確度更高，用戶可以酌情根據業務場景進行類型選擇。