JanusGraph入边统计排序查询性能优化实践

目标 #

以最高效的方式，将指定label的顶点按照指定type的入边数量进行降序排序。

环境配置 #

• Ubuntu虚拟机，分配内存23GB
• 部署JanusGraph 0.6.1完整版
• 本地图模式部署，使用默认conf/remote.yaml配置文件
• 全库总顶点数约40万，其中目标label对应的顶点约2000个
• 全库总边数约150万，其中目标type对应的入边约100万
• 已完成部分基础索引构建，未针对边构建专项索引

初始查询实现 #

初始使用的Gremlin查询语句如下：

g.V().hasLabel(<label>).
    order().
        by(inE(<type>).count(),desc).
    limit(10).
    project("name","score").
        by(<property_name>).
        by(inE(<type>).count())

存在问题 #

上述查询可以返回符合预期的结果，但执行耗时极长，最长耗时超过7分钟，完全无法满足业务使用要求，需要从查询写法、索引配置等维度寻找可行的优化方向。

前期调研结论 #

• 梳理组合索引、混合索引的官方能力说明，判断两类索引均无法解决当前的排序统计性能问题
• 调研顶点中心索引（vertex-centric indexes）的适用场景：由于当前需求是统计指定type入边的总数量，而非筛选获取入边子集，暂无法确定这类索引是否能带来实际性能提升。

已验证有效优化方案 #

• 查询语句优化：参考社区已验证的Gremlin写法调整查询逻辑，不做任何配置改动的前提下，查询耗时从7分钟以上下降到约2分钟。
• 标签索引替代方案：新增无业务用途的vertex_label属性，专门为该属性构建索引，将原查询中hasLabel(<label>)的写法替换为has("vertex_label", <label>)，调整后查询耗时进一步从2分钟下降到约5秒。该方案是JanusGraph不支持原生label索引问题的通用替代解法。

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