1、就像在 Updating a whole document 中所说的一样，更新 document 的步骤就是检索 修改插入整个document。然而使用 update，就能局部更新，就像在一个请求里增加一个计数器一样。以前说过 document 是不可变的不能被修改，只能被替换，update 也必须遵守这个规则。在外部看来是局部更新的，在内部，update 依然执行了检索修改重新插入这个流程。不同的是这个过程是发生在 shard 中，因此避免了多次网络请求的开销，通过减少检索和重新插入的时间，降低了来自于其他线程的访问导致的数据冲突的可能性。最简单的 update 格式就是请求体中接受部分的
2、document 作为“doc“的参数。这个参数的值会和已经存在的document 合并，已经存在的 field 将会被重写，新的 field 将会被添加，例如，增加一个 tags 字段和一个 views 字段到 blog 中：POST /website/blog/1/_update“doc“:“tags“:“testing“,“views“:0如果成功将会相应如下数据：“_index“: “website“,“_id“: “1“,“_type“: “blog“,“_version“:3检索这个 document，注意一下_source 字段：“_index“: “website“,“_typ
3、e“: “blog“,“_id“: “1“,“_version“: 3,“found“: true,“_source“:“title“: “My first blog entry“,“text“: “Starting to get the hang of this.“,“tags“:“testing“,“views“: 0标注 1 和 2 表示就是局部更新的内容。使用 script 进行局部更新。我们会在 Scripting when you need more (TODO)更详细的介绍 script，但是现在来说我们已经足够了解 script 在 ES 中的几个合适的用武之地，已满足某些不被
4、 API 直接支持的但是用户需要的动作。默认的 script 语言是 MVEL，但是 ES 也是支持 JavaScript，Groovy 和 Python 的。MVEL 是简单的，快速的，基于 jiava 的动态脚本语言，语法类似于 JavaScript。你可以在 Elasticsearch scripting docs 和 MVEL website 了解更过关于 MVEL 的内容。script 能用作 update API，用来修改_source 的内容，这被称为一个更新的脚本 ctx._source。例如，可以使用script 增加这个 views 的数目：POST /website/bl
5、og/1/_update“script“:“ctx._source.views+=1“我们也能使用 script 给 tags 数组增加一个元素，在这个例子中我们指定新的 tag 作为参数而不是在 scritp 中硬编码。这个方式允许 ES 在以后可以重用这个参数，并且不需要每次从新编译这个 script：POST /website/blog/1/_update“script“:“ctx._source.tags+=new_tag“,“params“:“new_tag“:“search“最后两个的请求相应如下：“_index“: “website“,“_type“: “blog“,“_id“:
6、 “1“,“_version“: 5,“found“: true,“_source“:“title“: “My first blog entry“,“text“: “Starting to get the hang of this.“,“tags“: “testing“,“search“,“views“: 1标记 1 表示 search 这个元素已经追加到 tags 的数组中。标记 2 表示 views 的数量已经增加了。通过设置 ctx.op 为 delete，我们甚至能通过 script 删除一个 document。POST /website/blog/1/_update“script“:
7、“ctx.op = ctx._source.views = count ? 'delete' : 'none'“,“params“:“count“:1注：以上执行在 curl 下失败，在 head 中成功。更新一个或许不存在的 document如果我们需要在 ES 中存储一个页面访问量的计数器 conter，每次用户访问这个页面，我们都对这个页面增加一个数，但是增加这个 counter 之前要确定这个 counter 是已经存在的哦。如果要更新一个不存在的 document，update 将会出错。可以使用 upsert 参数来解决这个问题，如果指定的 docu
8、ment 不存在，就创建一个：POST /website/pageviews/1/_update“script“:“ctx._source.views+=1“,“upsert“:“views“:1首次执行这个请求，这个 upsert 数值做为一个新的 document 被插入，被初始化为 1。接下来的执行将会对 views直接增加 1。更新和冲突在本章节的说明部分，在检索和重新插入的间隔越小，冲突的机会就越小，但并不是完全没有冲突。依然有可能一个线程在另外一个线程执行 update 之前执行了 reindex 的动作。为了防止这个事情的发生，updateAPI 在执行检索的时候会检查记录 do
9、cument 的_version 的数量，并且在执行重新插入之间把_version 传递给其他线程的 index 的请求。如果另外的线程在检索重新插入之间修改了document，这个_version 就不会和 update 记录的_version 匹配导致 update 失败。对于很多情况下的局部 update 来说，update 并不关心一个 document 是否已经被修改，例如，两个线程同时增加页面的访问数量，以什么样的顺序发生 update 都是无所谓的即使冲突发生了，唯一要做的事情就是重新执行update 就行了。 如果你在请求时候设置了 retry_on_conflict 参数并设
10、定重复执行的次数（默认是 0），这个重新执行就会自动进行：POST /website/pageviews/1/_update?retry_on_conflict=5“script“:“ctx._source.views+=1“,“upsert“:“views“:0标记 1 表示在成功更新之前尝试五次 update。这个设置对不强调顺序的多个线程无序的增加也个页面访问数量的值是很有效的，但是有另外的情况，就是更新的次序很重要。像 index API，update API 就默认采用了”last-write-wins“这个办法，但是也能采用 version 参数，这个参数允许你使用 optimistic concurrency control 指定你要更新的 document 的 version。
