Docker编译源码安装

  • nebula 版本:3.8.0
  • 部署方式: 分布式
  • 安装方式:源码编译 / Docker
  • 是否上生产环境:Y
  • 硬件信息
    • 磁盘( 统一分配资源-虚拟机)
    • CPU、内存信息 (16C 64GB *2台 32C 128GB *1 台)
  • 问题的具体描述
  1. 问题1


    为什么最后容器内编译后能够在宿主机使用?并没有挂载吧?并且环境也不同

  2. 问题2

最近节点和连边都已经达到了1~2亿,match一些简单的1跳或者2条很慢,经常RPC超时返回错误,甚至storaged挂掉,大佬们有什么部署建议吗?(资源见上面三台配置)

磁盘是 HDD?

是SSD,不过分配的是虚拟机,不知道虚拟化有多大影响

你的简单的 1 跳 2 跳的语句能否发下是怎样的?有的1 跳2 跳的查询其实也挺复杂的

不好意思,之前没有看到邮件,最近比较忙给耽误了。
其实也就是普通的一二跳,类似于 match (n:type1)-[e:e_type1]-(v:type2) return n, e, v
或者 match (n:type1)-[e1:e_type1]-(v:type2)-[e2:e_type2]-(r:type3) return e1, e2
之前测试发现从100~100w+数据规模查询,只要模式一样,console的执行完成时间都是差不多一致的,但是返回响应的数据时间有很大的时间,所以很多时候是因为rpc的数据传输导致的时间慢或者超过内存而挂掉或者RPC请求超时吗?(检索时间之和模式有关和数据规模关系不大?)
如果是这样是否哪里能够修改rpc的超时时间和传输的数据大小(之前grpc开发时发现需要调整传输数据的size)

你这“简单”的一跳、二跳并不简单。要全图扫描了。

是的,确实不算简单,例子举得不太对,但是是否确实由于传输数据过大也会导致超时呢?我想修改rpc传输数据大小和超时的参数
这是我用的ngql:

match (v:user)<-[e:user_follower_user1…2]-(v2:user) where id(v) in [‘xxxx’] with distinct v, v2, v2.user.followers_count as count order by count desc limit 250 match (v)<-[e:user_follower_user1…2]-(v2) return v2, e union match (v:user)-[e:user_follower_user1…2]->(v2:user) where id(v) in [‘xxxxx’] with distinct v, v2, v2.user.followers_count as count order by count desc limit 250 match (v)-[e:user_follower_user1…2]->(v2) return v2, e;

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。