nGQL支持不指定tag查询属性吗

  • nebula 版本:nebula v2.0.0-rc1
  • 部署方式(分布式 / 单机 / Docker / DBaaS):单机

nGQL有go, fetch, lookup, match等多种数据查询方式,根据官方给出的例子,除非直接指定数据id,不然都需要指定tag来查询。

比如match
MATCH (v:player{name:“Tony Parker”}) RETURN v;

v指定tag为player,不能match (v{name:“Tony Parker”}) return v,不指定v的tag。

假设有如下场景
我有很多tag类型:football player, basketball player, …
我想查询节点名字为xxx的某个节点,不管他是什么tag,怎么输入查询语句?

目前语句查询层面是需要指定tag和vid的

个人思考理解,这个可能跟数据存储有关,如果不指定的tag或者vid,仅基于属性查询,会造成扫描全表,性能开销较大。当然,如果你觉得这个功能很必要,可以继续探讨:handshake:

用go查询可以使用vid不用tag

好的,谢谢回答。

我觉得这个功能很必要,因为查询图的时候一般不知道数据的tag或者vid,就像例子给出的那样,或者同一个名称可也能对应多个不同tag的实体(存在歧义)。我用过neo4j和janusgraph都是能够进行模糊查询的,如果NebulaGraph没有类似的查询方法, 适配难度会增加,并且查询时延也会增加,不利于迁移。

另外我发现文档中似乎也没有指定两个节点,查询是否有关系的语句,不知道是不是文档中有遗漏。

以上这两个功能在进行实体链接(知识图谱利用前置步骤)的时候都是非常常用的,关于你提到的“仅基于属性查询,会造成扫描全表,性能开销较大”,但如果按tag_list依次查询,查询次数会从O(1)变成O(n),并且索引基于tag构建,没有全局索引,是不是查询时延会更大呢?

请问你们有计划实现这些功能吗?

我补充一下,就是这两个功能现在都可以实现,但是间接了一点。

1.实体查询要指定tag,虽然实体识别可以获得type,但是可能存在多个type并存的情况。

2.关系查询没有像janusgraph一样可以用gremlin=g.V(1010152).both().hasId(88054056, 70388048,…)这样的语句批量查询关系的方法。

不知道会不会导致时延增加。

目前不指定id或者tag查询是不支持的,这个我本周内部反馈一下,有消息会在这里同步:handshake:

这个Neo4j的示例语句麻烦给一下。

也请给一下Neo4j Cypher的使用示例

1 个赞

neo4j我现在没用,我只能提供gremlin的给参考哈

我理解你的查询其实是:

MATCH (v :football_player :basketball_player)
WHERE v.name == "Tony Parker"
RETURN v
//--- 或者
MATCH (v :football_player{name: "Tony Parker"} :basketball_player{name: "Tony Parker"})
RETURN v

如果不知道 TAG 有哪些:

MATCH (v)
WHERE v.name == "Tony Parker"
RETURN v
//--- 或者
MATCH (v {name: "Tony Parker"})
RETURN v

第一个 query 可以考虑支持,第二个 query 目前是没法支持,就如你所述,目前只有 TAG 的索引,没有 Global Index,不能遍历所有的 TAG 去查索引,这样 latency 估计是无法接受的。

1 个赞

嗯嗯,是这样的

您好,WHERE子句中貌似不支持IN的语法。比如上面的例子WHERE v.name IN [“Tony Parker”, “Kobe Brant”], 用udf_is_in() 2.0版本貌似也不支持。

2.0 支持in list的语法, 暂不支持ufd_is_in

[quote=“Gavingx, post:12, topic:2450”]
Tony Parker
[/quote]

不好意思,是我的语法有错误吗?

你用的lookup语句呀, lookup语句的where子句目前还不能用in list.

那如果我想通过球员的名字(name属性),找到他的VID, 然后通过VID再去找到他serve的球队。最好的做法是将球员的名字设为VID,然后不用通过LOOKUP,这样就可以一次查多个了;如果没有这样做的话,还有什么好的方法能一次通过属性查多个值吗?

我觉得这一类的需求还是挺多的: 通过属性去查某个vertex,如果这样,就需要创建INDEX, 但是创建INDEX就会显著地降低写的性能,所以生产环境最好不要创建索引,但是如果不创建索引就无法查到符合条件的node,也就无法满足某些需求;进入了一个死循环。。

所以也许不要这样建模,把要用的属性作为主键;

关于建模的一些建议,可以看看这篇文档
https://docs.nebula-graph.io/2.0/3.ngql-guide/20.appendix.md/graph-modeling/

我认为不是建模的问题(虽然建模可以解决这样的问题), 有时候在需求明确之前,根本不知道会用到什么属性(比如在这个需求中需要根据name去查player,在另外的需求中需要根据年龄查player,在需求明确之前,往往不知道需要以什么属性作为主键,这样的话,对不同的需求,相当于就要创建两个库了,而且如果以name作为主键,如果有相同的name,产生的冲突该如何解决也都是要考虑的问题),emmm。。我再找找看有什么好的方案吧。