建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
Elasticsearch是與名為L(zhǎng)ogstash的數(shù)據(jù)收集和日志解析引擎以及名為Kibana的分析和可視化平臺(tái)一起開(kāi)發(fā)的。這三個(gè)產(chǎn)品被設(shè)計(jì)成一個(gè)集成解決方案，稱(chēng)為“Elastic Stack”（以前稱(chēng)為“ELK stack”）。
10年積累的成都做網(wǎng)站、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶(hù)對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶(hù)得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站策劃后付款的網(wǎng)站建設(shè)流程，更有云溪免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
Elasticsearch & Lucene 是什么
Elasticsearch 是一個(gè)基于 Apache Lucene(TM) 的開(kāi)源搜索引擎。
那 Lucene 是什么？
無(wú)論在開(kāi)源還是專(zhuān)有領(lǐng)域，Lucene 可以被認(rèn)為是迄今為止最先進(jìn)、性能最好的、功能最全的搜索引擎庫(kù)，并通過(guò)簡(jiǎn)單的 RESTful API 來(lái)隱藏 Lucene 的復(fù)雜性，從而讓全文搜索變得簡(jiǎn)單。
Elasticsearch 不僅僅是 Lucene 和全文搜索，我們還能這樣去描述它：
– 分布式的實(shí)時(shí)文件存儲(chǔ)，每個(gè)字段都被索引并可被搜索
– 分布式的實(shí)時(shí)分析搜索引擎
– 可以擴(kuò)展到上百臺(tái)服務(wù)器，處理 PB 級(jí)結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)
Elasticsearch & Lucene 的關(guān)系
就像很多業(yè)務(wù)系統(tǒng)是基于 Spring 實(shí)現(xiàn)一樣，Elasticsearch 和 Lucene 的關(guān)系很簡(jiǎn)單：Elasticsearch 是基于 Lucene 實(shí)現(xiàn)的。ES 基于底層這些包，然后進(jìn)行了擴(kuò)展，提供了更多的更豐富的查詢(xún)語(yǔ)句，并且通過(guò) RESTful API 可以更方便地與底層交互。類(lèi)似 ES 還有 Solr 也是基于 Lucene 實(shí)現(xiàn)的。
在應(yīng)用開(kāi)發(fā)中，用 Elasticsearch 會(huì)很簡(jiǎn)單。但是如果你直接用 Lucene，會(huì)有大量的集成工作。
因此，入門(mén) ES 的同學(xué)，稍微了解下 Lucene 即可。如果往高級(jí)走，還是需要學(xué)習(xí) Lucene 底層的原理。因?yàn)榈古潘饕⒋蚍謾C(jī)制、全文檢索原理、分詞原理等等，這些都是不會(huì)過(guò)時(shí)的技術(shù)。
新文檔寫(xiě)入流程
數(shù)據(jù)模型
一個(gè) ES Index （索引，比如商品搜索索引、訂單搜索索引）集群下，有多個(gè) Node （節(jié)點(diǎn)）組成。每個(gè)節(jié)點(diǎn)就是 ES 的實(shí)例。
每個(gè)節(jié)點(diǎn)上會(huì)有多個(gè) shard （分片）， P1 P2 是主分片 R1 R2 是副本分片
每個(gè)分片上對(duì)應(yīng)著就是一個(gè) Lucene Index（底層索引文件）
Lucene Index 是一個(gè)統(tǒng)稱(chēng)。由多個(gè) Segment （段文件，就是倒排索引）組成。每個(gè)段文件存儲(chǔ)著就是 Doc 文檔。
Lucene Index
lucene 中，單個(gè)倒排索引文件稱(chēng)為 segment。其中有一個(gè)文件，記錄了所有 segments 的信息，稱(chēng)為 commit point：
文檔 create 新寫(xiě)入時(shí)，會(huì)生成新的 segment。同樣會(huì)記錄到 commit point 里面
文檔查詢(xún)，會(huì)查詢(xún)所有的 segments
當(dāng)一個(gè)段存在文檔被刪除，會(huì)維護(hù)該信息在 .liv 文件里面
新文檔寫(xiě)入流程
新文檔創(chuàng)建或者更新時(shí)，進(jìn)行如下流程：
更新不會(huì)修改原來(lái)的 segment，更新和創(chuàng)建操作都會(huì)生成新的一個(gè) segment。數(shù)據(jù)哪里來(lái)呢？先會(huì)存在內(nèi)存的 bugger 中，然后持久化到 segment 。
數(shù)據(jù)持久化步驟如下：write -> refresh -> flush -> merge
write 過(guò)程
一個(gè)新文檔過(guò)來(lái)，會(huì)存儲(chǔ)在 in-memory buffer 內(nèi)存緩存區(qū)中，順便會(huì)記錄 Translog。
這時(shí)候數(shù)據(jù)還沒(méi)到 segment ，是搜不到這個(gè)新文檔的。數(shù)據(jù)只有被 refresh 后，才可以被搜索到。那么 講下 refresh 過(guò)程
refresh 過(guò)程
refresh 默認(rèn) 1 秒鐘，執(zhí)行一次上圖流程。ES 是支持修改這個(gè)值的，通過(guò) index.refresh_interval 設(shè)置 refresh （沖刷）間隔時(shí)間。refresh 流程大致如下：
in-memory buffer 中的文檔寫(xiě)入到新的 segment 中，但 segment 是存儲(chǔ)在文件系統(tǒng)的緩存中。此時(shí)文檔可以被搜索到
最后清空 in-memory buffer。注意: Translog 沒(méi)有被清空，為了將 segment 數(shù)據(jù)寫(xiě)到磁盤(pán)
文檔經(jīng)過(guò) refresh 后， segment 暫時(shí)寫(xiě)到文件系統(tǒng)緩存，這樣避免了性能 IO 操作，又可以使文檔搜索到。refresh 默認(rèn) 1 秒執(zhí)行一次，性能損耗太大。一般建議稍微延長(zhǎng)這個(gè) refresh 時(shí)間間隔，比如 5 s。因此，ES 其實(shí)就是準(zhǔn)實(shí)時(shí)，達(dá)不到真正的實(shí)時(shí)。
flush 過(guò)程
上個(gè)過(guò)程中 segment 在文件系統(tǒng)緩存中，會(huì)有意外故障文檔丟失。那么，為了保證文檔不會(huì)丟失，需要將文檔寫(xiě)入磁盤(pán)。那么文檔從文件緩存寫(xiě)入磁盤(pán)的過(guò)程就是 flush。寫(xiě)入次怕后，清空 translog。
translog 作用很大：
保證文件緩存中的文檔不丟失
系統(tǒng)重啟時(shí)，從 translog 中恢復(fù)
新的 segment 收錄到 commit point 中
具體可以看官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/7.3/indices-flush.html
merge 過(guò)程
上面幾個(gè)步驟，可見(jiàn) segment 會(huì)越來(lái)越多，那么搜索會(huì)越來(lái)越慢？怎么處理呢？
通過(guò) merge 過(guò)程解決：
就是各個(gè)小段文件，合并成一個(gè)大段文件。段合并過(guò)程
段合并結(jié)束，舊的小段文件會(huì)被刪除
.liv 文件維護(hù)的刪除文檔，會(huì)通過(guò)這個(gè)過(guò)程進(jìn)行清除
小結(jié)
如這個(gè)圖，ES 寫(xiě)入原理不難，記住關(guān)鍵點(diǎn)即可。
write -> refresh -> flush
– write：文檔數(shù)據(jù)到內(nèi)存緩存，并存到 translog
– refresh：內(nèi)存緩存中的文檔數(shù)據(jù)，到文件緩存中的 segment 。此時(shí)可以被搜到
– flush 是緩存中的 segment 文檔數(shù)據(jù)寫(xiě)入到磁盤(pán)
寫(xiě)入的原理告訴我們，考慮的點(diǎn)很多：性能、數(shù)據(jù)不丟失等等
當(dāng)前名稱(chēng)：ElasticsearchLucene數(shù)據(jù)寫(xiě)入流程
文章URL：http://www.5511xx.com/article/ccejpoh.html
