updateAPI是以前说过的read和write操作的联合：
操作步骤：
1：客户端向node1发起请求。
2：node1想node3转发请求，node3是要查找的document的primary shard被分配的地方
3：node3从primary shard检索要查找的document，把_source中的对应的field的作出修改，然后重新插入到priymary shard，如果document被其他线程进行了修改，那么根据retry_on_conflict指定的次数，重复步骤3直到失败。
4：如果node3已经成功的更新了document，node3一起转发document的新版本到node1和node2中的副本进行重新插入。等到所有的replica shard都报告成功后，node3想node1发送成功的报告，node2想客户端发送成功的报告。
这个updateAPI也有routing，replication，consistency和timeout的参数，这个在Creating, indexing and deleting a document.提到过。
基于文件的复制
当primary shard通知replica shared作出变化时候，他并不转发update请求，而是转发了整个新版本的document。记住，变化是同步转发到replica shard的，也不保证到达是和发送的顺序是一致的。如果ES仅仅是转发了变化的部分，那么变化就可能做到在一个错误的次序上，造成文件的损坏。
原文：http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_partial_updates_to_a_document.html
部分更新document（pritial update document）,布布扣,bubuko.com
部分更新document（pritial update document）
原文地址：http://www.cnblogs.com/blog1350995917/p/3735242.html
