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

1、文檔的CRUD介紹

ElasticSearch中存在五種操做，分別以下：

一、Index

該操做表示：若是文檔的ID不存在，則建立新的文檔。如有相同的ID，先刪除現有文檔，而後再建立新的文檔，同時版本會增長。

語法格式以下：

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

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

二、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"}

三、Update

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

語法格式以下：

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

四、Delete

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

語法格式以下：

DELETE index_name/_doc/100

五、Read

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

語法格式以下：

GET index_name/_doc/100

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

 

2、文檔CRUD操做實例

咱們如今經過Kibana中的Dev Tools進行上述操做的演示：

一、Create操做

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

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

　　2）指定文檔ID的方式

若是文檔ID已經存在，則會報錯，以下所示：

二、Read操做

經過給定相應文檔ID，能夠讀取相應的文檔信息，以下所示：

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

 三、Index操做

經過執行Index操做，咱們能夠發現，version由1更改成2。同時經過讀取文檔ID爲100的信息，會發現name變成了「張三」，而字段des已經不存在了。說明Index操做是先刪除原有ID的文檔記錄，而後再建立一個相同ID的文檔信息。

四、Update操做

由於上面在執行Index操做時，文檔的Des字段已經不存在了，如今將這個字段增長到文檔ID爲100的文檔上，此時就須要執行Update操做，以下所示：

讀取文檔信息後會發現，文檔信息中新增長了」des"、"age"兩個字段，同時版本號又增長了一次。

五、Delete操做

 

3、文檔批量操做

一、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操做中，如有單條操做失敗，並不會影響其餘操做。同時，返回結果包括了每一條操做執行的結果。

二、mget（批量讀取）

mget與Bulk API的思路是同樣的，都是爲了減小網絡鏈接所產生的開銷，以提升性能。經過提供一系列的文檔ID，在一次API請求中，就能夠將全部的文檔信息返回回來。

上圖中，咱們經過mget操做訪問索引「users」中文檔ID爲「1」、「101」的文檔信息，訪問索引「shops」中文檔ID爲「1」的文檔信息。其中兩條均返回成功，而文檔ID=101的文檔信息沒有找到。

 三、msearch（批量查詢）

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

經過上圖中能夠看出，這次批量查詢一共執行了三段查詢操做，第一次是針對索引users，查詢文檔ID大於等於1的文檔信息，一共查詢10條；第二次是查詢索引users中全部的文檔信息；第三條是查詢索引shops中全部的文檔信息。

 

4、常見錯誤返回說明及注意事項 

一、對於Bulk API、mget、msearch等批量操做的API，經過調用它們能夠很好的提升性能，可是在調用時也不要過多的發送數據，不然也會容易致使ES集羣過大的壓力，形成性能的降低。

那麼過多的數據通常控制在多少爲好呢？通常建議是1000-5000個文檔，若是文檔很大，能夠適當減小隊列，大小建議是5-15M，默認不能超過100M，不然會報錯。

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

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

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

 

　你們可關注個人公衆號

　　

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