elasticsearch的一些架構設計，對我們做效能調優、故障處理，具有非常重要的影響。下面將從elasticsearch的準實時索引的實現、自動發現、rounting和replica的讀寫過程，shard的allocate控制
在傳統的資料庫中，乙個欄位存乙個值，但是這對於全文搜尋是不足的。想要讓文字中的而每個單詞都可以被搜尋，這意味著資料庫需要多個值。
支援乙個字段多個值的最佳資料結構是倒排索引。倒排索引包含了出現在所有文件中唯一的值或或詞的有序列表，以及每個詞所屬的文件列表。
倒排索引儲存了比包含乙個term的文件列表多地多的資訊，它可能包含每乙個term的文件數量，乙個term出現在制定文件中的頻次，每個文件中term的順序，每個文件的長度，所有文件的平均長度等等。這些統計資訊讓elasticsearch知道哪些term更重要，哪些文件更重要，也就是相關性。
在全文搜尋的早些時候，會為整個文件集合建立乙個大索引，並且寫入磁碟。只有新索引準備好了它就會替代舊肚餓索引，最近的修改可以被檢索。
不可變性
寫入磁碟的倒排索引是不可變的，它有如下好處：
當然，不可變的索引有它的缺點，首先是它不可變。如果想要搜尋乙個新文件，必須重建整個索引。這不僅限制了乙個索引所能裝下的資料，還有乙個索引可以被更新的頻次。
要做到實時跟新條件下資料的可用和可靠，就需要在倒排索引的基礎上，再做一系列更高階的處理。總結一下lucene的處理辦法：新收到的資料寫入新的索引檔案裡。lucene把每次生成的倒排索引，叫做乙個段(segment)。然後另外使用乙個commit檔案，記錄索引內的所有segment。而生成segment的資料**，則是記憶體中的buffer,也就是說，動態跟新過後過程如下：1）當前磁碟上有三個segement可用，同時有乙個commit檔案記錄當前的segment2）新收到的資料進入記憶體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>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吸收了目前主流的分布式系統的很多特性，下面簡單介紹一把。之前翻譯過一篇 譯 搜尋引擎與...