如何進行Elasticsearch數據寫入的分析

這期內容當中小編將會給大家帶來有關如何進行Elasticsearch數據寫入的分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

• 分布式的實時文件存儲，每個字段都被索引并可被搜索

• 分布式的實時分析搜索引擎

• 可以擴展到上百臺服務器，處理 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 中

具體可以看官方文檔：https://www.elastic.co/guide/...

3.3.4 merge 過程

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

• 就是各個小段文件，合并成一個大段文件。段合并過程

• 段合并結束，舊的小段文件會被刪除

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

四、小結

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

• write：文檔數據到內存緩存，并存到 translog

• refresh：內存緩存中的文檔數據，到文件緩存中的 segment 。此時可以被搜到

• flush 是緩存中的 segment 文檔數據寫入到磁盤

上述就是小編為大家分享的如何進行Elasticsearch數據寫入的分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。