前言
ElasticSearch實現分頁查詢，有3種方式，他們在數據查詢中各自占據着不同的優勢，因此在搜索引擎的數據分頁過程中，如何更好地利用各自的優勢來進行數據查詢是一個非常重要的過程。
傳統分頁（from&size）
按照一般的查詢流程來說，如果我們想查詢前10條數據：
- 客戶端請求發送給某個節點；
- 節點轉發給各個分片，查詢每個分片上的前10條數據；
- 查詢結果返回給節點，並將數據進行整合，提取前10條數據；
- 將查詢結果返回給客戶端。
其原理就是當我們需要查詢第10條到第20條數據時，節點從各個分片上獲取10條數據並進行數據整合，然后從整合的數據中獲取第10條到第20條數據作為請求的結果。查詢的方法如下：
{
'from' : 0,
'size' : 10,
'query' : {
'term' : {
'user' : 'kimchy'
}
}
}
其中from定義了目標數據的偏移值，size定義了當前返回的事件數目。默認from為0，size為10，即所有的查詢默認返回前10條數據。
在實際測試過程中，當此方式的訪問頁碼越高，其執行的查詢效率就越低。假設我們現在需要獲取第20頁的數據，ElasticSearch不得不取出所有分片上的第1頁到第20頁的所有文檔，並對其進行合並排序，最終再取出from后的size條作為最終的返回結果；假設我們現在服務器上有16個分片，則我們需要匯總到shards*（from+size）條記錄，即需要16*（20+10）條記錄后，對其進行整合再做一次全局排序。因此，當索引非常大時，我們是無法使用from+size方式做深分頁的，分頁越深越容易OOM或者消耗內存，所以ES使用index.max_result_window:10000作為保護措施來避免這種情況的發生。但實際上當訪問數據非常大時，我們采用scroll游標的方式來獲取數據是更好地一種選擇。
大數據量的快照分頁（scroll）
相對於from&size的分頁來說，使用scroll可以模擬一個傳統的游標來記錄當前讀取的文檔信息位置。采用此分頁方法，不是為了實時查詢數據，而是為了查詢大量甚至全部的數據。此方式相對於維護了一份當前索引的快照信息，在執行數據查詢時，scroll將會從這個快照信息中獲取數據。它相對於傳統的分頁方式來說，不是查詢所有數據再剔除掉不需要的部分，而是記錄一個讀取的位置來保證下次對數據的繼續獲取。
1、scroll訪問數據過程
在使用scroll方式進行數據請求的過程中，主要分為四步，第一步首先通過設置訪問地址和端口號等信息獲取到客戶端對象；第二步設置請求的索引名稱、類型值、分頁大小以及每次請求的scroll游標存活時間等信息，然后向服務器發送數據查詢請求，並保存返回結果中的scroll_id值，此id值作為下次訪問的必要內容；第三步獲取到第一次請求的scroll_id值，再次設置數據請求的scroll游標存活時間，即可訪問下一組size大小的索引數據，依次循環直到數據請求完畢；第四步，清除滾屏的scroll_id值，釋放內存資源。
2、用Java代碼實現scroll訪問過程
當了解到scroll數據請求的原理之后，我們可以用Java代碼對其進行相應的測試，其中主要包括兩種實現方式，一種是采用Transport方式進行訪問，另一種是采用Rest方式進行訪問；但官方建議使用Rest方式進行請求，因為Transport在ES8.X版本中將會被廢棄。
3、采用scroll方式請求的缺點
- scroll是對數據的一種快照，當數據發生任何變化的情況下（比如新增、更新和刪除操作），是不會被感知到的，且維護scroll上下文也是非常昂貴的，因此不適用於實時和高並發的場景；
- 因為采用scroll方式，每次的數據請求都需要上一次請求結果中的scroll_id值來作為下次訪問時的標志，因此采用此方式無法進行頁面的隨機跳轉功能，只能進行滾動式數據瀏覽（類似於微博）；
search_after
它與scroll API非常相似，但與它不同，search_after參數是無狀態的，它始終針對最新版本的搜索器進行解析。 因此，排序順序可能會在步行期間發生變化，具體取決於索引的更新和刪除。
待補充....
總結
在這幾種方式中，scroll方式適用於ES中索引數據很大的情況，因為scroll第一次請求數據時的時間相對於后面請求size大小的時間大得多（原因是因為此種方式會將滿足條件的所有索引數據都以快照的方式保存在內存中，然后后續的數據請求都直接可以獲取，因此第一次和之后的請求時間會差別比較大）；當數據量比較小時，采用傳統的from&size方式的效率就會比較高。
無論是哪種方式，避免深分頁查詢。