Elasticsearch是否支持多版本JSON文档存储检索及性能影响如何

方案可行性结论 #

引入JSON文档版本机制完全可行，有两种成熟实现路径可以根据业务需求选择：

• 仅需做更新冲突控制、不需要回溯历史版本内容：直接使用ES内置的_version元字段即可，每次文档创建/更新/删除操作时ES会自动递增版本号，配合乐观锁version_type=external参数可以直接实现业务层面的版本校验，无需修改业务JSON结构。
• 需要保留每笔交易所有历史版本的完整JSON快照：可在业务字段中新增自定义版本标识（如biz_version、update_timestamp），补全新字段时只需生成新版本号写入新文档即可，旧版本文档无需修改。

多版本文档的存储与检索支持 #

ES天然支持同索引下不同结构JSON文档的存储和检索，不需要额外做适配：

• 存储层面：ES默认采用动态映射机制，新版本文档新增的字段会自动更新索引映射，旧版本文档缺少新增字段也不会产生写入报错，也不会强制给旧文档补默认值。如果需要避免非预期的字段自动创建，可以提前在索引模板中定义好字段规则，关闭动态映射即可。
• 检索层面：
  • 按交易ID+版本号查询单版本：直接增加term过滤条件即可，查询效率和普通单条件查询一致；
  • 查询同交易所有历史版本：按交易主键过滤后按版本号排序即可返回全量变更链路；
  • 跨版本统一查询：如需筛选包含新增字段的文档，增加exists过滤条件即可自动排除无对应字段的旧版本文档，不需要额外做兼容处理。

性能影响说明 #

性能损耗和你选择的实现方案强相关，整体可控：

• 仅使用内置_version做版本控制：几乎无额外性能损耗，_version属于ES原生维护的元数据，单次写入时的版本号递增开销可以忽略，对读写性能的影响低于1%，基本感知不到。
• 保留全量多版本文档：
  • 存储成本：和版本保留数量线性正相关，每多存一个版本就多一份全量文档的存储开销，建议对超过保留周期的历史版本做冷节点归档或者离线存储，降低成本。
  • 写入性能：每个新版本写入的开销和普通单条文档写入完全一致，无额外 overhead，并发更新量较大时可以采用批量写入接口降低IO消耗。
  • 查询性能：如果索引内总文档数随版本数量翻倍，同等查询条件下的查询耗时会有30%~70%的线性增长，建议将交易ID设置为路由键，把同笔交易的所有版本都路由到同一个分片存储，查询时指定路由参数即可将查询耗时降到和单版本查询接近的水平。

内容的提问来源于stack exchange，提问作者Carlos Agudelo - AuroraTech