Elasticsearch 分頁問題

1.form和size的方式

2.scroll api

3.search_after引數

按照一般的查詢流程來說，如果我想查詢前10條資料：

1 客戶端請求發給某個節點

2 節點**給個個分片，查詢每個分片上的前10條

3 結果返回給節點，整合資料，提取前10條

4 返回給請求客戶端

該分頁方式可以通過from+size的方式來進行實現。

from定義了目標資料的偏移值，size定義當前返回的事件數目。

get /fs/_search?pretty get /fs/_search?pretty

這種分頁方式只適合少量資料，因為隨from增大，查詢的時間就會越大，而且資料量越大，查詢的效率指數下降

優點：from+size在資料量不大的情況下，效率比較高

缺點：在資料量非常大的情況下，from+size分頁會把全部記錄載入到記憶體中，這樣做不但執行速遞特別慢，而且容易讓es出現記憶體不足而掛掉

比如要取第5001頁的資料，在分頁的時候，elasticsearch需要首先在每乙個節點上取出50020的資料，然後和每乙個節點的所有資料進行排序，取出排序後在50010到50020的資料，然後返回。這樣隨著資料量的增大，每次分頁時排序的開銷會越來越大。

一般的分頁需求我們可以使用form和size的方式實現，但是這種分頁方式在深度分頁的場景下應該是要避免使用的。深度分頁會隨著請求的頁次增加，所消耗的記憶體和時間的增長也是成比例的增加，為了避免深度分頁產生的問題，elasticsearch從2.0版本開始，增加了乙個限制：

index.max_result_window =10000

scroll就是維護了當前索引段的乙份快照資訊–快取（這個快照資訊是你執行這個scroll查詢時的快照）

可以把 scroll 分為初始化和遍歷兩步：

1、初始化時將所有符合搜尋條件的搜尋結果快取起來，可以想象成快照；

get fs/_search?scroll=3m
}, "size": 3
}

初始化的時候就像是普通的search一樣

其中的scroll=3m代表當前查詢的資料快取3分鐘

size：3 代表當前查詢3條資料

2、遍歷時，從這個快照裡取資料；

在遍歷時候，拿到上一次遍歷中的_scroll_id，然後帶scroll引數，重複上一次的遍歷步驟，直到返回的資料為空，表示遍歷完成。

每次都要傳引數scroll，重新整理搜尋結果的快取時間，另外不需要指定index和type（不要把快取的時時間設定太長，占用記憶體）。

scroll雖然能夠解決from size帶來的問題，但是由於它代表的是某個時刻的snapshot，不適合做實時查詢；且由於scroll後接超時時間，頻繁地發起scroll請求，也會出現一系列問題。

search_after: 效能優秀，類似於優化後的分頁查詢，歷史條件過濾掉資料。

檢索第一頁的查詢如下所示：

post twitter/_search
},"sort": [,]
}

每個文件具有乙個唯一值的字段應該用作排序規範的仲裁器。否則，具有相同排序值的文件的排序順序將是未定義的。建議的方法是使用欄位_id，它肯定包含每個文件的乙個唯一值。

get twitter/_search
},"search_after": [1463538857, "654323"],
"sort": [,]
}

當我們使用 search_after 引數的時候，from引數必須被設定成 0 或 -1 （當然你也可以不設定這個from引數）。

search_after缺點是不能夠隨機跳轉分頁，只能是一頁一頁的向後翻，並且需要至少指定乙個唯一不重複欄位來排序。它與滾動api非常相似，但與它不同，search_after引數是無狀態的，它始終針對最新版本的搜尋器進行解析。因此，排序順序可能會在步行期間發生變化，具體取決於索引的更新和刪除。