ElasticSearch近實(shí)時(shí)搜索的實(shí)現(xiàn)

時(shí)間：2021-10-13 14:02:50

關(guān)鍵字： rc ic

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]作者：cdai來(lái)源：blog.csdn.net/dc_726/article/details/942528501.近實(shí)時(shí)搜索1.1實(shí)時(shí)與近實(shí)時(shí)實(shí)時(shí)搜索（Real-timeSearch）很好理解，對(duì)于一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)，執(zhí)行插入以后立刻就能搜索到剛剛插入到數(shù)據(jù)。而近實(shí)時(shí)（NearRea...

作者：cdai

來(lái)源：blog.csdn.net/dc_726/article/details/94252850

1.近實(shí)時(shí)搜索

1.1 實(shí)時(shí)與近實(shí)時(shí)

實(shí)時(shí)搜索（Real-time Search）很好理解，對(duì)于一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)，執(zhí)行插入以后立刻就能搜索到剛剛插入到數(shù)據(jù)。而近實(shí)時(shí)（Near Real-time），所謂“近”也就是說(shuō)比實(shí)時(shí)要慢一點(diǎn)點(diǎn)。

1.2 近實(shí)時(shí)的挑戰(zhàn)

對(duì)于一個(gè)單機(jī)系統(tǒng)來(lái)說(shuō)，這也并不容易實(shí)現(xiàn)，因?yàn)檫€要保證數(shù)據(jù)的持久化，還要利用緩存等技術(shù)加快數(shù)據(jù)的訪問(wèn)（注：這里不討論內(nèi)存計(jì)算系統(tǒng)）。對(duì)于ElasticSearch這樣一個(gè)分布式系統(tǒng)，保證持久化的同時(shí)，還要初始化好用于全文檢索的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，做到近實(shí)時(shí)的難度可想而知。而這就是ElasticSearch大獲成功的地方，也正是本文所要學(xué)習(xí)的主題：ElasticSearch是如何解決這些實(shí)現(xiàn)近實(shí)時(shí)搜索的難題的。

2.ElasticSearch的實(shí)現(xiàn)

2.1 不可變的數(shù)據(jù)結(jié)構(gòu)

有經(jīng)驗(yàn)的程序員一定知道，在做并發(fā)編程時(shí)，控制可變數(shù)據(jù)的并發(fā)訪問(wèn)是個(gè)難題。古往今來(lái)，各種粗細(xì)粒度的鎖，信號(hào)量，Actor模型等概念層出不窮。而另一流派函數(shù)式編程更為徹底，尤其是純函數(shù)式比如Haskell，用不可變數(shù)據(jù)來(lái)徹底解決這個(gè)問(wèn)題。
在ElasticSearch這樣主要服務(wù)全文檢索的系統(tǒng)中，Inverted Index是核心數(shù)據(jù)結(jié)構(gòu)。這里簡(jiǎn)單說(shuō)一句，Inverted Index本質(zhì)上一組document中term的各種統(tǒng)計(jì)信息，比如最重要的詞頻，以及其他許多統(tǒng)計(jì)信息，比如文檔長(zhǎng)度，詞序等等。要做到近實(shí)時(shí)搜索，就要保證新數(shù)據(jù)能快速構(gòu)建，已有數(shù)據(jù)能被高速訪問(wèn)。解決問(wèn)題的關(guān)鍵就在于Inverted Index的不可變性，這也是ElasticSearch底層依賴(lài)的高性能Lucene的根本奧秘。

2.2 從不可變到可變

所以當(dāng)用戶(hù)向ElasticSearch中的數(shù)據(jù)庫(kù)插入一組document后，底層Lucene構(gòu)建出一個(gè)不可變的Inverted Index?？晌覀冎溃粋€(gè)數(shù)據(jù)庫(kù)不可能是靜態(tài)的，當(dāng)用戶(hù)再次插入新數(shù)據(jù)時(shí)，Lucene該怎樣處理呢？答案就是增量保存和邏輯標(biāo)記。

