大家好，我是烤鴨：

? ??今天分享的是官網6.x? ? 單一文檔(Single document APIs)APIs。

? ? 本文這是部分翻譯，如果想看全部的，還是建議閱讀官方api。鏈接：

? ? ?https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html

1.?? ?刪除? ?(delete) API

刪除API允許根據特定的索引從特定的索引中刪除類型化的JSON文檔。下面的示例從稱為twitter的索引，類型是_doc,id是1來刪除JSON文檔。 ????DELETE /twitter/_doc/1結果： {"_shards" : {"total" : 2,"failed" : 0,"successful" : 2},"_index" : "twitter","_type" : "_doc","_id" : "1","_version" : 2,"_primary_term": 1,"_seq_no": 5,"result": "deleted" }

版本控制

索引的每個文檔都是版本控制的。刪除文檔時，可以指定version?，以確保我們試圖刪除的相關文檔實際上已經被刪除了，并且同時沒有被更改。在文檔上執行的每一個寫入操作（包括刪除操作）都會導致其版本增加。刪除文檔的版本號在刪除后的短時間內仍然可用，以允許對并發操作的控制。刪除文檔的版本可用的時間由index.gc_deletes參數決定和默認為60秒。

路由

當使用索引控制路由時，刪除文檔還應提供路由值。例如：
DELETE /twitter/_doc/1?routing=kimchy以上將刪除帶有索引為tweet ，id為1的文檔，但將基于用戶路由。注意，沒有正確路由的刪除將不會刪除成功。
當_routing?映射設置為required?，并且沒有指定路由值時，刪除API將引發一個路由RoutingMissingException?并拒絕該請求。

自動索引創建

如果使用?external versioning variant，如果索引尚未創建，則刪除操作將自動創建一個索引（請檢查create indexAPI以手動創建索引），并且如果尚未創建特定類型之前（檢查put mappingAPI以手動創建類型映射)，則自動創建動態類型映射。

分布式

刪除操作被hash成特定的碎片id。然后，它被重定向到id組內的主碎片中，并在id組內復制（如果需要的話）到碎片副本。

等待active碎片

在執行刪除請求時，可以在開始處理刪除請求之前設置wait_for_active_shards?參數，以要求最小數量的碎片副本是active的。請參閱這里的詳細信息和使用示例。

超時

當主碎片被要求執行刪除操作，當操作被執行后，主碎片可能不可用。一些原因可能是，主要碎片目前正在從內存恢復或進行重新定位。默認情況下，刪除操作在主碎片在故障和響應錯誤之前，將等待1分鐘。timeout?參數可用于顯式指定它等待多長時間。下面是將其設置為5分鐘的示例： DELETE /twitter/_doc/1?timeout=5m

2.? ? 更新? ?(update) API

更新API允許根據提供的腳本更新文檔。從索引獲取（與碎片搭配的）文檔，運行腳本（帶有可選的腳本語言和參數），并返回結果（也允許刪除或忽略操作）。它使用版本控制來確保在“獲取”和“重新索引”期間沒有發生任何更新。
注意，此操作仍然意味著文檔的完全重新索引，它只刪除一些網絡往返行程，降低了獲取操作和索引操作之間的版本沖突的可能性。必須啟用_source字段來啟用此功能。

簡單例子：

PUT test/_doc/1 {"counter" : 1,"tags" : ["red"] }

腳本更新

運行腳本，自增計數。

POST test/_doc/1/_update {"script" : {"source": "ctx._source.counter += params.count","lang": "painless","params" : {"count" : 4}} } 我們可以在標簽列表中添加一個標簽（注意，如果標簽存在，它將仍然添加它，因為它是一個列表）：
POST test/_doc/1/_update {"script" : {"source": "ctx._source.tags.add(params.tag)","lang": "painless","params" : {"tag" : "blue"}} }

除了_source之外，以下變量可通過ctx? 圖獲得，如:_index、_type、_id、_version、_routing?和_now?（當前時間戳）。

也可以在文檔中添加新變量：

POST test/_doc/1/_update {"script" : "ctx._source.new_field = 'value_of_new_field'" }

或者刪除變量：

POST test/_doc/1/_update {"script" : "ctx._source.remove('new_field')" }

而且，我們甚至可以改變執行的操作。如果tags字段包含green，刪除文檔，否則它不做任何操作（noop）：

