panda
1
对图数据库不是很熟,以前用惯了mysql和mongodb。现在用nebula设计schema时,感觉不太顺手。
假设我有以下的schema (为了方便,暂且用graphql来表示):
// 用户表
type User {
name: String,
followings: [User],
followers: [User],
posts: [Post],
topics: [Topic]
}
// 主题表
type Topic {
name: String,
description: String,
user: User,
members: [Member]
posts: [User]
}
// 帖子表
type Post {
text: String,
member: Member,
topic: Topic
}
// 主题的成员表
type Member {
user: User,
topic: Topic,
name: String,
level: Int,
join_date: DateTime,
posts: [Post],
}
这个用nebula来做的话,没有表关联的概念,没法设置关联字段, 怎么设计它的schema比较好 ?
查询的时候是否能一次性把需要的标量字段和关联字段查出来 ?
请给些建议。
现在用的v2版本。
关联字段可以建模成nebula中的边: 比如你的用户表中的followings字段, 表示的是一个User关注另一个User, 即User—following—>User, 那following字段就可以就可以表示为点User之间的关系(边)
panda
3
@jievince
这些概念我知道的,但我不是想问这个。
我比较疑惑的是:
1,tag和edge是分离的,没有强关联,那么查询的时候怎么把它们查出来,比如上面我要把post的数据都查出来,是不是先查tag,然后edge边再一个个去查? 每个查询都得这样处理?
写入数据的时候也这样操作吗 ? (感觉超麻烦)
2,多个tag共用相同的边,比如上面的 user: User
边 ,Topic、Member都使用了这个边,是否会引起数据混乱,怎么区分?(不想换名字创建新的边)
3,关联字段通常有一对一关联,比如上面的user: User
,有一对多关联,比如上面的followings: [User]
,还有多对多关联,那么这些在nebula里面怎么表示 ?
4,对于关联列表,通常需要统计数量,通常做法是聚合查询,或者单独设置count字段来保存数量,那么在nebula里怎么处理比较好?是在边里面设置count属性吗?比如CREATE EDGE followings(count int default 0);
?
官网文档写的太术语化了,没有结合实际场景和案例,很多东西也没有细讲,理解起来很费劲。
可以的话,针对上面的schema,帮忙弄一个最佳的nebula schema 案例,包括查询和写入等。
1 个赞
yee
4
首先感谢你提供的场景,可以给我们的文档提需求 @Amber @min.wu
下面针对以上的场景,简单组织其中关系如下:
目前 Scan By Tag 的功能还没有完成,后续会在 Match 中实现,比如 MATCH(p:post) RETURN p
。这种全量扫 tag 的 query 依赖索引,同时也会比较消耗内存,数据量大的情况下容易 OOM。
数据写入只要填入对应 post 中的 properties 即可,不需要其他操作。
这里你应该是把 tag 和 vertex 的概念弄混了,建议你看看 Nebula Concepts 先。实际中不会出现如你所诉的不同顶点共用同一条边的情况,边的 id 有 src/dst vertex 构成,如果两端的顶点相同,再加上 edge type 和 rank 也相同,即为一条边。有一处不同,即为不同边。不同的边可以是相同的 edge type,但往往不会是相同的顶点,除非 rank 不同。
像 user – topic 的 edge type 可能是 focus,而 user – member 的 edge type 就可能是 is.
还是参看上一条,nebula 不做 tag 跟 edge 之间的建模,而是 vertex 和 edge 之间的 relationship,tag 是附属在 vertex 上,vertex 之间通过 edge 来描述关系,所以无论是 1-1,1-N 还是 N-N 都是体现在每个顶点的出入边上。
nGQL 支持 Count 等聚合操作,可以不需要通过设置 counter 属性的方式来统计
5 个赞