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