序
Elasticsearch是一個實時分布式搜索和分析引擎。在使用的過程中，有一些典型的使用場景，比如分頁、遍歷等。
在關系數據庫的使用中，我們被告知要注意甚至明確禁止深度分頁的使用。同樣，在Elasticsearch中，也要盡量避免使用深度分頁。
本文主要介紹Elasticsearch中分頁相關的內容！
From/Size參數
在ES中，缺省情況下分頁查詢返回前10個匹配的命中結果。
如果需要分頁，您需要使用from和size參數。
from參數定義需要跳過的命中次數，默認值為0；
size參數定義要返回的最大命中數。
基本的ES查詢語句是這樣的：
帖子/我的索引/我的類型/_搜索
{
查詢' :{'match_all':{}，
從：100開始，
尺寸' :10
}
上面的查詢表示從搜索結果的第100條開始的10條數據。
那么，這個查詢語句在ES集群內部是怎么執行的呢？
在ES中，搜索一般包括兩個階段，查詢和提取階段，可以簡單理解。查詢階段決定取哪張單據，取貨階段取具體的單據。
查詢階段
如上圖所示，描述了搜索請求的查詢階段：
客戶端發送搜索請求，node1接收該請求。然后，node1創建一個優先級隊列，其大小為size，用于存儲結果。我們稱節點1為協調節點。
協調節點將請求廣播給相關的分片，每個分片在內部執行搜索請求，然后在內部將結果存儲在與from size大小相同的優先級隊列中，可以理解為包含前N個結果的列表。
每個碎片將臨時存儲在自己的優先級隊列中的數據返回給協調節點。在得到每個shard返回的結果后，協調節點將結果合并一次，生成一個全局優先級隊列，并存儲在自己的優先級隊列中。
在上面的例子中，協調節點獲得(來自size) * 6條數據，然后對它們進行合并和排序，然后從size中選擇前面的幾條數據存儲在優先級隊列中，以便在fetch階段使用。
此外，每個切片返回給協調節點的數據用于從size數據中選擇第一個，因此只需要返回唯一標記doc的_id和用于排序的_score，這也可以保證返回的數據足夠小。
在協調節點計算出自己的優先級隊列后，查詢階段結束，進入獲取階段。
獲取階段
查詢階段知道要獲取哪些數據，但它不獲取特定的數據，這是獲取階段要做的事情。
上圖顯示了獲取過程：
l>- 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，要給所有粉絲群去發消息，或者給某省粉絲群fa，這時候就需要取得所有符合條件的粉絲，而最容易想到的就是利用 from + size 來實現，不過，這個是不現實的，這時，可以采用 Elasticsearch 提供的其他方式來實現遍歷。
深度分頁問題大致可以分為兩類：
- 隨機深度分頁：隨機跳轉頁面
- 滾動深度分頁：只能一頁一頁往下查詢
下面介紹幾個官方提供的深度分頁方法
Scroll
Scroll遍歷數據
我們可以把scroll理解為關系型數據庫里的cursor，因此，scroll并不適合用來做實時搜索，而更適合用于后臺批處理任務，比如群fa
這個分頁的用法，不是為了實時查詢數據，而是為了一次性查詢大量的數據（甚至是全部的數據）。
因為這個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": ,
"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" : ,
"failed" :
},
"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
總結
- 如果數據量?。╢rom+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用來給用戶進行實時的分頁查詢，而是適合于大批量的拉取數據，因為它從設計上就不是為了實時讀取數據而設計的。
509006974