Elasticsearch 三種分頁(yè)方式

來源：zhexiao.blog.csdn.net/article/details/83864171

• from + size 淺分頁(yè)
• scroll 深分頁(yè)
• scroll刪除
• search_after 深分頁(yè)

from + size 淺分頁(yè)

"淺"分頁(yè)可以理解為簡(jiǎn)單意義上的分頁(yè)。它的原理很簡(jiǎn)單，就是查詢前20條數(shù)據(jù)，然后截?cái)嗲?0條，只返回10-20的數(shù)據(jù)。這樣其實(shí)白白浪費(fèi)了前10條的查詢。

GET?test_dev/_search
{
??"query":?{
????"bool":?{
??????"filter":?[
????????{
??????????"term":?{
????????????"age":?28
??????????}
????????}
??????]
????}
??},
??"size":?10,
??"from":?20,
??"sort":?[
????{
??????"timestamp":?{
????????"order":?"desc"
??????},
??????"_id":?{
????????"order":?"desc"
??????}
????}
??]
}

其中，from定義了目標(biāo)數(shù)據(jù)的偏移值，size定義當(dāng)前返回的數(shù)目。默認(rèn)from為0，size為10，即所有的查詢默認(rèn)僅僅返回前10條數(shù)據(jù)。

在這里有必要了解一下from/size的原理：

因?yàn)閑s是基于分片的，假設(shè)有5個(gè)分片，from=100，size=10。則會(huì)根據(jù)排序規(guī)則從5個(gè)分片中各取回100條數(shù)據(jù)數(shù)據(jù)，然后匯總成500條數(shù)據(jù)后選擇最后面的10條數(shù)據(jù)。

做過測(cè)試，越往后的分頁(yè)，執(zhí)行的效率越低。總體上會(huì)隨著from的增加，消耗時(shí)間也會(huì)增加。而且數(shù)據(jù)量越大，就越明顯！

scroll 深分頁(yè)

from+size查詢?cè)?0000-50000條數(shù)據(jù)（1000到5000頁(yè)）以內(nèi)的時(shí)候還是可以的，但是如果數(shù)據(jù)過多的話，就會(huì)出現(xiàn)深分頁(yè)問題。

為了解決上面的問題，elasticsearch提出了一個(gè)scroll滾動(dòng)的方式。

scroll 類似于sql中的cursor，使用scroll，每次只能獲取一頁(yè)的內(nèi)容，然后會(huì)返回一個(gè)scroll_id。根據(jù)返回的這個(gè)scroll_id可以不斷地獲取下一頁(yè)的內(nèi)容，所以scroll并不適用于有跳頁(yè)的情景。

GET?test_dev/_search?scroll=5m
{
??"query":?{
????"bool":?{
??????"filter":?[
????????{
??????????"term":?{
????????????"age":?28
??????????}
????????}
??????]
????}
??},
??"size":?10,
??"from":?0,
??"sort":?[
????{
??????"timestamp":?{
????????"order":?"desc"
??????},
??????"_id":?{
????????"order":?"desc"
??????}
????}
??]
}

• scroll=5m表示設(shè)置scroll_id保留5分鐘可用。
• 使用scroll必須要將from設(shè)置為0。
• size決定后面每次調(diào)用_search搜索返回的數(shù)量

然后我們可以通過數(shù)據(jù)返回的_scroll_id讀取下一頁(yè)內(nèi)容，每次請(qǐng)求將會(huì)讀取下10條數(shù)據(jù)，直到數(shù)據(jù)讀取完畢或者scroll_id保留時(shí)間截止：

GET?_search/scroll
{
??"scroll_id":?"DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAJZ9Fnk1d......",
??"scroll":?"5m"
}

注意：請(qǐng)求的接口不再使用索引名了，而是 _search/scroll，其中GET和POST方法都可以使用。

scroll刪除

根據(jù)官方文檔的說法，scroll的搜索上下文會(huì)在scroll的保留時(shí)間截止后自動(dòng)清除，但是我們知道scroll是非常消耗資源的，所以一個(gè)建議就是當(dāng)不需要了scroll數(shù)據(jù)的時(shí)候，盡可能快的把scroll_id顯式刪除掉。

清除指定的scroll_id：

DELETE?_search/scroll/DnF1ZXJ5VGhlbkZldGNo.....

清除所有的scroll：

DELETE?_search/scroll/_all

search_after 深分頁(yè)

scroll 的方式，官方的建議不用于實(shí)時(shí)的請(qǐng)求（一般用于數(shù)據(jù)導(dǎo)出），因?yàn)槊恳粋€(gè) scroll_id 不僅會(huì)占用大量的資源，而且會(huì)生成歷史快照，對(duì)于數(shù)據(jù)的變更不會(huì)反映到快照上。

search_after 分頁(yè)的方式是根據(jù)上一頁(yè)的最后一條數(shù)據(jù)來確定下一頁(yè)的位置，同時(shí)在分頁(yè)請(qǐng)求的過程中，如果有索引數(shù)據(jù)的增刪改查，這些變更也會(huì)實(shí)時(shí)的反映到游標(biāo)上。但是需要注意，因?yàn)槊恳豁?yè)的數(shù)據(jù)依賴于上一頁(yè)最后一條數(shù)據(jù)，所以無法跳頁(yè)請(qǐng)求。

為了找到每一頁(yè)最后一條數(shù)據(jù)，每個(gè)文檔必須有一個(gè)全局唯一值，官方推薦使用 _uid 作為全局唯一值，其實(shí)使用業(yè)務(wù)層的 id 也可以。

GET?test_dev/_search
{
??"query":?{
????"bool":?{
??????"filter":?[
????????{
??????????"term":?{
????????????"age":?28
??????????}
????????}
??????]
????}
??},
??"size":?20,
??"from":?0,
??"sort":?[
????{
??????"timestamp":?{
????????"order":?"desc"
??????},
??????"_id":?{
????????"order":?"desc"
??????}
????}
??]
}

• 使用search_after必須要設(shè)置from=0。
• 這里我使用timestamp和_id作為唯一值排序。
• 我們?cè)诜祷氐淖詈笠粭l數(shù)據(jù)里拿到sort屬性的值傳入到search_after。

使用sort返回的值搜索下一頁(yè)：

GET?test_dev/_search
{
??"query":?{
????"bool":?{
??????"filter":?[
????????{
??????????"term":?{
????????????"age":?28
??????????}
????????}
??????]
????}
??},
??"size":?10,
??"from":?0,
??"search_after":?[
????1541495312521,
????"d0xH6GYBBtbwbQSP0j1A"
??],
??"sort":?[
????{
??????"timestamp":?{
????????"order":?"desc"
??????},
??????"_id":?{
????????"order":?"desc"
??????}
????}
??]
}