支持任意版本查询的HashMap结构文件最优存储方案

核心采用属性级版本链+分层快照的混合架构，同时满足任意版本查询的低延迟和高空间利用率，没有明显短板。

具体实现逻辑 #

• 拆分存储粒度
  放弃按版本存储独立HashMap的思路，为每个Property单独维护一条有序版本链，链上每个节点只存两个字段：(commit_version, value_ref)，其中value_ref是实际存储Value的地址指针，相同内容的Value全局只存一份，所有版本链节点共用引用。
  额外维护一份全局提交日志，按版本号递增顺序记录每个版本的元信息：提交时间、本次变更的Property列表、是否为全量更新标记。
  举个实际场景：v1版本是全量初始化，v2只更新了device.status这一个字段，那只需要在device.status的版本链尾部追加v2对应的节点，其余所有Property的版本链不需要做任何修改，完全没有冗余存储。
• 分层快照解决长链查询性能问题
  纯版本链查询老版本需要从头遍历链表，版本多了性能会衰减，因此加两层快照截断长链：
  • 每累计10个小版本（单/少字段更新的版本），生成一份增量快照：仅记录这10个版本内发生过变更的Property在该快照点的取值，未变更的Property不做存储
  • 每累计100个版本，生成一份全量基线快照：存储该版本下所有Property的完整取值，作为全局查询的快速起点
    查询任意版本的指定Property值时，先通过跳表索引找到小于等于目标版本的最近快照，直接拿到快照点该Property的值，再往后遍历最多9个版本链节点，就能定位到目标版本的取值，查询耗时稳定在微秒级，和直接读原生HashMap的性能差距不超过10%。
• 全量更新场景特殊处理
  如果某个版本是全字段更新（比如全量数据同步、批量刷数），直接将该版本标记为全量基线快照，不需要给每个Property单独追加版本链节点，既避免大量写操作，也缩短后续版本的查询路径。

方案对比参考 #

常见同类方案的优劣势对照：

• 纯全量快照方案：查询性能最好，直接读取对应版本的HashMap即可，但空间浪费极其严重，哪怕单字段更新也要存储整份Map，版本量上来后空间会膨胀几十到上百倍
• 纯操作日志方案：空间利用率最高，只存每次的变更记录，但查询任意版本需要从v1开始重放所有变更日志直到目标版本，版本数过千后查询延迟会升到秒级，完全无法支撑交互式查询
• 本方案：空间占用仅为纯全量快照的5%~20%（单版本平均更新字段越少，空间优势越明显），查询性能接近纯全量快照，是兼顾两者的最优选择。

落地优化提示 #

如果Value是大文本、二进制对象这类大体积内容，可以额外加一层内容哈希去重，相同哈希的Value全局仅存一份实体，空间利用率还能再提升30%以上。

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