Star

一些功能方面的问题/建议

已经使用了一段时间的nebula graph,目前有几个功能方面的问题或者建议想和官方的开发人员聊一下。
第一个建议是: 查询的类型约束感觉目前的语法限制还有点大。之前在一个提问里面我问过 是否支持对查询结果的属性引用省略。具体的案例是:
GO FROM hash(“0b124bdeada9d45514550fb3bfd1e486”) OVER related_ip,related_domain,related_url BIDIRECT YIELD $$.IP.node_value AS IP_value, $$.DOMAIN.node_value AS DOMAIN_value, $$.URL.node_value AS URL_value

转变为

GO FROM hash(“0b124bdeada9d45514550fb3bfd1e486”) OVER related_ip,related_domain,related_url BIDIRECT YIELD $$.*.node_value AS value

相当于对目标结点的类型可以忽略,如果没有相应属性的即返回空值。

第二个建议是:目前经过询问,NG不支持给定一个起始点,给定一个终点类型,给定一个跳数,来返回该跳数范围内所有该类型的点。(相当于FIND PATH 的 dst只给定一个类型,不给定实际值)
目前我的做法是根据schema中结点和结点的关系,先递归按照跳数生成若干个查询路径的模式,配合pipe,得到最终有结果的路径模式。然后在对每一个路径模式进行反查,从模式的倒数第二个点(从目标点出发的第一个点)往出发点过滤。
想法比较初步,也没实际测过性能,不知道官方对于这类情况有没有什么什么建议。

第三个建议是:目前好像没有类似于 Select * from 这样选择一类结点的功能。其实和第二个问题有点类似,如果能直接获取一类结点,就可以利用目前的find path 去遍历第二个问题的情况。(目前只能从图库外面的原始数据拉出来一个列表,然后一个一个遍历。性能特别差)

不知道各位开发人员有什么建议或者看法

个人看法:

  1. 似乎不太赞同,要是把这个value再通过管道传给第二个语句的时候,似乎容易引起语法各种corner case;
  2. 查询引擎目前的架构是一个请求只在一个graphd处理,所以并发发往多个graphd会好一点。单个超大的FINDPATH请求(一个点出发,到一个类型的所有终点)很可能在一个graphd上会跑不出来。拆分下应用端比较麻烦,不过性能会好很多。
  3. 赞同. match (n: N) return n 还是挺常见的cypher操作

浙ICP备20010487号