记得按照下面模版提需求哟
1 台虚拟机:4 Core,4G Mem
Space 名称 | 分片数量 | 备份数量 | VID 类型 2 |
---|---|---|---|
test6 | 3 | 1 | String |
配置基本上都是按照官方文档还配置的,数据量100多万6种不同的点,一种类型的边
GO 1 STEPS FROM “3” OVER like REVERSELY YIELD like._dst as id | FETCH PROP ON seller $-.id 查询出来大概8万的数据,需要1s多的时间?
记得按照下面模版提需求哟
1 台虚拟机:4 Core,4G Mem
Space 名称 | 分片数量 | 备份数量 | VID 类型 2 |
---|---|---|---|
test6 | 3 | 1 | String |
配置基本上都是按照官方文档还配置的,数据量100多万6种不同的点,一种类型的边
GO 1 STEPS FROM “3” OVER like REVERSELY YIELD like._dst as id | FETCH PROP ON seller $-.id 查询出来大概8万的数据,需要1s多的时间?
你可以把你的query变成这样
GO 1 STEPS FROM “3” OVER like REVERSELY YIELD $$.seller.prop1, $$.seller.prop2
prop1 和 prop2你就替换成你实际 seller 这个tag的所有属性
你看下服务端的处理时间,用console执行下
在console执行那个命令
我的意思是你通过nebula-console执行同样的query,nebula-console就会打印两个世界,前面的时间是服务端处理的时间,后面是客户端的,你这100万行数据经过网络到达客户端,再加上客户端的数据解码,时间肯定就长了。但是你可以对比想服务端的处理时间。
硬盘不行