ElasticSearch文檔操做介紹三

ElasticSearch文檔的操做

 

文檔存儲位置的計算公式:

shard = hash(routing) % number_of_primary_shards

上面公式中，routing 是一個可變值，默認是文檔的 _id ，也能夠設置成一個自定義的值。 routing 經過 hash 函數生成一個數字，而後這個數字再除以 number_of_primary_shards （主分片的數量）後獲得 餘數 。這個分佈在 0 到 number_of_primary_shards-1 之間的餘數，就是咱們所尋求的文檔所在分片的位置。

這就解釋了爲何咱們要在建立索引的時候就肯定好主分片的數量 而且永遠不會改變這個數量：由於若是數量變化了，那麼全部以前路由的值都會無效，文檔也再也找不到了。

全部的文檔 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一個叫作 routing 的路由參數 ，經過這個參數咱們能夠自定義文檔到分片的映射。一個自定義的路由參數能夠用來確保全部相關的文檔——例如全部屬於同一個用戶的文檔——都被存儲到同一個分片中。

ElasticSearch中，新建、刪除、索引文檔都屬於寫操做，必須在主分片上面完成以後才能被複制到相關的副本分片。

寫一個文檔:

下圖是官網的一個例子，假設集羣中有三個節點，一個索引，兩個主分片，每一個主分片有兩個副本。寫操做一個文檔的過程以下:

一、客戶端向 Node 1 發送新建、索引或者刪除請求。
二、節點使用文檔的 _id 肯定文檔屬於分片 0 。請求會被轉發到 Node 3`，由於分片 0 的主分片目前被分配在 `Node 3 上。
三、Node 3 在主分片上面執行請求。若是成功了，它將請求並行轉發到 Node 1 和 Node 2 的副本分片上。一旦全部的副本分片都報告成功, Node 3 將向協調節點(接受客戶端請求的節點)報告成功，協調節點向客戶端報告成功。

在客戶端收到成功響應時，文檔變動已經在主分片和全部副本分片執行完成，變動是安全的。

 

讀一個文檔:

檢索(讀取)一個文檔時，能夠從主分片或者其餘任意副本分區檢索。

如下是從主分片或者副本分片檢索文檔的步驟順序：

一、客戶端向 Node 1 發送獲取請求。

二、節點使用文檔的 _id 來肯定文檔屬於分片 0 。分片 0 的主、副分片存在於全部節點上。 在這種狀況下，它將請求轉發到 Node 2 。

三、Node 2 將文檔返回給 Node 1 ，而後將文檔返回給客戶端。

在處理讀取請求時，協調結點在每次請求的時候都會經過輪詢全部的副本分片來達到負載均衡。

在文檔被檢索時，已經被索引的文檔可能已經存在於主分片上可是尚未複製到副本分片。 在這種狀況下，副本分片可能會報告文檔不存在，可是主分片可能成功返回文檔。 一旦索引請求成功返回給用戶，文檔在主分片和副本分片都是可用的。

 

部分更新一個文檔: 

 

如下是部分更新一個文檔的步驟：

一、客戶端向 Node 1 發送更新請求。二、它將請求轉發到主分片所在的 Node 3 。三、Node 3 從主分片檢索文檔，修改 _source 字段中的 JSON ，而且嘗試從新索引主分片的文檔。 若是文檔已經被另外一個進程修改，它會重試步驟 3 ，超過 retry_on_conflict 次後放棄。四、若是 Node 3 成功地更新文檔，它將新版本的文檔並行轉發到 Node 1 和 Node 2 上的副本分片，從新創建索引。 一旦全部副本分片都返回成功， Node 3 向協調節點也返回成功，協調節點向客戶端返回成功。