Elasticsearch 資料寫入原理分析

本文轉自 | 泥瓦匠BYSocket

• 分散式的實時檔案儲存，每個欄位都被索引並可被搜尋

• 分散式的實時分析搜尋引擎

• 可以擴充套件到上百臺伺服器，處理 PB 級結構化或非結構化資料

二、Elasticsearch & Lucene 的關係

因此，入門 ES 的同學，稍微瞭解下 Lucene 即可。如果往高階走，還是需要學習 Lucene 底層的原理。因為倒排索引、打分機制、全文檢索原理、分詞原理等等，這些都是不會過時的技術。

三、新文件寫入流程

3.1 資料模型

如圖

• 一個 ES Index （索引，比如商品搜尋索引、訂單搜尋索引）叢集下，有多個 Node （節點）組成。每個節點就是 ES 的例項。

• 每個節點上會有多個 shard （分片）， P1 P2 是主分片 R1 R2 是副本分片

• 每個分片上對應著就是一個 Lucene Index（底層索引檔案）

• Lucene Index 是一個統稱。由多個 Segment （段檔案，就是倒排索引）組成。每個段檔案儲存著就是 Doc 文件。

3.2 Lucene Index

lucene 中，單個倒排索引檔案稱為 segment。其中有一個檔案，記錄了所有 segments 的資訊，稱為 commit point：

• 文件 create 新寫入時，會生成新的 segment。同樣會記錄到 commit point 裡面

• 文件查詢，會查詢所有的 segments

• 當一個段存在文件被刪除，會維護該資訊在 .liv 檔案裡面

3.3 新文件寫入流程

資料持久化步驟如下：write -> refresh -> flush -> merge

3.3.1 write 過程

一個新文件過來，會儲存在 in-memory buffer 記憶體快取區中，順便會記錄 Translog。

• in-memory buffer 中的文件寫入到新的 segment 中，但 segment 是儲存在檔案系統的快取中。此時文件可以被搜尋到

• 最後清空 in-memory buffer。注意: Translog 沒有被清空，為了將 segment 資料寫到磁碟

文件經過 refresh 後， segment 暫時寫到檔案系統快取，這樣避免了效能 IO 操作，又可以使文件搜尋到。refresh 預設 1 秒執行一次，效能損耗太大。一般建議稍微延長這個 refresh 時間間隔，比如 5 s。因此，ES 其實就是準實時，達不到真正的實時。

3.3.3 flush 過程

上個過程中 segment 在檔案系統快取中，會有意外故障文件丟失。那麼，為了保證文件不會丟失，需要將文件寫入磁碟。那麼文件從檔案快取寫入磁碟的過程就是 flush。寫入磁碟後，清空 translog。

• 保證檔案快取中的文件不丟失

• 系統重啟時，從 translog 中恢復

• 新的 segment 收錄到 commit point 中

具體可以看官方文件：

3.3.4 merge 過程

上面幾個步驟，可見 segment 會越來越多，那麼搜尋會越來越慢？怎麼處理呢？

• 就是各個小段檔案，合併成一個大段檔案。段合併過程

• 段合併結束，舊的小段檔案會被刪除

• .liv 檔案維護的刪除文件，會透過這個過程進行清除

四、小結

如這個圖，ES 寫入原理不難，記住關鍵點即可。

• write：文件資料到記憶體快取，並存到 translog

• refresh：記憶體快取中的文件資料，到檔案快取中的 segment 。此時可以被搜到

• flush 是快取中的 segment 文件資料寫入到磁碟

• 《深入理解 Elasticsearch》

• ～