JanusGraph中多版本记录及关联的最优存储方案探讨

1. 合并同ID顶点，用属性存储版本信息 #

• 不再为每个版本创建独立顶点，为记录A、B、C各创建单个顶点，顶点ID直接使用原始记录ID（如A、B、C）。
• 在顶点上通过结构化属性存储版本信息：
  • 用version_ranges字段存储顶点的有效版本区间，比如A的顶点可存[{start:1, end:2}, {start:3, end:n}]；
  • 用Map类型的versioned_attrs存储各版本的属性集合，格式为{1: {...属性集1...}, 2: {...属性集2...}, ...}，避免冗余顶点。

2. 边的版本区间标记优化关联关系 #

• 不再为每个版本创建独立边，用单条边存储关联生效的版本区间：
  • A与B之间的边，添加属性valid_versions: {start:1, end:2}，代表A的v1-v2版本关联B的对应版本；
  • A与C之间的边，添加属性valid_versions: {start:3, end:n}；
  • 如果需要精准对应目标顶点版本（如Av1关联Bv1），可在边上添加target_version_map属性，比如{1:1, 2:2}，或预设规则（如目标版本等于当前A的版本），减少冗余存储。

3. 版本查询的实现方式 #

• 查询"A版本1的所有关联记录"时，执行以下逻辑：
  1. 定位顶点A；
  2. 遍历所有与A相连的边，筛选出满足valid_versions.start ≤ 1 ≤ valid_versions.end的边；
  3. 通过边上的版本映射规则，从目标顶点的versioned_attrs中提取对应版本的属性。
• 基于JanusGraph的Gremlin查询示例：

  g.V('A').outE().has('valid_versions.start', lte(1)).has('valid_versions.end', gte(1)).inV().valueMap('versioned_attrs')
  

  可创建valid_versions.start+valid_versions.end的复合索引，进一步加速查询。

4. 额外存储优化建议 #

• 为顶点添加latest_attrs属性，单独存储最新版本的属性集合，避免频繁从版本Map中读取，提升最新版本的查询效率；
• 定期归档老旧版本：对于不再需要查询的历史版本，将其从versioned_attrs中移除，转存到外部归档存储，压缩JanusGraph的核心存储占用。

内容的提问来源于stack exchange，提问作者A R K