PUT /index/type/id 创建文档&替换文档,就是一样的语法
一般对应到应用程序中,每次的执行流程基本是这样的:
1、应用程序发起一个get请求,获取到document,展示到前台界面,供用户查看和修改
2、用户在前台界面修改数据,发送到后台
3、后台代码会将用户修改的数据在内存中进行执行,然后封装好修改后的全量数据
4、然后发送PUT请求到es中,进行全量替换
5、es将老的document标记为delete,然后重新创建一个新的document
什么是partial update?
POST /index/type/id/_update
{
"doc" : {
"要修改的少数几个field"
}
}
看起来好像比较方便,每次就传递几个发生修改的field即可,不需要将全量的document数据发送过去。
实现原理:
其实es内部对partial update的实际操作,更传统的全量替换方式,几乎是一样的
1、内部先获取document
2、将传过来的field更新到document的json中
3、将老的document标记为deleted
4、将修改后的新的document创建出来
partial update相较于全量替换的优点:
1、全量替换需要将数据从es中通过java应用程序传输到用户界面,然后用户在前台界面修改后,再通过java应用程序写入到es中去,而partial update的所有查询、修改和写回操作,都发生在es中的一个shard内部,避免了所有网络数据传输的开销(减少了两次网络请求),大大提升了性能
2、全量替换,查询结果放在界面,用户修改就有可能经历10分钟或者更长时间,然后修改完以后再写回去,可能es中的数据早已经被别人修改了,所以并发冲突的情况就会发生的较多。而partial update的查询、修改和写回都发生在es中一个shard内部,一瞬间就完成修改,可能耗时就是毫秒级别的,所以可以大大减少并发冲突的情况。
partial update 涉及到的两个知识点:
1、retry_on_conflict = n(如果第一次更新失败,接下来会重新获取新的version版本号,继续尝试更新。这个过程会持续N次)
POST /index/type/id/_update?retry_on_conflict=n
2、version(指定特定的版本号)
POST /index/type/id/_update?version=n