- nebula 版本：3.5.0
- 部署方式： 分布式
- 安装方式： RPM
- 是否上生产环境：N
- 硬件信息
- 磁盘（ 2T）
- CPU（48核）、内存信息（251G）
使用ID查询 语句如下
match(m:tag1)-[:挂载于]-(n:tag2)-[:挂载于]-(q:tag3) return m,n,q
数据量 tag1 有17条数据 tag2有30万数据 tag3有30万数据
tag2 和 tag3 是 一对一挂接的 然后 tag1 里面的数据 基本是一对多的
因此 在tag1里面有一条数据 是对应 后面的全部数据 也就是挂接了30万条数据 然后使用这个id 查询的时候
返回结果的速度 是 50秒左右
tag1的一条数据 挂接了 14万 条数据 返回速度 是 8-10秒
tag1的一条数据挂接了 5万以及5万以下的 返回速度 在1-5秒内
这种情况是正常的吗 如果有优化方案 怎么优化呢
执行计划在内网 不好弄出来 而且 数据量大小 上面已经大致说过 一个id 下 如果有30万数据 返回速度 就是50秒左右 1个id 下有十几万数据 返回速度是10秒左右 一个id 下数据没有超过5万 返回速度大致在2秒左右
这种情况是正常的吗
几个建议，如果需要继续优化的话可以考虑几点：
- desc space <space_name>
1.1看下当前用的vid type是什么，经验上，vid是int型会更快，同时vid越小越好；
1.2 看下partition num设置是多大，一块ssd盘设置大概10个partition是建议值，这种场景下，多加点对性能有优化； - 看查询结果，你最后需要的是什么，是只有vid还是要整个点的内容。
2.1 当前是会返回整个点的属性的。如果需要所有属性，那需要检查下属性的数量和配置的属性类型，属性越多，数据越多，比如string比较大，做序列化反序列化是需要时间比较长的。
2.2 如果只需要部分数据，比如只要vid，可以返回id(m),id(n)这样的，或者只要部分属性，可以m.tag1.<属性名>; - 整个查询过程中是否允许截断。如果允许截断，可以配置下截断参数，参加下面文档：Storage 服务配置 - NebulaGraph Database 手册
或者在查询语句里增加limit - 如果只要点的话，也可以考虑用go语句。性能会比match好一些
1 个赞
1、当前使用的vid type 是 flxed_String (128) partition num 是 100
2、查询结果 是数据全部返回 整个内容
3、我们的属性类型都是string 类型 属性的话 一般在20-40之间 数据量的话 起初在30W 后续会越来越多的
vid看有没有可能改成int，或者考虑对string做hash。
其他的就是考虑效率和结果的平衡了。你现在返回的数据量看起来比较大，所以相对也会慢点。
另外，你返回全部内容下一步做啥？感觉这里一般都有不少优化的地方
返回的结果呈现在页面上 就像搜索框内 搜索一个线损 返回的就是30万数据 这样
如果是在页面上的话，为什么要返回所有数据？返回所有数据你也看不清楚啊。
最好的做法是返回结果的时候只返回必要的信息，比如vid。然后用户点击这个点或者这个边的时候再触发一次点查或边查。这样效率是最高的。内存开销也是最小的，对客户端的负载压力也比较小
另外，30w的数据不做limit吗？据我所知还没有一个可视化能呈现那么多数据哦
做limit 但是 社区版 limit 没有下推 30W数据全部查询到然后limit 作为一个算子返回对应的数据而已
这个是3.6.0版本的 我们刚升级3.5.0 一段时间不考虑升级版本的
那就
1、配超级节点截断
2、只返回id
这个与版本无关。思路是一致的，之前版本的文档中也有相同的描述。
1 个赞
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。