elasticsearch学习笔记（十四）——Elasticsearch partial update实现原理和实践

首先来讲一下为什么会有partial update。

在之前对于创建文档和更新替换文档的格式都是：

PUT /{index}/{type}/{id}
{}

一般对应到应用程序中，每次的执行流程基本都是这样的：

（1）应用程序先发起一个get请求，获取到document，展示到前台界面，供用户查看和修改

（2）用户在前台界面修改数据，发送到后台

（3）后台代码会将用户修改的数据在内存中进行执行，然后封装好修改后的全量数据

（4）然后在发送PUT请求到ES中，进行全量替换

（5）ES会将老的document标记为deleted，然后重新创建一个新的document

之前的流程有1个问题就是每次修改数据的时候，由于都是替换，所以每次带上的字段不仅包括要修改的字段，还需要带上其它的所有字段（即使那些字段根本就不需要修改）。

针对这一点，于是ES就有了partial update。格式就是：

POST /{index}/{type}/{id}/_update
{
    "doc": {
        "需要修改的字段"
    }
}

这样看起来好像是方便了很多，每次修改时只需要传入少数几个发生修改的字段即可，不需要将全量的document数据发送过去。

partial update实现原理以及优点

partial update实现原理:从本质上来说，它的实现原理和传统的全量替换的方式是几乎一样的。

过程如下：

（1）在内部会先获取document

（2）将传过来的field更新到document的json中去

（3）将旧的document标记为deleted

（4）将修改后的新的document创建出来

既然说本质都一样，那它相比传统的方式优点在哪里呢？

比较之后不难发现有以下的优点：

（1）所有的查询、修改和写回操作都发生在ES中的一个shard内部，与传统全量替换将操作放在内存的方式相比，避免了所有网络数据传输的开销（减少了2次网络请求），大大提升了性能

（2）减少了查询和修改中的时间间隔，可以有效减少并发冲突的情况

实践：

PUT /test_index/_doc/3
{
  "test_field1": "test1",
  "test_field2": "test2"
}
GET /test_index/_doc/3
{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "3",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "test_field1" : "test1",
    "test_field2" : "test2"
  }
}
POST /test_index/_update/3
{
  "doc": {
    "test_field2" : "update test2"
  }
}
GET /test_index/_doc/3
{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "3",
  "_version" : 2,
  "_seq_no" : 1,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "test_field1" : "test1",
    "test_field2" : "update test2"
  }
}