'Elasticsearch基礎整理-來自程序員的浪漫'

ES來源

Elasticsearch 來源於作者 Shay Banon 的第一個開源項目Compass庫，而這個庫的最初目的只是為了給Shay當時正在學廚師的妻子做一個菜譜的搜索引擎。

馬上聯想到當年Pinterest的創意來源也是創始人Ben Silbermann為了方便他的女朋友尋找訂婚戒指，可以圖釘隨手粘貼同一個頁面進行對比。

ES基礎

數據模型

數據模型

邏輯概念

ES本身是schema less的，有比較特殊的字段需要通過Mapping設置一下，每個數據點就是一行數據Document，ES數據分類通過Index這層完成的

Elassticsearch的基礎概念-數據模型，如上圖把ES數據模型概念和傳統數據庫做了對比。

index 對應db 庫database庫

type 對應db 表table表(廢棄)

doc 對應db 行 row

field 對應db 字段 column

物理存儲

首先分為兩層，一個是ES，下面是Lucene，一個ES集群有多個node組成的。一個ES實例會承載一些Shard，多個shard會落到不同機器上面，P1和P2是兩個不同的Shard，並且shard有主從的概念，對於ES每個Shard落地下來是一個Lucene Index。

節點(Node)

運行了單個實例的ES主機稱為節點，它是集群的一個成員，可以存儲數據、參與集群索引及搜索操作。類似於集群，節點靠其名稱進行標識，默認為啟動時自動生成的隨機Marvel字符名稱。用戶可以按需要自定義任何希望使用的名稱，但出於管理的目的，此名稱應該儘可能有較好的識別性。節點通過為其配置的ES集群名稱確定其所要加入的集群。

分片(Shard)和副本(Replica)

ES的“分片(shard)”機制可將一個索引內部的數據分佈地存儲於多個節點，它通過將一個索引切分為多個底層物理的Lucene索引完成索引數據的分割存儲功能，這每一個物理的Lucene索引稱為一個分片(shard)。每個分片其內部都是一個全功能且獨立的索引，因此可由集群中的任何主機存儲。創建索引時，用戶可指定其分片的數量，默認數量為5個。

Shard有兩種類型：primary和replica，即主shard及副本shard。Primary shard用於文檔存儲，每個新的索引會自動創建5個Primary(最新版改成1個了) shard，當然此數量可在索引創建之前通過配置自行定義，不過，一旦創建完成，其Primary shard的數量將不可更改。Replica shard是Primary Shard的副本，用於冗餘數據及提高搜索性能。每個Primary shard默認配置了一個Replica shard，但也可以配置多個，且其數量可動態更改。ES會根據需要自動增加或減少這些Replica shard的數量。

ES集群可由多個節點組成，各Shard分佈式地存儲於這些節點上。

ES可自動在節點間按需要移動shard，例如增加節點或節點故障時。簡而言之，分片實現了集群的分佈式存儲，而副本實現了其分佈式處理及冗餘功能。

數據持久化

數據持久化.png

Lucence索引原理

新接到的數據寫入新的索引文件裡

動態更新索引時候，不修改已經生成的倒排索引，而是新生成一個段(segment)

每個段都是一個倒排索引，然後另外使用一個commit文件記錄索引內所有的segment,而生成segment的數據來源則放在內存的buffer中

持久化主要有四個步驟，write->refresh->flush->merge

寫入in-memory buffer和事務日誌translog

定期refresh到段文件segment中 可以被檢索到

定期flush segement落盤 清除translog

定期合併segment 優化流程

write

es每新增一條數據記錄時，都會把數據雙寫到translog和in-memory buffer內存緩衝區中

寫流程

這時候還不能會被檢索到，而數據必須被refresh到segment後才能被檢索到

refresh

默認情況下es每隔1s執行一次refresh,太耗性能，可以通過index.refresh_interval來修改這個刷新時間間隔。

整個refresh具體做了如下事情

所有在內存緩衝區的文檔被寫入到一個新的segment中，但是沒有調用fsync，因此數據有可能丟失,此時segment首先被寫到內核的文件系統中緩存

segment被打開是的裡面的文檔能夠被見檢索到

清空內存緩衝區in-memory buffer，清空後如下圖

refresh操作

flush

隨著translog文件越來越大時要考慮把內存中的數據刷新到磁盤中，這個過程叫flush

把所有在內存緩衝區中的文檔寫入到一個新的segment中

清空內存緩衝區

往磁盤裡寫入commit point信息

文件系統的page cache(segments) fsync到磁盤

刪除舊的translog文件，因此此時內存中的segments已經寫入到磁盤中,就不需要translog來保障數據安全了，flush後效果如下

flush操作

flush和fsync的區別

flush是把內存中的數據(包括translog和segments)都刷到磁盤,而fsync只是把translog刷新的磁盤(確保數據不丟失)。

segment合併

