目前更新文档的方式主要有两种

1.update api
2._update_by_query api

这里主要针对这两种做总结和说明 

update api

这个例子演示了如何去更新我们先前的文档（ID 为 1），通过修改 name 字段的值为 “Jane Doe” :

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty&pretty' -d'
{
  "doc": { "name": "Jane Doe" }
}'

对应的Kibana DSL

POST customer/external/1/_update
{
  "doc": {
    "name":"Jane Doe"
  }
}

 这个例子演示了如何去更新我们先前的文档（ID 为 1），通过修改 name 字段的值为 “Jane Doe”，并且同时添加 age 字段 :

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty&pretty' -d'
{
  "doc": { "name": "Jane Doe", "age": 20 }
}'

对应的Kibana DSL

POST index_account_sub_trans_detail_latest/account_sub_trans_detail/14/_update
{
  "doc": {
    "accSubId":888888,
    "age": 20
  }
}

 更新也是通过使用简单的简本来执行。这个例子演示了使用简本来将 age 加 5 :

curl -XPOST 'localhost:9200/customer/external/1/_update?pretty&pretty' -d'
{
  "script" : "ctx._source.age += 5"
}'

对应的Kibana DSL

POST index_account_sub_trans_detail_latest/account_sub_trans_detail/14/_update
{
  "script": "ctx._source.age+=5"
}

在上面的例子中，ctx._source 代表当前将被更新的源文档。

请注意，在编写该文档时，在同一时间中更新只能够被执行一个文档上。在将来，Elasticsearch 也许会提供给定一个查询条件（像 SQL UPDATE-WHERE 语句）来更新多个文档的功能。

 

_update_by_query 

_update_by_query 最简单的用法只是基于索引来执行每个文档的更新，而不更改源(意思就是，简单的用法下，只会更新文档的版本号，而不修改源数据)。这是非常有用快捷的，在完成一些  map 的变化也得以表现。

这里是 API：

POST twitter/_update_by_query?conflicts=proceed

返回值类似于这样：

{
  "took" : 147,
  "timed_out": false,
  "updated": 120,
  "deleted": 0,
  "batches": 1,
  "version_conflicts": 0,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1.0,
  "throttled_until_millis": 0,
  "total": 120,
  "failures" : [ ]
}

_update_by_query获取索引的快照，当它开始和进行索引时发现使用的是 internal的版本。这意味着如果在获取快照时或者进行索引请求时文档发生改变，那么将会发生版本冲突。当索引请求被处理的时间之间变化。当版本匹配文档被更新时候，版本号递增。

注意：

　　因为 internal版本不支持的值 0 作为一个有效的版本号，与版本等于 0 时候，文档无法使用 _update_by_query 更新，请求将会失败。所有的更新和查询失败导致 _update_by_query中止，并在返回错误的响应。正在执行的更新将会继续下去。换句话说，该方法不支持回滚，仅中止。虽然第一次失败将导致中止，由失败的请求返回所有故障将在 failures元素体现。因此，有可能存在一些失败的实体。如果你想简单地统计版本冲突不会导致 _update_by_query 中止你可以在 URL 中设置 conflicts=proceed或在请求中设置 "conflicts": "proceed" 。第一个例子做到这一点因为它只是试图获取一个当前的 mapping 变化，这里发生的版本冲突仅仅意味着冲突的文档在 _update_by_query 开始的时间和文件尝试更新时间之间被更新了。这样做具有一定的优点，因为更新将获取当前 mapping 更新。回到API格式，您可以限制 _update_by_query到一个单一类型。这将只从 twitter索引中更新 tweet 文件：

 限制 _update_by_query到一个单一类型,这将只从 twitter索引中更新 tweet 文件

POST twitter/tweet/_update_by_query?conflicts=proceed

限制 _update_by_query使用 。这将更新从 twitter 索引中更新所有的文档

POST twitter/_update_by_query?conflicts=proceed
{
  "query": { （1）
    "term": {
      "user": "kimchy"
    }
  }
}

（1）查询必须作为一个值传递 query键，就像在 Search API 中同样的方式。还可以使用的 q 参数。到目前为止，我们只是一直在更新文档，而无需更改其来源。

_update_by_query支持脚本对象更新文档。这将在所有 kimchy tweet 中增加 likes ：

POST twitter/_update_by_query
{
  "script": {
    "inline": "ctx._source.likes++",
    "lang": "painless"
  },
  "query": {
    "term": {
      "user": "kimchy"
    }
  }
}

 

参考文档：
https://www.kancloud.cn/apachecn/elasticsearch-doc-zh/1944946