一文带你了解「图数据库」Nebula 的存储设计和思考( 四 ) _Nebula

VID 遍历点和边的原理

可以依据 VID 遍历点和边？

文章插图

文章插图

从上图你可以看到存储了个 Type 类型，在 v1.x 版本中无论点和边 Type 类型都是一样的，所以就会发生上面说到过的扫描点会夹杂多个边的问题。在 v2.x 开始，将点和边的 Type 进行区分，前缀 Type 值就不一样了，给定一个 VID ，无论是查所有 tag 还是所有边，都只需要一次前缀查询，且不会扫描额外数据。
数据预校验

Nebula 是强 Schema 的，插入数据时如何去判断这个字段是否符合定义？

是否符合定义的话，大概是这样，创建 Schema 时会要求指定某个字段是 nullable 或者是有默认值，或者既不是 nullable 也不带默认值。当我们插入一条数据的时候，插入语句会要求你“写明”各个字段的值分别是什么。而这条插入 Query 发到存储层后，存储层会检查是不是所有字段值都有设置，或者写入值的字段是否有默认值或者是 nullable 。然后程序会去查是不是所有的字段都可以填上值。如果不是的话，系统会报错，告知用户 Query 有问题无法写入。如果没有报错， storage 就会对 value 进行编码，然后通过 raft 最后写到 RocksDB 里，整个流程大概是这样的。
Nebula 监测

Nebula 可以针对 space来进行统计吗？因为我记得好像针对机器。

这个是非常好的问题，目前答案是不能。这块我们在规划，这个问题的主要原因是 metrics 较少，目前我们支持的 metrics 只有 latency、qps 还有报错的 qps 这三类。每个指标有对应的平均值、最大值、最小值， sum 和 count ，以及 p99 之类参数。目前是机器级别的 metrics ，后续的话会做两个优化：一个增多 metrics；二是按 space 级别进行统计，对于每个空间来说，我们会提供诸如 fetch、go、lookup 之类语句的 qps 。上面是 graph 这边的 metrics ，而 storage 这块因为没有强资源隔离能力，还是提供集群或者单个机器级别的 metrics 而不是 space 级别的。
Nebula 的事务

nebula 2.6.0 的边事务是怎么实现的呢？

先说下边事务的背景，背景是上面提到的 Nebula 是存了两份边 2 个 kv ，这 2 个 kv 可能会存在不同的节点上，这会导致如果有台机器挂了，其中有一条边可能是没有成功写入。所谓边事务或者叫 TOSS ，它主要解决的问题就是当我们遇到其中有一台机器宕机时，存储层能够保证这两个边（出边和入边）的最终一致。这个一致性级别是最终一致，没有选择强一致是因为研发过程中碰到一些报错信息以及数据处理流程上的问题，最后选择了最终一致性。
再来说下 TOSS 处理的整体流程，先往第一个要写入数据的机器发正向边信息，在机器上写个标记，看标记有没有写成功，如果成功了进入到下一步，如果失败直接报错。第二步的话，把反向边信息从第一台机器发给第二台机器，能让存正向边的机器向第二台机器发送反向边信息的原因是， Nebula 中正反向边只有起点和终点调换了一个位置，所以存正向边的机器是完全可以拼出反向边。存反向边的机器收到之后，会直接写入边，并将它的写入结果成功与否告诉第一台机器。第一台机器收到这个写入结果之后，假设它是成功的，它就会把之前第一步写的标记删掉，同时换成正常的边，这时整个边的正常写入流程就完成了，这是一个链式的同步机制。
简单说下失败的流程，一开始第一台机器写失败了直接就报错；第一台机器成功之后，第二台机器写失败了，这种情况下机器一会有背景线程，会一直不断尝试修复第二台机器的边，保证和第一台机器一样。当中比较复杂的是，第一台机器会根据第二台机器返回的错误码进行处理。目前来说，所有的流程都会直接把标记删掉，直接换成正常的正向边，同时写些更额外的标记来表示现在需要恢复的失败边，让它们最终保持一致。