关于部分异常数据对批量插入的影响

问答 问题
1
  • nebula 版本：2.0-rc1
  • 部署方式（分布式 / 单机 / Docker / DBaaS）：分布式
  • 硬件信息
    • 磁盘：SSD

space信息

CREATE SPACE test

tag、edge信息

CREATE TAG user()

操作：批量插入user

(nebula@nebula) [test]> INSERT VERTEX user() VALUES "123456789":(), "b":()
[ERROR (-8)]: Storage Error: The VID must be a 64-bit interger or a string.

Tue, 09 Mar 2021 16:44:33 CST

(nebula@nebula) [test]> FETCH PROP ON user "b"
+----------+
| VertexID |
+----------+
| "b"      |
+----------+
Got 1 rows (time spent 1494/2034 us)

Tue, 09 Mar 2021 16:44:42 CST
  • 可以看到，虽然第一个数据由于VID过长报错，但是不影响后面"b"数据的插入
  • 下面将"b"改成"a"
(nebula@nebula) [test]> INSERT VERTEX user() VALUES "123456789":(), "a":()
[ERROR (-8)]: Storage Error: The VID must be a 64-bit interger or a string.

Tue, 09 Mar 2021 16:50:23 CST

(nebula@nebula) [test]> FETCH PROP ON user "a"
Empty set (time spent 1419/1970 us)

Tue, 09 Mar 2021 16:50:25 CST
  • 后面的数据"a"的插入似乎一起失败了。想咨询一下，为何行为会不一致呢？
1 个赞
2

Good，这里应该在执行前先检查一下, graph 层需要先检查一下，再下发给storage @steam

2 个赞
3

这两条语句为啥行为会不一样？

4

@kyle 估计graph这里需要检查下，所有的vertex是否有效，然后再下发storage执行。
而不是在storage来判断vertex是否有效。否则就有的可以执行，有的报错。

5

猜测可能不是在一个storage中插入的，分片到不同的host

6

所以graph来检查下啊

7

确实是。

8

不在 graph 端检查是因为有一些工具支持直接从 storage 导入，还是会有上述现象。

9

感谢您的反馈。这边可以增加下部分成功的时候，在返回的消息里面提示下用户部分成功。或者增加部分成功的错误码。

1 个赞
10

现在storage已经检查了。
graph要是也检查的话，就不会出现这样的问题，会提前报错的。

1 个赞