所謂增量保存就是為新數(shù)據(jù)構(gòu)建一個(gè)新的不可變的Inverted Index，當(dāng)執(zhí)行搜索時(shí)，要合并每個(gè)Inverted Index中的統(tǒng)計(jì)信息得到最終結(jié)果。保存新數(shù)據(jù)的問(wèn)題解決了，而邏輯標(biāo)記就是解決更新和刪除的。Lucene為每個(gè)Inverted Index都額外維護(hù)一個(gè)del數(shù)據(jù)結(jié)構(gòu)，當(dāng)執(zhí)行刪除時(shí)，只需在del中標(biāo)記，這樣最終結(jié)果就會(huì)排出掉刪除掉document。同理，更新時(shí)也是給老數(shù)據(jù)做標(biāo)記，新document會(huì)保存在新的Inverted Index中，最終結(jié)果會(huì)使用最新版本數(shù)據(jù)的統(tǒng)計(jì)信息。在Lucene中，每個(gè)Inverted Index叫做Segment，而管理這些Segment的叫做Index。

ElasticSearch中一個(gè)數(shù)據(jù)庫(kù)被稱(chēng)為Index，每個(gè)Index可以在創(chuàng)建時(shí)指定要?jiǎng)澐譃閹追?，每一份叫做Shard。Shard會(huì)被ElasticSearch分配到不同結(jié)點(diǎn)，運(yùn)行中還會(huì)根據(jù)壓力做Rebalance。這個(gè)Shard其實(shí)就是Lucene中的Index。由于不同層級(jí)上名字的重復(fù)，初學(xué)時(shí)很容易混淆。

這種思想其實(shí)并非獨(dú)創(chuàng)，在其他一些高級(jí)數(shù)據(jù)結(jié)構(gòu)中也能找到它的影子。如果沒(méi)記錯(cuò)的話，一個(gè)經(jīng)典的例子就是LSM樹(shù)：https://en.m.wikipedia.org/wiki/Log-structured_merge-tree。

2.3 分布式數(shù)據(jù)存儲(chǔ)

對(duì)于分布式的數(shù)據(jù)存儲(chǔ)，ElasticSearch采取了經(jīng)典的做法，對(duì)數(shù)據(jù)進(jìn)行分片和路由，這里每個(gè)分片Shard就是一個(gè)Lucene數(shù)據(jù)庫(kù)Index。對(duì)于有副本replica的Shard，ElasticSearch操作完primary后，再去同步到replica。

2.4 挑戰(zhàn)磁盤(pán)I/O

現(xiàn)在我們已經(jīng)可以高效地維護(hù)全文檢索的數(shù)據(jù)結(jié)構(gòu)，也遵循經(jīng)典做法解決了分布式數(shù)據(jù)存儲(chǔ)。可就像前面提到的，還有個(gè)挑戰(zhàn)就是磁盤(pán)讀寫(xiě)的巨大開(kāi)銷(xiāo)。Lucene的做法是，每個(gè)Segment在文件系統(tǒng)Cache中構(gòu)建起來(lái)就可以被訪問(wèn)，同步到磁盤(pán)的fsync之后才會(huì)執(zhí)行。Lucene的Index內(nèi)部的Commit Point會(huì)記住哪些Segment還未同步。ElasticSearch默認(rèn)每隔1秒會(huì)用Buffer中的document新建一個(gè)Segment，這個(gè)操作叫做refresh。正因?yàn)檫@1秒鐘的間隔，ElasticSearch支持的是近實(shí)時(shí)而非實(shí)時(shí)。

