社区 AMA｜我是姚成耀，你有什么问题要问我吗？

活动
1

8407c34521fc4c53a38aab78265d0c03_
8407c34521fc4c53a38aab78265d0c03_1920×817 105 KB

大家好，我是第二期做客「社区 AMA」的嘉宾：姚成耀。大家对什么是社区 AMA 有疑问的话，你可以先看下官方出的活动介绍：🎉社区 AMA 重磅回归！欢迎大家 Ask Me Anything🎙️🎙️

简单来说，社区 AMA 活动期间，你可以向我提指定范围的问题，我将在活动期间内回复你的问题。

关于我

我是姚成耀，现在在博睿数据担任大数据开发工程师，现负责公司内 NebulaGraph 数据库的开发及维护工作。从3.0.0版本开始接入一直到目前最新的3.8.0版本。
由于我们公司有很多私有化客户，所以有一些较为丰富的使用场景，也遇到过一些升级，迁移方面的问题，也对内核进行过一些二开，目前由于是偏向业务方向的二开，需要修改一下才能是更通用的功能，目前由于比较忙一直没时间改提pr来着 :joy:

提问范畴

你可以向我提问 内核原理、nebula-java 客户端、性能优化 相关的问题。

这边有礼

为了鼓励大家向成耀提出实用的问题，成耀将会在他的 AMA 结束之后指定 2 名提问者送上由 NebulaGraph 社区提供的交流礼。

本期交流礼：NebulaGraph 电脑包 & 笔记本（别想多了，是写字的笔记本～）

image
image669×870 32.8 KB

3 个赞
3

:tada:欢迎大家在两周内向成耀提问， 为了鼓励大家向成耀提出实用的问题，成耀将会在他的 AMA 结束之后指定 2 名提问者送上由 NebulaGraph 社区提供的交流礼： NebulaGraph 电脑包 & 笔记本（别想多了，是写字的笔记本～）

:mag:可以看看成耀写的文章博睿数据 x NebulaGraph ｜博睿数据在 NebulaGraph 的应用实践

4

使用JAVA客户端连接3.8.0社区版偶现
com.vesoft.nebula.client.graph.exception.AuthFailedException:Auth Failed:Insert session to local cache faild错误。还偶尔会有Execution had been killed错误。这是什么原因。

1 个赞
5

Execution had been killed ： 这个问题一般是因为你设置了超时时间，然后这个语句执行时间太长了。
另外一个报错我倒没遇到过，没啥印象。可以把堆栈贴出来看看不？

6

不好贴图，不过确实有这两个错，偶现的

7

大概率是内核的压力比较大，然后造成的一些响应慢从而导致的这些问题

1 个赞
8

姚老师，数据更新，有增量的方法吗？每次从测试库到生产更新，全量更新太慢了。
目前使用的是BR工具，单表在300G-1TB，您有增量更新的方法吗？或针对数据不定期更新有好的建议吗？

1 个赞
9

对于大数据量不定时更新，我这边目前有下面两个方案:

第一个方案：如果说你的数据都可以基于同一种形式来更新，那可以用子句的方式.比如 先使用lookup查出来一些符合条件的数据，然后再用| 后面跟上update set的形式来更新。这种我记得效率好像也不是特别好。
第二个方案其实是通过调整数据模型来将update转化为insert来操作的，举个例子：比如原本你的tag1有a,b,c,d,e五个字段，现在数据生产方可能会随机更新c,d，e三个字段，其中c，d是一定会同时更新的(或者说这个数据生成方一定能同时获取c，d)，e可能会和c,d一起更新，也可能会单独更新。这里就会把tag1 拆分成3个tag，分别是tag1_1包含a，b；tag1_2包含c，d；tag1_3包含e。这样所有的update就全部转化成了insert了

但是你的场景是需要将一个环境的库里的数据全量覆盖另一个环境的库吗？

3 个赞
10

感谢姚老师的回复建议呀！是的，我现在的场景，测试数据有更新后，是从测试库环境的库里的数据全量导出，然后覆盖另一个生产环境的库。
每次都是全量导出，全量覆盖，便实际更新的不多，考虑增量更新。您提到的字段拆分方法二看起来不错，可以节省时间效率，有机会测试一下。

1 个赞
11

你这种情况也可以看看下面两个帖子，通过直接同步文件夹的操作全量同步数据，可以和使用BR对比下速度：

1 个赞
12

你好，请问关系型数据库增量更新到nebulagraph图数据库的方案有那些？

13

我目前没有涉及过这方面的实践，所以我只知道通过flink的方式可以实现：

其他的方案我就不知道了

14

val poolConfig = new SessionPoolConfig(urls, spaceName, user, password)
.setMaxSessionSize(maxConnSize.toInt)
val pool = new SessionPool(poolConfig)
pool.init()

目前用的session线程池会在初始化的时候指定space，那对于不同空间的调用，是建议初始化多个线程池，还是通过use space切换呢

15

还有就是nebula在重启之后的超时率，会比全量compaction之后还要低，这个到底是什么原理呢，虽然知道重启之后会compaction,但这个不是只是p0层的吗，理论上不会比全量compaction对性能影响还大吧

这个问题补充下，现在是有两套集群，在用的上午超时比例过千2，就切了另一套集群（这个使用场景有差异超时会更高），然后当前集群重启，重启后切回来运行1h 超时率一直为0 :joy: 虽然运行一段时间后肯定还会升，但是这个收益高到感觉可以每天重启了

16

这个问题我这里使用的方式是不同space初始化不同的SessionPool，因为有遇到过use space和后面的语句请求到不同graph的情况，然后因为切换space的操作没有及时同步导致后面的语句执行失败的情况。
新版本有没有优化我没太关注。但是也不建议通过use space切换，毕竟这个也是需要成本的

17

明白，感谢 :clap:
还有就是并发大了storage排队导致的超时短时间飙升，对于多空间，并发是不是互不影响，storage的排队是针对单space还是整个空间呢

18

重启之后我记得不止只compaction p0层。应该就是全量compaction。至于重启比全量compaction之后的超时率低，应该是本身程序的负载降低下来导致的。当然这个也是我的猜测，没有关注过这个现象。

19

准确来说是互相影响的，因为连接池是不区分space的。一个storage中用于处理查询和写入的线程池只有一个，然后不区分space，大家一起排队。space目前做到的隔离只有数据隔离，cpu和内存目前没有隔离

20

但是我现在全量compaction昨天运行要2个半小时左右，重启耗时也就3分钟，达不到全量的效率，重启后看level分布也只是没有p0,p1-p4都有数据

我会关注这个现象就是正常运行时超时率太高了 :rofl: