Elasticsearch系列(五)ES數據寫入

本文轉載自:ES數據寫入

一、路由

它被存儲在單獨一個主分片上。Elasticsearch是如何知道文檔屬於哪個分片的呢?當你創建一個新文檔,它是如何知道是應該存儲在分片1還是分片2上的呢?

當你索引一個文檔,它被存儲在單獨一個主分片上。Elasticsearch是如何知道文檔屬於哪個分片的呢?當你創建一個新文檔,它是如何知道是應該存儲在分片1還是分片2上的呢?
進程不能是隨機的,因爲我們將來要檢索文檔。事實上,它根據一個簡單的算法決定:

shard = hash(routing) % number_of_primary_shards

routing值是一個任意字符串,它默認是_id但也可以自定義。這個routing字符串通過哈希函數生成一個數字,然後除以主切片的數量得到一個餘數(remainder),餘數的範圍永遠是0到number_of_primary_shards - 1,這個數字就是特定文檔所在的分片。

這也解釋了爲什麼主分片的數量只能在創建索引時定義且不能修改:如果主分片的數量在未來改變了,所有先前的路由值就失效了,文檔也就永遠找不到了。

所有的文檔API(get、index、delete、bulk、update、mget)都接收一個routing參數,它用來自定義文檔到分片的映射。自定義路由值可以確保所有相關文檔——例如屬於同一個人的文檔——被保存在同一分片上。


二、數據寫入

新建、索引和刪除請求都是寫(write)操作,它們必須在主分片上成功完成才能複製到相關的複製分片上。

在這裏插入圖片描述

下面我們羅列在主分片和複製分片上成功新建、索引或刪除一個文檔必要的順序步驟:

(1)客戶端給Node 1發送新建、索引或刪除請求。
(2)節點使用文檔的_id確定文檔屬於分片0。它轉發請求到Node 3,分片0位於這個節點上。
(3)Node 3在主分片上執行請求,如果成功,它轉發請求到相應的位於Node 1和Node 2的複製節點上。當所有的複製節點報告成功,Node 3報告成功到請求的節點,請求的節點再報告給客戶端。
(4)客戶端接收到成功響應的時候,文檔的修改已經被應用於主分片和所有的複製分片。你的修改生效了。

有很多可選的請求參數允許你更改這一過程。你可能想犧牲一些安全來提高性能。這一選項很少使用因爲Elasticsearch已經足夠快,不過爲了內容的完整我們將做一些闡述。

數據寫入相關參數選擇配置:

(1) replication

複製默認的值是sync。這將導致主分片得到複製分片的成功響應後才返回。
如果你設置replication爲async,請求在主分片上被執行後就會返回給客戶端。它依舊會轉發請求給複製節點,但你將不知道複製節點成功與否。

上面的這個選項不建議使用。默認的sync複製允許Elasticsearch強制反饋傳輸。async複製可能會因爲在不等待其它分片就緒的情況下發送過多的請求而使Elasticsearch過載。

(2) consistency

默認主分片在嘗試寫入時需要規定數量(quorum)或過半的分片(可以是主節點或複製節點)可用。這是防止數據被寫入到錯的網絡分區。規定的數量計算公式如下:

int( (primary + number_of_replicas) / 2 ) + 1

consistency允許的值爲one(只有一個主分片),all(所有主分片和複製分片)或者默認的quorum或過半分片。

注意number_of_replicas是在索引中的的設置,用來定義複製分片的數量,而不是現在活動的複製節點的數量。如果你定義了索引有3個複製節點,那規定數量是:

int( (primary + 3 replicas) / 2 ) + 1 = 3

但如果你只有2個節點,那你的活動分片不夠規定數量,也就不能索引或刪除任何文檔。

(3) timeout

當分片副本不足時會怎樣?Elasticsearch會等待更多的分片出現。默認等待一分鐘。如果需要,你可以設置timeout參數讓它終止的更早:100表示100毫秒,30s表示30秒。

注意:

新索引默認有1個複製分片,這意味着爲了滿足quorum的要求需要兩個活動的分片。當然,這個默認設置將阻止我們在單一節點集羣中進行操作。爲了避開這個問題,規定數量只有在number_of_replicas大於一時才生效。

本文轉載自:ES數據寫入

附:更多數據寫入請查看ES數據寫入

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章