opensearch 原生不支持 version_type=external 用于 _update api，但可通过 painless 脚本在更新时对比文档内时间戳字段，仅当新时间戳更新时才执行写入，从而实现业务层面的“外部版本语义”。
在 OpenSearch 中，_update 操作默认仅支持基于内部序列号（if_seq_no / if_primary_term）的乐观并发控制，不支持 version_type=external 参数——该限制源于底层 Lucene 的版本机制设计，且当前（包括 OpenSearch 2.x 及 ElasticSearch 8.x+）均无计划引入该功能。因此，若需依据业务字段（如 EPOCH 时间戳 updateTimestamp）实现“仅当新数据更新时才覆盖”的语义，必须采用脚本化更新方案。
✅ 推荐方案：Painless 脚本条件更新
使用 POST /{index}/_update/{id} 发送带条件逻辑的脚本请求，核心逻辑为：
- 获取现有文档中的 updateTimestamp（即 ctx._source.updateTimestamp）；
- 与传入参数 params.updateTimestamp 比较；
- 仅当新时间戳更大时，才逐字段更新文档内容；否则静默跳过（或主动抛出异常便于监控）。
示例请求体如下：
{
"script": {
"lang": "painless",
"source": """
if (params.updateTimestamp > ctx._source.updateTimestamp) {
for (entry in params.entrySet()) {
// 跳过 updateTimestamp 自身，避免重复赋值（可选）
if (!entry.getKey().equals('updateTimestamp')) {
ctx._source[entry.getKey()] = entry.getValue();
}
}
// 强制更新时间戳（推荐：确保最终一致性）
ctx._source.updateTimestamp = params.updateTimestamp;
} else {
// 可选：抛出异常，使 HTTP 返回 409 Conflict，便于客户端感知冲突
// throw new IllegalArgumentException('Stale update rejected: new timestamp is older');
}
""",
"params": {
"updateTimestamp": 1718234567890,
"title": "Updated Document Title",
"content": "New content body"
}
}
}✅ 关键说明：ctx._source 是当前文档源数据的可变映射，修改后将持久化；params 中除 updateTimestamp 外的字段均为待更新业务字段；显式更新 updateTimestamp 字段可保证其始终反映最新写入时间；若启用 throw 分支，OpenSearch 将返回 409 Conflict，客户端可据此统计/告警陈旧更新请求。
⚠️ 注意事项与最佳实践
- 脚本性能：Painless 脚本在主分片上执行，逻辑应保持轻量。避免循环大量字段、正则匹配或复杂计算。
- 字段存在性检查：生产环境建议添加 ctx._source.containsKey('updateTimestamp') 判断，防止首次写入（无该字段）时脚本报错。
-
存储脚本优化：高频使用的脚本建议注册为 stored script，通过 id 引用，提升可维护性与执行效率：
PUT /_scripts/timestamp_guarded_update { "script": { "lang": "painless", "source": "...（同上脚本逻辑）..." } }调用时使用 "script": {"id": "timestamp_guarded_update", "params": {...}}"。
- 幂等性保障：该方案天然支持幂等更新——相同时间戳或更旧时间戳的重复请求均不会改变文档状态。
-
替代方案对比：
❌ if_seq_no + if_primary_term：仅校验写入顺序，无法关联业务时间；
❌ 先 GET 再 INDEX：引入竞态风险（读写间可能被其他更新覆盖），且增加 RTT 开销；
✅ 脚本更新：原子、高效、业务语义清晰。
综上，虽然 OpenSearch 不提供开箱即用的外部版本支持，但借助 Painless 脚本可精准、安全、高效地实现基于任意字段（尤其是时间戳）的条件更新逻辑，是当前最成熟、最推荐的工程实践。
