ElasticStack學習（四）：ElasticSearch文檔的CRUD使用

一、文檔的CRUD介紹

ElasticSearch中存在五種操作，分別如下：

1、Index

該操作表示：如果文檔的ID不存在，則創建新的文檔。若有相同的ID，先刪除現有文檔，然後再創建新的文檔，同時版本會增加。

語法格式如下：

PUT index_name/_doc/100
{"field1":"value1","field2":"value2"}

其中，index_name【索引名稱】，_doc【Type名稱，約定都用_doc】，100【文檔ID】

2、Create

該操作表示：創建新的文檔，但是如果ID已經存在，會失敗。

該操作支持兩種操作方式：1）自動生成文檔ID；2）指定文檔ID；

語法格式如下：

根據文檔ID，創建文檔信息。（指定文檔ID的方式）
PUT index_name/_create/100
{"field1":"value1","field2":"value2"}
或者

PUT index_name/_doc/100?op_type=create
{"field1":"value1","field2":"value2"}

若不指定文檔ID，創建文檔時會自動生成。（自動生成文檔ID的方式）
POST index_name/_doc
{"field1":"value1","field2":"value2"}

3、Update

該操作表示：更新的文檔必須存在，更新時只會對相應欄位做增量修改。

語法格式如下：

POST index_name/_update/100
{
    "doc":{"field1":"value1","field2":"value2"}  
}

4、Delete

該操作表示：根據文檔ID，對相應文檔進行刪除。

語法格式如下：

DELETE index_name/_doc/100

5、Read

該操作表示：根據文檔ID，獲取相應文檔信息。

語法格式如下：

GET index_name/_doc/100

註意：Index操作相對於Create、Update操作的不同之處在於：如果文檔不存在，Index就會創建新的文檔。否則，如果文檔存在，現有文檔會被刪除，新的文檔會被創建，版本信息也會加1。而反觀Create操作，如果具有相同文檔ID的文檔信息存在了，則不能創建新的文檔，會報錯；Update操作，如果發現有相同文檔ID的信息，不會刪除原來的文檔，而是實現真正的數據更新，若沒有發現相同的文檔ID，則會報錯。

二、文檔CRUD操作實例

我們現在通過Kibana中的Dev Tools進行上述操作的演示：

1、Create操作

　　1）自動生成文檔ID的方式

通過以自動生成文檔ID的形式進行文檔創建，會發現創建的文檔ID是自動生成的，版本為1。

　　2）指定文檔ID的方式

如果文檔ID已經存在，則會報錯，如下所示：

2、Read操作

通過給定相應文檔ID，可以讀取相應的文檔信息，如下所示：

從讀取出來的結果信息中可以發現，藍色區域部分就是文檔的metadata，包括索引的名稱、類型、文檔ID、版本等信息；紅色區域部分就是文檔的所有原始信息。

 3、Index操作

通過執行Index操作，我們可以發現，version由1更改為2。同時通過讀取文檔ID為100的信息，會發現name變成了“張三”，而欄位des已經不存在了。說明Index操作是先刪除原有ID的文檔記錄，然後再創建一個相同ID的文檔信息。

4、Update操作

因為上面在執行Index操作時，文檔的Des欄位已經不存在了，現在將這個欄位增加到文檔ID為100的文檔上，此時就需要執行Update操作，如下所示：

讀取文檔信息後會發現，文檔信息中新增加了”des"、"age"兩個欄位，同時版本號又增加了一次。

5、Delete操作

三、文檔批量操作

1、Bulk API（批量操作）

Bulk API的作用：在訪問網路API時，每一次的訪問都需要重新建立網路開銷，因此是非常損耗性能的。 而Bulk API的核心思想就是在一次Rest請求中，對不同索引執行多次操作。它支持四種操作類型：Index、Create、Update、Delete。

通過上圖中實例操作，可以看出：

1）對於索引“users”執行index操作，返回成功；

2）對於索引"users"中，文檔ID為2的文檔信息進行刪除，返回狀態是404，結果是not_found，說明在索引“users”中並沒有文檔ID=2的文檔信息；

3）對於索引"users"中，文檔ID為2的文檔信息進行更新，新增欄位field2；

4）對於索引"shops"中，創建文檔ID為1的文檔信息；

在Bulk API操作中，若有單條操作失敗，並不會影響其他操作。同時，返回結果包括了每一條操作執行的結果。

2、mget（批量讀取）

mget與Bulk API的思路是一樣的，都是為了減少網路連接所產生的開銷，以提高性能。通過提供一系列的文檔ID，在一次API請求中，就可以將所有的文檔信息返回回來。

上圖中，我們通過mget操作訪問索引“users”中文檔ID為“1”、“101”的文檔信息，訪問索引“shops”中文檔ID為“1”的文檔信息。其中兩條均返回成功，而文檔ID=101的文檔信息沒有找到。

 3、msearch（批量查詢）

msearch通過一次Rest訪問，對不同的索引進行不同的查詢。

通過上圖中可以看出，此次批量查詢一共執行了三段查詢操作，第一次是針對索引users，查詢文檔ID大於等於1的文檔信息，一共查詢10條；第二次是查詢索引users中所有的文檔信息；第三條是查詢索引shops中所有的文檔信息。

四、常見錯誤返回說明及註意事項 

1、對於Bulk API、mget、msearch等批量操作的API，通過調用它們可以很好的提高性能，但是在調用時也不要過多的發送數據，否則也會容易導致ES集群過大的壓力，造成性能的下降。

那麼過多的數據一般控制在多少為好呢？一般建議是1000-5000個文檔，如果文檔很大，可以適當減少隊列，大小建議是5-15M，預設不能超過100M，否則會報錯。

2、雖我們在執行CU操作，或者批量執行CU操作時，動態的向索引更新或者創建了欄位。此時並沒有對索引預先做mapping定義，但是ES也會根據文檔類型進行類型推斷，將新增的欄位定義在mapping中。在生產環境中，建議做mapping設定後再寫入數據。

3、mget與msearch的區別：mget是通過文檔ID列表得到文檔信息，msearch是根據查詢條件，搜索到相關文檔。

4、自創建文檔ID時，需要考慮ID的均衡性，避免產生分配不均衡的問題。

　大家可關註我的公眾號

　　知識學習來源：《Elasticsearch核心技術與實戰》