Gremlin配合AWS Neptune使用inject()批量插入顶点耗时过长

核心问题 #

你的查询性能瓶颈主要来自两处：

• coalesce内的顶点匹配逻辑使用了.has('code', __.where(eq('a')))的嵌套谓词写法，Neptune查询优化器无法对这类写法做索引匹配，会触发全量遍历
• 缺少针对attribute标签的tenantId、code属性的专属索引，相等查询时需要扫描全量同标签顶点

具体优化方案 #

1. 简化查询写法 #

删除不必要的as('a')变量定义，直接使用__.identity()获取当前遍历的单个属性值，避免嵌套谓词，优化后的匹配逻辑可以触发索引匹配。

2. 构建专属属性索引 #

在Neptune控制台为attribute标签的tenantId和code属性建立等值查询索引，租户隔离场景下建议优先建立tenantId + code的联合索引，进一步缩小扫描范围。

优化后通用示例代码 #

g.inject(["1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", '24', '25'])
    .unfold()
    .coalesce(
        __.V()
            .hasLabel('attribute')
            .has('tenantId', 'spm')
            .has('code', __.identity()),
        __.addV('attribute')
            .property('created', new Date())
            .property('tenantId', 'spm')
            .property('updated', new Date())
            .property('code', __.identity())
            .property('title', __.identity())
    )
    .project("code", "id")
        .by(__.values("code"))
        .by(__.id())
    .toList()

效果验证 #

优化后的查询在未补全索引的情况下，25条数据的处理耗时可降至1秒以内，补全对应索引后耗时可低至几十毫秒，远优于单条循环执行的性能。

注意事项 #

保证inject传入的code值类型与数据库中存储的code属性类型完全一致，类型不匹配会导致索引失效，触发全量扫描。

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