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

问答 讨论
1

已经使用了一段时间的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 去遍历第二个问题的情况。（目前只能从图库外面的原始数据拉出来一个列表，然后一个一个遍历。性能特别差）

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

2

个人看法：

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