今天我們來研究ES的讀操作原理

• 一般來說查詢模式是遵循query_then_fetch的模式，也是一種兩階段查詢
  1. 第一階段查詢到匹配的id
  2. 第二階段再將對應到id的完整文檔抓出來
• 三階段的則是dfs_query_then_fetch
  1. 會先去收集所有shard的TF與DF，避免單一shard內比例失衡狀況
     • TF(term frequency)
     • DF(document frequency)
  2. 將結果加入請求，再進行query_then_fetch
  3. 如果是特別要求相關分數排序才考慮使用，因為效率較低

讀操作流程：

1. coordinator接收到client的請求
2. coordinator判斷要將請求發送到哪些nodes中
   • request中是否有指定preference
     • 可以指定_local, _shard等等限制查詢範圍
   • 沒有特別設定的話，一般會先選找replica shard
3. shard接收請求後，會進行local search，並建立local priority queue
4. nodes再將queue回傳給coordinator
5. coordinator將其整合成global priority queue
6. 根據參數來決定最終需要取得前幾筆資料
7. 再跟node要完整的資料
8. 最後將結果回傳給client

整體流程如下圖：

圖源：

https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf

我們這邊延伸query與fetch流程：

Query phase：

1. 先創建出search context
   • search context會紀錄在shard上的查詢操作的過程
2. 解析query，針對不同的query類型創建Query對象
   • ex: TermQuery, FuzzyQuery
3. 判斷請求是否有cache，如果有cache就可以直接拿結果。並且如果該查詢能建立cache，也會在查詢後建立cache
4. 添加collector
   • collector會收集查詢結果，進行過濾與排序
   • 將多個collector組建起來成為一個過濾流程(collector list)，以下為其中幾種：
     • MinimumScoreCollector：過濾掉相關分數低於設定的文檔
     • TopDocsCollector：會添加在collector list的頭部，對於決定Top N的結果是最核心的collector
5. 開始執行搜尋，對每個segment去搜尋結果，並計算相關分數
   • 會先對所有搜尋到的結果先計算一次分數
     • 接著根據上面的Query對象，來計算第二次算分

Fetch phase：

• 通過routing決定shard時，可能會只根據一個主要查詢欄位來進行查詢。但是真實查詢時可能會需要根據多個欄位，如果只查詢特定的shard會導致結果不準確
• 因此需要查詢的每個shard都需要返回完整的Top N 文檔，避免結果缺失
  • 這部分可以回去看我之前寫對於aggregation的介紹：https://ithelp.ithome.com.tw/articles/10325316
• 但是同時導致了如果要這麼大量的資料，IO跟CPU消耗會很大
• 因此第一個階段的query phase只會返回特定資訊，如文檔id
  在coordinator排序，選出最終TOP N文檔的名單後，再去fetch完整文檔

以上就是讀操作相關的原理
如果想要知道更多更細節的部分，相當建議去看我附上的資料來源
可以收穫更多

有關請求原理就在這邊告一段落
明天我們會進到生命週期的單元

參考資料
讀原理：
https://pdai.tech/md/db/nosql-es/elasticsearch-y-th-4.html
preference：
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/search-search.html#search-preference