OpenSearch两种更新方式（PUT/POST）的执行性能对比咨询

一、两种更新方式的底层逻辑 #

• PUT index/_doc/1（全量替换）：
  本质是先标记旧文档为删除（若存在），再写入新文档。默认不做版本冲突检查（除非显式指定if_seq_no/if_primary_term参数），并发场景下后执行的请求会直接覆盖前一次结果，因此不会触发版本冲突异常。执行流程简单：接收新文档 → 处理旧文档 → 写入新文档 → 按需刷新。

• POST index/_update/1（部分更新）：
  核心是读-改-写的原子操作：先读取旧文档内容，将传入的更新字段/脚本与旧文档合并，再写入新文档。OpenSearch会自动校验文档版本，并发更新时版本不匹配就会抛出version_conflict_engine_exception，这是默认的乐观锁机制。执行流程多了读取旧文档、版本校验、字段合并这几步。

二、性能差异对比 #

1. PUT 的性能优势：
   省去了「读取旧文档」和「版本检查」两个关键步骤，IO操作更少，延迟更低，吞吐量更高。适合文档结构变动大、或业务允许覆盖更新的场景（比如全量数据同步）。

2. POST 的额外开销：

   • 必须先读取旧文档，若文档不在内存缓存中，会增加一次磁盘IO开销；
   • 版本校验、字段/脚本合并逻辑会占用额外CPU资源，更新逻辑越复杂，开销越明显；
   • 并发场景下的版本冲突会导致请求重试（若业务需要重试），进一步拉高整体耗时。

三、场景选择建议 #

• 优先用PUT：当你能获取完整文档、且业务允许覆盖更新时，PUT性能更优，无额外读操作开销；
• 选择POST：当仅需更新部分字段（节省带宽）、或更新逻辑依赖旧文档内容（比如累加数值）时，虽有额外开销，但能满足业务逻辑需求。

内容的提问来源于stack exchange，提问作者MyWay