一、文件的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核心技術與實