elasticsearch的ScanScroll如何使用

184次閱讀

共計(jì) 2561 個(gè)字符，預(yù)計(jì)需要花費(fèi) 7 分鐘才能閱讀完成。

這篇文章主要講解了“elasticsearch 的 ScanScroll 如何使用”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著丸趣 TV 小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“elasticsearch 的 ScanScroll 如何使用”吧！

ScanScroll 的特點(diǎn)

優(yōu)點(diǎn)

速度快

大數(shù)據(jù)量

缺點(diǎn)

不支持排序

不支持分頁(yè)

不支持評(píng)分

不支持續(xù)查

使用場(chǎng)景

看起來(lái)，缺點(diǎn)要比優(yōu)點(diǎn)多很多，不過(guò)它很有用。如果說(shuō) BULK 是為了快速入庫(kù)存在的，那 SCAN 就是為了快速出庫(kù)而誕生的。ES 的查詢性能優(yōu)越，但是分析能力弱。所以會(huì)有, 比如把 ES 的數(shù)據(jù)拉到 Hadoop 集群去分析計(jì)算的需求，當(dāng)然這個(gè)已經(jīng)有現(xiàn)成的插件了，不出所料也是用的 SCAN。如果 SCAN 遭遇 BULK，也就是 ES 到 ES 的話，它有另一個(gè)更熟悉的名字叫復(fù)制表。

使用方法

def scanTest():
 searchRes = es.search(index= users ,size=10,body={ query : { match_all : {}}},search_type= scan ,scroll= 10s )
 while True:
 scrollRes=es.scroll(scroll_id=searchRes[ _scroll_id],scroll= 10s ,ignore=[400, 404])
 res_list = scrollRes[hits][hits]
 if not len(res_list):
 break;
 for res in res_list:
 print res[_source][userName]

原理流程

整個(gè)流程比較清晰，先 count 一個(gè)總數(shù)，下面每次 scroll，返回 size* 分片數(shù)的數(shù)據(jù)，直到遍歷全部。SCAN 是支持查詢偏好 preference 的，可以指定分片，所以有人說(shuō)的 size* 主分片數(shù)，是不準(zhǔn)確的，這個(gè)很容易驗(yàn)證。

第一階段：Search

用 TotalHitCountCollector 統(tǒng)計(jì)下總數(shù)，并且確定（節(jié)點(diǎn)，查詢上下文 ID），Base64 編碼成 ScrollId 返回

第二階段：SearchScroll

根據(jù) ScrollId 去每個(gè)節(jié)點(diǎn)，找到查詢上下文 ID 執(zhí)行 XFilteredQuery，收集結(jié)果，合并返回

第一階段除了返回總數(shù)，還有一個(gè)很神秘的 ScrollId，這個(gè) ScrollId 長(zhǎng)成這樣，很像 Base64 編碼過(guò)的。一定不是 ID 那么簡(jiǎn)單，了解一番，果不其然，主要有 3 個(gè)部分組成 type,context,attributes

type 分別是 queryThenFetch,queryAndFetch,scan, 我們這里講的是 scan

attributes 只有一個(gè)元素，total_hits

context 是個(gè)分片的元組，有 2 個(gè)元素，分片 = [節(jié)點(diǎn) ID, 查詢上下文 ID]

ScrollId 是個(gè)很容易會(huì)暴露秘密的東西，我們會(huì)發(fā)現(xiàn) ScrollId 依賴的節(jié)點(diǎn) ID 和查詢上下文 ID 都是變量，查詢上下文 ID，每次請(qǐng)求都要遞增的。所以每次請(qǐng)求的 ScrollId 都不一樣，導(dǎo)致了如果在我們的 SCAN 過(guò)程意外終止，我們可能需要重新來(lái)過(guò)。

每次 SCAN，處理 Scroll 跳到下一頁(yè)去，我們自己指定 form 是無(wú)效的。

//SearchService
private void processScroll(InternalScrollSearchRequest request, SearchContext context) {
 // process scroll
 context.from(context.from() + context.size());
 context.scroll(request.scroll());
 // ...
 }

//ScanContext
public TopDocs execute(SearchContext context) throws IOException { ScanCollector collector = new ScanCollector(readerStates, context.from(), context.size(), context.trackScores());
 Query query = new XFilteredQuery(context.query(), new ScanFilter(readerStates, collector));
 try { context.searcher().search(query, collector);
 } catch (ScanCollector.StopCollectingException e) {
 // all is well
 }
 return collector.topDocs();}

自定義的 Filter，Collector，執(zhí)行搜索，收集那一頁(yè)的結(jié)果集

 //ScanContext
 public void collect(int doc) throws IOException { if (counter  = from) { docs.add(new ScoreDoc(docBase + doc, trackScores ? scorer.score() : 0f));
 }
 readerState.count++;
 counter++;
 if (counter  = to) {
 throw StopCollectingException;
 }
}

根據(jù)以往數(shù)據(jù)庫(kù)的認(rèn)識(shí)，count 操作總是很慢的，這讓我很擔(dān)心會(huì)延長(zhǎng)整個(gè)查詢的時(shí)間，后來(lái)我發(fā)現(xiàn)這種擔(dān)心是多余的，對(duì)于全文檢索 count 操作是很快速的。根據(jù)測(cè)試，17 億數(shù)據(jù) 24 個(gè)分片，平均每個(gè)分片的 count 時(shí)間在 200ms 到 700ms 之間，最糟糕的情況下總數(shù)也能在 1 秒內(nèi)返回，這對(duì)于整個(gè)查詢時(shí)間而言是可以接受的。

感謝各位的閱讀，以上就是“elasticsearch 的 ScanScroll 如何使用”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì) elasticsearch 的 ScanScroll 如何使用這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

正文完