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