ElasticSearch深度分頁解決方案
前言
Elasticsearch 是一個實時的分布式搜索與分析引擎，在使用過程中，有一些典型的使用場景，比如分頁、遍歷等。
在使用關系型數據庫中，我們被告知要注意甚至被明確禁止使用深度分頁，同理，在 Elasticsearch 中，也應該盡量避免使用深度分頁。
這篇文章主要介紹 Elasticsearch 中分頁相關內容!
From/Size參數
在ES中，分頁查詢默認返回最頂端的10條匹配hits。
如果需要分頁，需要使用from和size參數。
from參數定義了需要跳過的hits數，默認為0;
size參數定義了需要返回的hits數目的最大值。
一個基本的ES查詢語句是這樣的：
- POST /my_index/my_type/_search
- {
- "query": { "match_all": {}},
- "from": 100,
- "size": 10
- }
上面的查詢表示從搜索結果中取第100條開始的10條數據。
「那么，這個查詢語句在ES集群內部是怎么執行的呢?」
在ES中，搜索一般包括兩個階段，query 和 fetch 階段，可以簡單的理解，query 階段確定要取哪些doc，fetch 階段取出具體的 doc。
Query階段
如上圖所示，描述了一次搜索請求的 query 階段：·
- Client 發送一次搜索請求，node1 接收到請求，然后，node1 創建一個大小為from + size的優先級隊列用來存結果，我們管 node1 叫 coordinating node。
- coordinating node將請求廣播到涉及到的 shards，每個 shard 在內部執行搜索請求，然后，將結果存到內部的大小同樣為from + size 的優先級隊列里，可以把優先級隊列理解為一個包含top N結果的列表。
- 每個 shard 把暫存在自身優先級隊列里的數據返回給 coordinating node，coordinating node 拿到各個 shards 返回的結果后對結果進行一次合并，產生一個全局的優先級隊列，存到自身的優先級隊列里。
在上面的例子中，coordinating node 拿到(from + size) * 6條數據，然后合并并排序后選擇前面的from + size條數據存到優先級隊列，以便 fetch 階段使用。
另外，各個分片返回給 coordinating node 的數據用于選出前from + size條數據，所以，只需要返回唯一標記 doc 的_id以及用于排序的_score即可，這樣也可以保證返回的數據量足夠小。
coordinating node 計算好自己的優先級隊列后，query 階段結束，進入 fetch 階段。
Fetch階段
query 階段知道了要取哪些數據，但是并沒有取具體的數據，這就是 fetch 階段要做的。
上圖展示了 fetch 過程：
- coordinating node 發送 GET 請求到相關shards。
- shard 根據 doc 的_id取到數據詳情，然后返回給 coordinating node。
- coordinating node 返回數據給 Client。
coordinating node 的優先級隊列里有from + size 個_doc _id，但是，在 fetch 階段，并不需要取回所有數據，在上面的例子中，前100條數據是不需要取的，只需要取優先級隊列里的第101到110條數據即可。
需要取的數據可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」 來避免多次去同一分片取數據，從而提高性能。
「這種方式請求深度分頁是有問題的：」
我們可以假設在一個有 5 個主分片的索引中搜索。當我們請求結果的第一頁(結果從 1 到 10 )，每一個分片產生前 10 的結果，并且返回給 協調節點 ，協調節點對 50 個結果排序得到全部結果的前 10 個。
現在假設我們請求第 1000 頁—結果從 10001 到 10010 。所有都以相同的方式工作除了每個分片不得不產生前10010個結果以外。然后協調節點對全部 50050 個結果排序最后丟棄掉這些結果中的 50040 個結果。
「對結果排序的成本隨分頁的深度成指數上升。」
「注意1：」
size的大小不能超過index.max_result_window這個參數的設置，默認為10000。
如果搜索size大于10000，需要設置index.max_result_window參數
- PUT _settings
- {
- "index": {
- "max_result_window": "10000000"
- }
- }
「注意2：」
_doc將在未來的版本移除，詳見：
- https://www.elastic.co/cn/blog/moving-from-types-to-typeless-apis-in-elasticsearch-7-0
- https://elasticsearch.cn/article/158
深度分頁問題
Elasticsearch 的From/Size方式提供了分頁的功能，同時，也有相應的限制。
舉個例子，一個索引，有10億數據，分10個 shards，然后，一個搜索請求，from=1000000，size=100，這時候，會帶來嚴重的性能問題：CPU，內存，IO，網絡帶寬。
在 query 階段，每個shards需要返回 1000100 條數據給 coordinating node，而 coordinating node 需要接收10 * 1000，100 條數據，即使每條數據只有 _doc _id 和 _score，這數據量也很大了?
「在另一方面，我們意識到，這種深度分頁的請求并不合理，因為我們是很少人為的看很后面的請求的，在很多的業務場景中，都直接限制分頁，比如只能看前100頁。」
比如，有1千萬粉絲的微信大V，要給所有粉絲群發消息，或者給某省粉絲群發，這時候就需要取得所有符合條件的粉絲，而最容易想到的就是利用 from + size 來實現，不過，這個是不現實的，這時，可以采用 Elasticsearch 提供的其他方式來實現遍歷。
深度分頁問題大致可以分為兩類：
- 「隨機深度分頁：隨機跳轉頁面」
- 「滾動深度分頁：只能一頁一頁往下查詢」
「下面介紹幾個官方提供的深度分頁方法」
Scroll
Scroll遍歷數據
我們可以把scroll理解為關系型數據庫里的cursor，因此，scroll并不適合用來做實時搜索，而更適合用于后臺批處理任務，比如群發。
這個分頁的用法，「不是為了實時查詢數據」，而是為了「一次性查詢大量的數據(甚至是全部的數據」)。
因為這個scroll相當于維護了一份當前索引段的快照信息，這個快照信息是你執行這個scroll查詢時的快照。在這個查詢后的任何新索引進來的數據，都不會在這個快照中查詢到。
但是它相對于from和size，不是查詢所有數據然后剔除不要的部分，而是記錄一個讀取的位置，保證下一次快速繼續讀取。
不考慮排序的時候，可以結合SearchType.SCAN使用。
scroll可以分為初始化和遍歷兩部，初始化時將「所有符合搜索條件的搜索結果緩存起來(注意，這里只是緩存的doc_id，而并不是真的緩存了所有的文檔數據，取數據是在fetch階段完成的)」，可以想象成快照。
在遍歷時，從這個快照里取數據，也就是說，在初始化后，對索引插入、刪除、更新數據都不會影響遍歷結果。
「基本使用」
- POST /twitter/tweet/_search?scroll=1m
- {
- "size": 100,
- "query": {
- "match" : {
- "title" : "elasticsearch"
- }
- }
- }
初始化指明 index 和 type，然后，加上參數 scroll，表示暫存搜索結果的時間，其它就像一個普通的search請求一樣。
會返回一個_scroll_id，_scroll_id用來下次取數據用。
「遍歷」
- POST /_search?scroll=1m
- {
- "scroll_id":"XXXXXXXXXXXXXXXXXXXXXXX I am scroll id XXXXXXXXXXXXXXX"
- }
這里的scroll_id即 上一次遍歷取回的_scroll_id或者是初始化返回的_scroll_id，同樣的，需要帶 scroll 參數。
重復這一步驟，直到返回的數據為空，即遍歷完成。
「注意，每次都要傳參數 scroll，刷新搜索結果的緩存時間」。另外，「不需要指定 index 和 type」。
設置scroll的時候，需要使搜索結果緩存到下一次遍歷完成，「同時，也不能太長，畢竟空間有限。」
「優缺點」
缺點：
「scroll_id會占用大量的資源(特別是排序的請求)」
同樣的，scroll后接超時時間，頻繁的發起scroll請求，會出現一些列問題。
「是生成的歷史快照，對于數據的變更不會反映到快照上。」
「優點：」
適用于非實時處理大量數據的情況，比如要進行數據遷移或者索引變更之類的。
Scroll Scan
ES提供了scroll scan方式進一步提高遍歷性能，但是scroll scan不支持排序，因此scroll scan適合不需要排序的場景
「基本使用」
Scroll Scan 的遍歷與普通 Scroll 一樣，初始化存在一點差別。
- POST /my_index/my_type/_search?search_type=scan&scroll=1m&size=50
- {
- "query": { "match_all": {}}
- }
需要指明參數：
- search_type：賦值為scan，表示采用 Scroll Scan 的方式遍歷，同時告訴 Elasticsearch 搜索結果不需要排序。
- scroll：同上，傳時間。
- size：與普通的 size 不同，這個 size 表示的是每個 shard 返回的 size 數，最終結果最大為 number_of_shards * size。
「Scroll Scan與Scroll的區別」
Scroll-Scan結果「沒有排序」，按index順序返回，沒有排序，可以提高取數據性能。
初始化時只返回 _scroll_id，沒有具體的hits結果
size控制的是每個分片的返回的數據量，而不是整個請求返回的數據量。
Sliced Scroll
如果你數據量很大，用Scroll遍歷數據那確實是接受不了，現在Scroll接口可以并發來進行數據遍歷了。
每個Scroll請求，可以分成多個Slice請求，可以理解為切片，各Slice獨立并行，比用Scroll遍歷要快很多倍。
- POST /index/type/_search?scroll=1m
- {
- "query": { "match_all": {}},
- "slice": {
- "id": 0,
- "max": 5
- }
- }
- POST ip:port/index/type/_search?scroll=1m
- {
- "query": { "match_all": {}},
- "slice": {
- "id": 1,
- "max": 5
- }
- }
上邊的示例可以單獨請求兩塊數據，最終五塊數據合并的結果與直接scroll scan相同。
其中max是分塊數，id是第幾塊。
官方文檔中建議max的值不要超過shard的數量，否則可能會導致內存爆炸。
Search After
Search_after是 ES 5 新引入的一種分頁查詢機制，其原理幾乎就是和scroll一樣，因此代碼也幾乎是一樣的。
「基本使用：」
第一步：
- POST twitter/_search
- {
- "size": 10,
- "query": {
- "match" : {
- "title" : "es"
- }
- },
- "sort": [
- {"date": "asc"},
- {"_id": "desc"}
- ]
- }
返回出的結果信息 ：
- {
- "took" : 29,
- "timed_out" : false,
- "_shards" : {
- "total" : 1,
- "successful" : 1,
- "skipped" : 0,
- "failed" : 0
- },
- "hits" : {
- "total" : {
- "value" : 5,
- "relation" : "eq"
- },
- "max_score" : null,
- "hits" : [
- {
- ...
- },
- "sort" : [
- ...
- ]
- },
- {
- ...
- },
- "sort" : [
- 124648691,
- "624812"
- ]
- }
- ]
- }
- }
上面的請求會為每一個文檔返回一個包含sort排序值的數組。
這些sort排序值可以被用于search_after參數里以便抓取下一頁的數據。
比如，我們可以使用最后的一個文檔的sort排序值，將它傳遞給search_after參數：
- GET twitter/_search
- {
- "size": 10,
- "query": {
- "match" : {
- "title" : "es"
- }
- },
- "search_after": [124648691, "624812"],
- "sort": [
- {"date": "asc"},
- {"_id": "desc"}
- ]
- }
若我們想接著上次讀取的結果進行讀取下一頁數據，第二次查詢在第一次查詢時的語句基礎上添加search_after，并指明從哪個數據后開始讀取。
「基本原理」
es維護一個實時游標，它以上一次查詢的最后一條記錄為游標，方便對下一頁的查詢，它是一個無狀態的查詢，因此每次查詢的都是最新的數據。
由于它采用記錄作為游標，因此「SearchAfter要求doc中至少有一條全局唯一變量(每個文檔具有一個唯一值的字段應該用作排序規范)」
「優缺點」
「優點：」
無狀態查詢，可以防止在查詢過程中，數據的變更無法及時反映到查詢中。
不需要維護scroll_id，不需要維護快照，因此可以避免消耗大量的資源。
「缺點：」
由于無狀態查詢，因此在查詢期間的變更可能會導致跨頁面的不一值。
排序順序可能會在執行期間發生變化，具體取決于索引的更新和刪除。
至少需要制定一個唯一的不重復字段來排序。
它不適用于大幅度跳頁查詢，或者全量導出，對第N頁的跳轉查詢相當于對es不斷重復的執行N次search after，而全量導出則是在短時間內執行大量的重復查詢。
SEARCH_AFTER不是自由跳轉到任意頁面的解決方案，而是并行滾動多個查詢的解決方案。
總結
分頁方式 性能 優點 缺點 場景
from + size 低 靈活性好，實現簡單 深度分頁問題 數據量比較小，能容忍深度分頁問題
scroll 中 解決了深度分頁問題 無法反應數據的實時性(快照版本)維護成本高，需要維護一個 scroll_id 海量數據的導出需要查詢海量結果集的數據
search_after 高 性能最好不存在深度分頁問題能夠反映數據的實時變更 實現復雜，需要有一個全局唯一的字段連續分頁的實現會比較復雜，因為每一次查詢都需要上次查詢的結果，它不適用于大幅度跳頁查詢 海量數據的分頁
ES7版本變更
參照：https://www.elastic.co/guide/en/elasticsearch/reference/master/paginate-search-results.html#scroll-search-results
在7.*版本中，ES官方不再推薦使用Scroll方法來進行深分頁，而是推薦使用帶PIT的search_after來進行查詢;
從7.*版本開始，您可以使用SEARCH_AFTER參數通過上一頁中的一組排序值檢索下一頁命中。
使用SEARCH_AFTER需要多個具有相同查詢和排序值的搜索請求。
如果這些請求之間發生刷新，則結果的順序可能會更改，從而導致頁面之間的結果不一致。
為防止出現這種情況，您可以創建一個時間點(PIT)來在搜索過程中保留當前索引狀態。
POST /my-index-000001/_pit?keep_alive=1m
返回一個PIT ID：
{
"id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA=="
}
在搜索請求中指定PIT：
GET /_search
{
"size": 10000,
"query": {
"match" : {
"user.id" : "elkbee"
}
},
"pit": {
"id": "46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA==",
"keep_alive": "1m"
},
"sort": [
{"@timestamp": {"order": "asc", "format": "strict_date_optional_time_nanos", "numeric_type" : "date_nanos" }}
]
}
性能對比
分別分頁獲取1 - 10，49000 - 49010，99000 - 99010范圍各10條數據(前提10w條)，性能大致是這樣：
圖片
向前翻頁
對于向前翻頁，ES中沒有相應API，但是根據官方說法(https://github.com/elastic/elasticsearch/issues/29449)，ES中的向前翻頁問題可以通過翻轉排序方式來實現即：
對于某一頁，正序search_after該頁的最后一條數據id為下一頁，則逆序search_after該頁的第一條數據id則為上一頁。
國內論壇上，有人使用緩存來解決上一頁的問題：https://elasticsearch.cn/question/7711
圖片
總結
如果數據量小(from+size在10000條內)，或者只關注結果集的TopN數據，可以使用from/size 分頁，簡單粗暴
數據量大，深度翻頁，后臺批處理任務(數據遷移)之類的任務，使用 scroll 方式
數據量大，深度翻頁，用戶實時、高并發查詢需求，使用 search after 方式
個人思考
Scroll和search_after原理基本相同，他們都采用了游標的方式來進行深分頁。
這種方式雖然能夠一定程度上解決深分頁問題。但是，它們并不是深分頁問題的終極解決方案，深分頁問題「必須避免!!」。
對于Scroll，無可避免的要維護scroll_id和歷史快照，并且，還必須保證scroll_id的存活時間，這對服務器是一個巨大的負荷。
對于Search_After，如果允許用戶大幅度跳轉頁面，會導致短時間內頻繁的搜索動作，這樣的效率非常低下，這也會增加服務器的負荷，同時，在查詢過程中，索引的增刪改會導致查詢數據不一致或者排序變化，造成結果不準確。
Search_After本身就是一種業務折中方案，它不允許指定跳轉到頁面，而只提供下一頁的功能。
Scroll默認你會在后續將所有符合條件的數據都取出來，所以，它只是搜索到了所有的符合條件的doc_id(這也是為什么官方推薦用doc_id進行排序，因為本身緩存的就是doc_id，如果用其他字段排序會增加查詢量)，并將它們排序后保存在協調節點(coordinate node)，但是并沒有將所有數據進行fetch，而是每次scroll，讀取size個文檔，并返回此次讀取的最后一個文檔以及上下文狀態，用以告知下一次需要從哪個shard的哪個文檔之后開始讀取。
這也是為什么官方不推薦scroll用來給用戶進行實時的分頁查詢，而是適合于大批量的拉取數據，因為它從設計上就不是為了實時讀取數據而設計的。