POST test/_doc/1/_update {"script" : {"source": "if (ctx._source.tags.contains(params.tag)) { ctx.op = 'delete' } else { ctx.op = 'none' }","lang": "painless","params" : {"tag" : "green"}} }

更新部分文檔

更新API還支持傳遞部分文檔，該文檔將被合并到現有文檔中（簡單遞歸合并、對象內部合并、替換核心“鍵值對”和數組）。要完全替換現有文檔，應該使用index API。下面的部分更新是對現有文檔添加了新字段：

POST test/_doc/1/_update {"doc" : {"name" : "new_name"} }

如果指定了doc?和script?，則忽略doc?。最好是將你的字段對的部分文檔放在腳本本身中。

NOOP更新檢查

如果doc?被指定，它的值將與現有的_source合并。默認情況下，更新檢測會檢測到它們不會改變任何東西，并返回“"result"：?"noop"?，像這樣：

POST test/_doc/1/_update {"doc" : {"name" : "new_name"} }

如果在發送請求之前name?如果是new_name?，則忽略整個更新請求。如果請求被忽略，響應中的result?返回noop?。

{"_shards": {"total": 0,"successful": 0,"failed": 0},"_index": "test","_type": "_doc","_id": "1","_version": 6,"result": "noop" }

可以禁用上面的更新檢查：

POST test/_doc/1/_update {"doc" : {"name" : "new_name"},"detect_noop": false }

更新插入

如果文檔不存在，則upsert?元素的內容將作為新文檔插入。如果文檔確實存在，那么script?將被執行：
POST test/_doc/1/_update {"script" : {"source": "ctx._source.counter += params.count","lang": "painless","params" : {"count" : 4}},"upsert" : {"counter" : 1} }

更新插入腳本

如果不管文檔是否存在，腳本都運行的話，即腳本代替upsert?初始化文檔，將scripted_upsert設置為true：

POST sessions/session/dh3sgudg8gsrgl/_update {"scripted_upsert":true,"script" : {"id": "my_web_session_summariser","params" : {"pageViewEvent" : {"url":"foo.com/bar","response":404,"time":"2014-01-01 12:32"}}},"upsert" : {} }

文檔插入更新

發送部分doc?加上upsert?doc?，將doc_as_upsert?設置為true?將使用doc?的內容作為upsert?值：
POST test/_doc/1/_update {"doc" : {"name" : "new_name"},"doc_as_upsert" : true }

參數

更新操作支持下列query-string 參數：

retry_on_conflict?

在更新的獲取和索引階段之間，可能另一個進程可能已經更新了同一文檔。默認情況下，更新操作將因版本沖突異常而失敗。retry_on_conflict?參數控制在最終拋出異常之前重試更新的次數。

routing

路由用于將指引更新請求路由到正確的碎片，如果更新的文檔不存在，則為更新插入請求設置路由。不能用于更新已存在文檔的路由。

timeout

碎片的超時等待變成可用。

wait_for_active_shards

在進行更新操作之前需要active的碎片副本的數量。詳情請見這里。

refresh

控制此請求所做的更改為可見的并且能夠搜索到。詳情見這里。

_source

控制被更新的source是否可以以及如何在響應中返回。默認情況下，更新的source不返回。有關詳細信息，請參見source filtering?。

version

Update API在內部使用依靠es的版本控制支持，以確保文檔在更新過程中不會改變。可以使用version?參數指定文檔僅在其版本與指定的版本匹配時才被更新。

更新API不支持除內部版本之外的版本控制。

更新API不支持外部（版本類型external?和external_gte）或強制（版本類型force）版本，因為這會導致es版本號與外部系統不同步。外部請使用使用index API 。

更多關于elasticsearch 6.x內容：

? ?1.? ?elasticsearch 6.x 部署 windows入門(一) spingboot連接

? ??2.???elasticsearch 6.x linux部署(二) kibana x-pack 安裝

? ? 3.? ?elasticsearch 6.x (三) linux 集群多節點部署

? ??4.? ?elasticsearch 6.x (四) 單一文檔 API 介紹和使用 index和get API

總結

以上是生活随笔為你收集整理的elasticsearch 6.x (五) 单一文档 API 介绍和使用 update和delete API的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。