elasticsearch的一些架構設計,對我們做效能調優、故障處理,具有非常重要的影響。下面將從elasticsearch的準實時索引的實現、自動發現、rounting和replica的讀寫過程,shard的allocate控制
在傳統的資料庫中,乙個欄位存乙個值,但是這對於全文搜尋是不足的。想要讓文字中的而每個單詞都可以被搜尋,這意味著資料庫需要多個值。
支援乙個字段多個值的最佳資料結構是倒排索引。倒排索引包含了出現在所有文件中唯一的值或或詞的有序列表,以及每個詞所屬的文件列表。
倒排索引儲存了比包含乙個term的文件列表多地多的資訊,它可能包含每乙個term的文件數量,乙個term出現在制定文件中的頻次,每個文件中term的順序,每個文件的長度,所有文件的平均長度等等。這些統計資訊讓elasticsearch知道哪些term更重要,哪些文件更重要,也就是相關性。
在全文搜尋的早些時候,會為整個文件集合建立乙個大索引,並且寫入磁碟。只有新索引準備好了它就會替代舊肚餓索引,最近的修改可以被檢索。
不可變性
寫入磁碟的倒排索引是不可變的,它有如下好處:
當然,不可變的索引有它的缺點,首先是它不可變。如果想要搜尋乙個新文件,必須重建整個索引。這不僅限制了乙個索引所能裝下的資料,還有乙個索引可以被更新的頻次。
要做到實時更新條件下資料的可用和可靠,就需要在倒排索引的基礎上,再做一系列更高階的處理。總結一下lucene的處理辦法:新收到的資料寫入新的索引檔案裡。lucene把每次生成的倒排索引,叫做乙個段(segment)。然後另外使用乙個commit檔案,記錄索引內的所有segment。而生成segment的資料**,則是記憶體中的buffer,也就是說,動態更新過後過程如下:
1)當前磁碟上有三個segement可用,同時有乙個commit檔案記錄當前的segment
2)新收到的資料進入記憶體buffer,索引狀態如下所示。
3)buffer刷到磁碟,生成乙個新的segment,commit檔案同步更新。這樣可以完成更新,也產生了幾個問題:
1、每次一有資料就重新整理到磁碟,會增大對磁碟的操作
2、重新整理到磁碟的時間佔據很大一部分時間
3、如果重新整理的過程中重新整理失敗應該怎麼控制呢?
segment是不可變的,所以文件即不能從舊的段中刪除,舊的段也不能更新以反映文件最新的文字。相反,每乙個提交點包括乙個.del檔案,包含了段上已經被刪除的文件當乙個文件被刪除,它是實際上只是在.del檔案中被標記刪除,亦然可以匹配查詢,但最終返回之前會被從結果中刪除。
文件的更新操作是類似的:當乙個文件被更新,舊版本的文件被標記為刪除,新版本的文件在新的段中索引。也許該文件的不同版本都會匹配乙個查詢,但是老版本會從結果中刪除。
既然涉及到磁碟,那麼乙個不可避免的問題就來了:磁碟太慢了!對我們要求的實時性很高的服務來說,這種處理還不夠。所以,在剛剛第3步的處理中,還有乙個中間狀態:
1)記憶體buffer生成乙個新的segment,刷到檔案系統快取中,lucene即可檢索到這個新的segment,索引狀態如圖所示。
2)檔案系統快取真正同步到磁碟上,commit檔案更新。
刷到檔案系統快取中這個步驟,elasticsearch預設1s的時間間隔,這也就是說相當於是實時搜尋的,elasticsearch也提供了單獨的/_reflush介面,使用者如果對1s間隔還是不太滿意,可以主動呼叫介面來保證搜尋可見。
post /_refresh <1>post /blogs/_refresh <2>
一般來說我們會通過/_settings介面或者定製template的方式,加大refresh_interval引數:
put /my_logs/_settings <1>put /my_logs/_settings <2>
既然refresh只是寫到檔案系統快取中,那麼最後一步寫到實際磁碟又是由什麼來控制的呢?如果這期間發生主機錯誤、硬碟故障等異常情況,資料會不會丟失?這裡,其實elasticsearch提供了另乙個機制來控制。elasticsearch也把資料寫入到記憶體buffer的同時,其實還另外記錄了乙個treanslog的日誌。也就是說,在記憶體資料進入到buffer這一步驟時,其實還另外記錄了乙個translog記錄。 Elasticsearch 架構原理
elasticsearch的一些架構設計,對我們做效能調優 故障處理,具有非常重要的影響。下面將從elasticsearch的準實時索引的實現 自動發現 rounting和replica的讀寫過程,shard的allocate控制 在傳統的資料庫中,乙個欄位存乙個值,但是這對於全文搜尋是不足的。想要...
Elasticsearch 執行架構詳解
檔案系統 hdfs,資料庫 hbase,訊息佇列 kafka,協調服務 zookeeper,接下來要讓大資料儲存的生態圈變得更完整,不得不提的就是搜尋引擎了,雖然說 elasticsearch 是以搜尋聞名的,但是說到底它還是個資料庫,它底層的儲存特性使它擁有了毫秒級的全文檢索響應能力,很好地補充了...
ElasticSearch分布式架構
it技術精華網 今天介紹下elasticsearch的分布式架構,如果你熟悉cassandra hadoop mongodb,你會發現elasticsearch裡面有很多他們的影子,沒錯,elasticsearch吸收了目前主流的分布式系統的很多特性,下面簡單介紹一把。之前翻譯過一篇 譯 搜尋引擎與...