一個(gè)很自然的問(wèn)題就是每秒鐘都會(huì)新建一個(gè)Segment，那Lucene Index中的Segment個(gè)數(shù)豈不是很容易就爆炸了。每個(gè)Segment都是一個(gè)物理文件，操作系統(tǒng)中打開(kāi)文件的句柄個(gè)數(shù)是有限的，而且即便不考慮上限，過(guò)多Segment也會(huì)拖慢搜索，因?yàn)榍懊嬷v過(guò)一次搜索的最終結(jié)果是要合并所有Segment中的統(tǒng)計(jì)信息的。
ElasticSearch的做法是維護(hù)一個(gè)后臺(tái)線程去做Merge，Merge的過(guò)程中不僅將多個(gè)小Segment合并成大的，同時(shí)還會(huì)排除掉刪除或修改的文件的老版本，最終修改Commit Point排除掉老的Segment，這樣那些“垃圾”document就徹底被刪除了。得益于Segment的不可變性，后臺(tái)進(jìn)程Merge時(shí)并不會(huì)影響數(shù)據(jù)插入和搜索的性能。

2.5 保證數(shù)據(jù)不丟失

一個(gè)可以預(yù)料到的問(wèn)題就是，如果當(dāng)前結(jié)點(diǎn)上的ElasticSearch進(jìn)程意外中止，那Buffer中等待處理的document和未同步到磁盤(pán)的Segment中的數(shù)據(jù)都會(huì)丟失。為了避免這一點(diǎn)，ElasticSearch引入了傳統(tǒng)數(shù)據(jù)庫(kù)中所謂的Write-Ahead Log（WAL）日志，ElasticSearch為其起名為translog。每次插入Buffer時(shí)，都會(huì)同時(shí)寫(xiě)入translog。下面的圖示清晰地展示ElasticSearch是如何與Lucene配合的。

當(dāng)創(chuàng)建新Segment時(shí)，Buffer清空，但translog會(huì)一直保留到Segment同步到磁盤(pán)才會(huì)清空。**所以當(dāng)ElasticSearch重啟時(shí)，先根據(jù)Commit Point將所有之前已經(jīng)commit到磁盤(pán)的Segment恢復(fù)到Cache，然后再重放（replay）translog中的所有操作。默認(rèn)每30分鐘或者translog很大時(shí)，ElasticSearch做一次full commit，即flush操作。
繼續(xù)刨根問(wèn)底，translog保證了Buffer和Segment的安全，誰(shuí)來(lái)保證它的安全呢？默認(rèn)情況下，translog每5秒鐘會(huì)同步到磁盤(pán)，也就是說(shuō)我們至多會(huì)丟失5秒到數(shù)據(jù)。因?yàn)閠ranslog只是原始的請(qǐng)求document，所以這里的寫(xiě)磁盤(pán)開(kāi)銷(xiāo)是遠(yuǎn)小于Segment的一次commit的。

3.題外話：如何深入學(xué)習(xí)ElasticSearch

以本文為例，談一談如何學(xué)習(xí)ElasticSearch。在有了一些分布式系統(tǒng)和開(kāi)發(fā)經(jīng)驗(yàn)后，像本文2.3和2.5節(jié)是完全可以跳過(guò)的。前者是分布式系統(tǒng)的通用做法，而后者則早已存在于傳統(tǒng)數(shù)據(jù)庫(kù)中。要掌握ElasticSearch，基本用法和系統(tǒng)命令是一方面，而設(shè)計(jì)中的精華往往在前文2.1和2.2中。光理解了設(shè)計(jì)還不行，就像前面說(shuō)過(guò)的，思想可能流傳已久，但做出來(lái)東西的質(zhì)量則可能千差萬(wàn)別?！疤煜麓笫拢刈鲇诩?xì)”，實(shí)現(xiàn)中的精髓只能在源代碼中體會(huì)。

其實(shí)這種方法在另一篇文章里也提到過(guò)，就是學(xué)一門(mén)編程語(yǔ)言時(shí)也是要抓住它的精髓，而不是每門(mén)語(yǔ)言都花很多時(shí)間去學(xué)基本語(yǔ)法，而沒(méi)有精力去掌握精華，最終迷失了。在此再次強(qiáng)調(diào)一下，自己也引以為戒。