通過每隔一秒的自動刷新機制會創建一個新的segment，用不了多久就會有很多的segment。segment會消耗系統的文件句柄，內存，CPU時鐘。最重要的是，每一次請求都會依次檢查所有的segment。segment越多，檢索就會越慢。

ES通過在後臺merge這些segment的方式解決這個問題。小的segment merge到大的

這個過程也是那些被”刪除”的文檔真正被清除出文件系統的過程，因為被標記為刪除的文檔不會被拷貝到大的segment中。

段合併

當在建立索引過程中，refresh進程會創建新的segments然後打開他們以供索引。

merge進程會選擇一些小的segments然後merge到一個大的segment中。這個過程不會打斷檢索和創建索引。一旦merge完成，舊的segments將被刪除。

段合併後

新的segment被flush到磁盤

一個新的提交點被寫入，包括新的segment，排除舊的小的segments

新的segment打開以供索引

舊的segments被刪除

下面補充介紹下translog

Translog

Lucence基於節點宕機的考慮，每次寫入都會落盤Translog,類似db binlog,不同的是db binlog 通過expire_logs_days=7 設定過期時間以天為單位 默認7天

而translog 是每次flush後會清除 可以通過幾個維度的設定清除策略

index.translog.flush_threshold_ops,執行多少次操作後執行一次flush，默認無限制

index.translog.flush_threshold_size，translog的大小超過這個參數後flush，默認512mb

index.translog.flush_threshold_period,多長時間強制flush一次,默認30m

index.translog.interval,es多久去檢測一次translog是否滿足flush條件

translog日誌提供了一個所有還未被flush到磁盤的操作的持久化記錄。當ES啟動的時候，它會使用最新的commit point從磁盤恢復所有已有的segments，然後將重現所有在translog裡面的操作來添加更新，這些更新發生在最新的一次commit的記錄之後還未被fsync。

translog日誌也可以用來提供實時的CRUD。當你試圖通過文檔ID來讀取、更新、刪除一個文檔時，它會首先檢查translog日誌看看有沒有最新的更新，然後再從響應的segment中獲得文檔。這意味著它每次都會對最新版本的文檔做操作，並且是實時的。

理論上設定好這個過期策略，在flush之前把translog拿到後做雙機房同步或者進一步的消息通知處理，還可以有很大作為，可行性還有待嘗試。

寫操作

主分片+至少一個副分片全部寫成功後才返回成功

寫操作.png

具體流程：

客戶端向node1發起寫入文檔請求

Node1根據文檔ID(_id字段)計算出該文檔屬於分片shard0,然後將請求路由到Node3 的主分片P0上

路由公式 shard = hash(routing) % number_of_primary_shards

Node3在p0上執行了寫入請求後，如果成功則將請求並行的路由至Node1 Node2它的副本分片R0上，且都成功後Node1再報告至client

wait_for_active_shards 來配置副本分配同步策略

- 設置為1 表示僅寫完主分片就返回

- 設置為all 表示等所有副本分片都寫完才能返回

- 設置為1-number_of_replicas+1之間的數值，比如2個副本分片，有1個寫成功即可返回

timeout 控制集群異常副本同步分片不可用時候的等待時間

讀操作

一個文檔可以在任意主副分片上讀取

讀操作.png

讀取流程：

客戶端發起讀請求到Node1

Node1根據文檔ID(_id字段)計算出該文檔屬於分片shard0,在所有節點上都有，這次它根據負載均衡將請求路由至Node2

Node2將文檔返回給Node1，Node1將文檔返回給client

更新操作

更新操作其實就是先讀然後寫

更新操作.png

更新流程：

客戶端將更新請求發給Node1

Node1根據文檔ID(_id字段)計算出該文檔屬於分片shard0,而其主分片在Node上，於是將請求路由到Node3

Node3從p0讀取文檔，改變source字段的json內容，然後將修改後的數據在P0重新做索引。如果此時該文檔被其他進程修改，那麼將重新執行3步驟，這個過程如果超過retryon_confilct設置的重試次數，就放棄。

如果Node3成功更新了文檔，它將並行的將新版本的文檔同步到Node1 Node2的副本分片上重新建立索引，一旦所有的副本報告成功，Node3向被請求的Node1節點返回成功，然後Node1向client返回成功

更新和刪除

由於segments是不變的，所以文檔不能從舊的segments中刪除，也不能在舊的segments中更新來映射一個新的文檔版本。取之的是，每一個提交點都會包含一個.del文件，列舉了哪一個segment的哪一個文檔已經被刪除了。 當一個文檔被”刪除”了，它僅僅是在.del文件裡被標記了一下。被”刪除”的文檔依舊可以被索引到，但是它將會在最終結果返回時被移除掉。

文檔的更新同理：當文檔更新時，舊版本的文檔將會被標記為刪除，新版本的文檔在新的segment中建立索引。也許新舊版本的文檔都會本檢索到，但是舊版本的文檔會在最終結果返回時被移除。

作者：白天不懂夜的黑

鏈接：https://zhuanlan.zhihu.com/p/74047684

來源：知乎