场景：
- 计算单结点的出入度；
- 批量计算多个结点的出入度；
以前我们考虑过该需求。
能介绍下你的应该场景吗？
这个应该挺常见的需求，主要是表达图结点的 “degree” / “hot” 值，可以有两种表达方式：
- 通过图结点属性值；
- 通过图本身的特征，出入度是其中之一；出入度大的结点，表明与其关联的结点越多，其 “degree” 越大；
举例：
- 好友关系中，某个结点出入度很大，说明这个人交际圈越广；
- 数据血缘中，某个数据结点入度很大，说明产生该数据需要花费很大成本；某个数据结点出度很大，说明该结点能够为很多个下游提供数据；
1 个赞
如果是全图的每个点的degree，不要放nebula处理了，放到graphx之类的吧。
了解，不过在nebula中因为插入一条正向边时，同时会插入反向边，正常情况下一个节点的出度和入度是等价的。
“在nebula中因为插入一条正向边时，同时会插入反向边，正常情况下一个节点的出度和入度是等价的”
1、这里插入反向边的意思是增加一条终点指向起点的边么
比如A ，B，现在有一条A指向B的边，在插入的时候会插入两条边，一条是 A → B ,另一条是 B → A
不知道这样理解对不对，但如果是这样的话，跟实际不符，比如A打了个电话给B，但B并没有打给A；
2、另一种理解就是基于A作为起点插入一条 A指向B的边，基于B作为起点插入一条A指向B的边，这样比较合理
3、一个节点的出度和入度不能等价吧，比如A打给B打了5次，B打给A打了3次，对于A，出度为5，入度为3，对于B，出度为3，入度为5 （这里两个点是多重边情况，但对于非多重也是同样的）
@huotu 我猜想大佬的意思应该是：我们正常查询时用的是“正向边”；“反向边”是用于类似 GO... REVERSELY 的查询；以你的例子为例
A打了个电话给B，但B并没有打给A
A打给B打了5次，B打给A打了3次
可以理解为
- A 打了个电话给B，B 接到了 A 的电话；
- A 打给 B 打了 5 次，B 接了 A 的 5 次电话；
- B 打给 A 打了 3 次，A 接了 B 的 3 次电话；
@pandasheeps 这样子理解是否成立？成立的话，图结点的出入度区分是不是应该只考虑正向边？
1 个赞
某种边的出入度：
出度：GO … | yield count
入度：GO … REVERSELY | yield count
全图太慢 不适合TP
3 个赞
@junyicc @huotu
你的需求可以采用图计算实现的，可以使用nebula-algorithm 进行度统计。度统计的算法在这里：
https://github.com/vesoft-inc/nebula-java/pull/283
5 个赞
@pandasheeps 就 “在nebula中因为插入一条正向边时，同时会插入反向边” 这个说明，想进一步请教一下：
由于边的存储分为 out-key & in-key 两个 KV 存储，那正向边与反向边在存储上也是独立的两组 KV 吗？换句话说：正向边有 2 个 KV，反向边也会存储 2 个 KV ？
正向边就是out-key 1个kv，反向边是in-key ，1个kv
1 个赞
yeah
@pandasheeps 接着正向边&反向边的话题请教一下：
使用 Match 查询上下游关系的过程中发现，查正向边的时很快，而查询反向边的相对较慢，请问可能是什么原因？
例如：
查询反向边：
MATCH p=(v:tag1)<-[e:edge1*1..8]-(v2) WHERE id(v) IN ["vertex_id"] and all(t in e where t.exec_time>=1624636800 and t.exec_time<=1624723199) RETURN p,length(p) LIMIT 100
查询正向边：
MATCH p=(v:tag1)-[e:edge1*1..8]->(v2) WHERE id(v) IN ["vertex_id"] and all(t in e where t.exec_time>=1624636800 and t.exec_time<=1624723199) RETURN p,length(p) LIMIT 100
profile 一下，我本地测试这两条语句差别不大