ElasticSearch 文檔的增删改查都不會，還學啥呢？
本文主要是介紹 ElasticSearch 的文檔增删改查和批量操作，同時會介紹一些 REST API 傳回狀态碼的具體含義。
我們先來看下這個表：
這個表包含了 Index、Create、Read、Update、Delete 這五種方法，我們先來看下 CRUD 操作的 HTTP 請求都長什麼樣子？
首先是提供一個 HTTP 的 method，後面是索引名字，在 7.0 之後是以的 Type 都用 _doc 表示，後面是文檔 id。
再簡單了解了 CURD 操作的 HTTP 請求後，那麼讓我們先來了解下如何建立文檔：
建立文檔
Create 支援兩種方式，一種是指定文檔 id 建立文檔，像上面這張圖就是；另一種是通過調用 post /users/_doc 去讓 ES 自動生成文檔 id。
自己指定文檔 id建立文檔，需要考慮 id 的均衡性，避免産生配置設定不均衡的問題。
ES 的 hash 函數會確定文檔 id 被均勻配置設定到不同的分片。
當我們執行剛才的指令，可以傳回如下結果：
其中 _version 每一次操作，都會 + 1，它是一個鎖的機制，當并行修改文檔的時候，更新的版本号比文檔目前的版本号小時就會報錯，不允許做修改。
建立文檔時，如果索引不存在，ES 會自動建立對應的 index 和 type。
接下來看下另一種建立文檔的方式，不指定 id 建立文檔，HTTP 請求也變為了 POST，具體的請求如下：
傳回的結果如下：
Index 和 Create 差別為：如果文檔不存在，就索引新的文檔，否則現有文檔就會被删除，新的文檔被索引，版本資訊 _version + 1。
查詢文檔
Get 方法比較簡單，隻需要 Get 索引名稱/_doc/文檔 id，通過執行這個指令就可以知道文檔的具體資訊了。
當執行這條語句後會傳回 HTTP 200，具體傳回結果如下：
其中 _index 為索引，_type 為類型，_id 為文檔 id，_version 為版本資訊，_source 存儲了文檔的完整原始資料。
當查詢的文檔 id 不存在的時候，會傳回 HTTP 404，且 found 為 false，具體結果如下：
更新文檔
Update 方法采用 HTTP POST，在請求體中必須指明 doc，在把具體文檔提供在 HTTP 的 body 裡。Update 和 Index 方法不同，Update 方法不會删除原來的文檔，而是實作真正的資料更新。
比如在原來的文檔 id 為 1 的文檔上增加字段，具體請求如下：
執行後，版本資訊 _version + 1，讓我們再去查詢下該文檔：
可以看到，新增字段已經成功了。
删除文檔
Delete 方法也很簡單，Delete 索引名稱/_doc/文檔 id 就可以了，再這裡就不再做代碼示範了。
在介紹完文檔的基本 CRUD 操作後，讓我們來看看批量操作吧：
Bulk API
在一個 REST 請求中，重建立立網絡開銷是十分損耗性能的，是以 ES 提供 Bulk API，支援在一次 API 調用中，對不同的索引進行操作，進而減少網絡傳輸開銷，提升寫入速率。
它支援 Index、Create、Update、Delete 四種類型操作，可以在 URI 中指定索引，也可以在請求的方法體中進行。
同時多條操作中如果其中有一條失敗，也不會影響其他的操作，并且傳回的結果包括每一條操作執行的結果。
比如輸入如下代碼：
當我們執行指令後，結果如下：
took 表示消耗了 93 毫秒，errors 為 true 表示在這些操作中錯誤發生，發現是 update 操作發生了錯誤，id 為 2 的文檔不存在，是以報錯了。
在使用 Bulk API 的時候，當 errors 為 true 時，需要把錯誤的操作修改掉，防止存到 ES 的資料有缺失。
批量查詢文檔
批量查詢需要指明要查詢文檔的 id，可以在一個 _mget 操作裡查詢不同索引的資料，可以減少網絡連接配接所産生的開銷，提高性能。
下面我們來實際操作下，輸入以下代碼執行，就可以得到文檔 id 為 1,3 的資料。
運作結果如下：
在介紹完文檔的一些操作，最後讓我們看下 REST API 常見錯誤傳回有哪些吧！
REST API 常見錯誤傳回
剛才在示範中，當查詢文檔 id 不存在的時候就會報 404 錯誤，而且 ES 還有各種各樣的傳回，下面通過一個表格了解下：
總結