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