关于数据库:图数据库｜正反向边的最终一致性TOSS-介绍

4次阅读

共计 1569 个字符，预计需要花费 4 分钟才能阅读完成。

本文首发于 Nebula Graph Community 公众号

Nebula Graph v2.6 版本当中比拟重要的个性之一便是 TOSS。通过本文，我将带你全方位理解 TOSS 为何物。

家喻户晓，边分为无向边跟有向边两种。所以当按有向边去摸索时，就能够按正向边 / 反向边做遍历，Nebula Graph 也反对这种语义。比方：

go from "101" over known reversely yield known.kdate, id($$);

上述语句从点 101 开始反向的找所有的对应邻边。但，当用户应用 Nebula 插入一条边时，命令都相似于：

insert edge known(degree) VALUES "100" -> "101":(299792458);

上述语句看上去只写了正向边，并没有输出反向边：这是因为在 Nebula 设计时，当用户插入一条边时，零碎会默默地在后盾写入一条反向边。

以上文的那条 INSERT 语句为例，后盾的执行流程有：

Nebula Console 将 INSERT 对应的 request 发给连贯的 Nebula Graph Server；
Nebula Graph Server 收到后，依据正向边的信息对应补充出反向边的信息，并将这个 AddEdgeRequest 别离发往正反向边对应的主机；
Nebula Storage Server 收到这个 AddEdgeRequest 后，在本地（通过 raft）插入对应的边，并将后果返回给 Graph Server；
Nebula Graph Server 收到两边的后果后，返回给 Nebula Console；

流程图如下：

这里，对网络 / 分布式编程比拟相熟的同学可能当初就看出问题了：因为 Graph 对于两个 Storage 的调用应用 RPC，那么当 INSERT 操作执行的次数足够多，就肯定会遇到一边 RPC 胜利，另一边 RPC 失败（超时）的状况。换句话说，可能呈现一个 INSERT 正向边胜利，反向边失败的状况。

这种后果会反馈给客户端：如果用户有正反向边属性统一的需要，就须要对 failed 的 request 做有限重试。然而 Nebula Graph 做为一个数据库，将数据的原子性交由内部（客户端）来保障还是不适合的。

于是，诞生了一个需要——保障正反向边的原子性，即变更边时，正反边要么同时变更胜利，要么同时变更失败。这便是 TOSS（Transaction on storage side）的由来，用于保障对边进行 INSERT、UPDATE 或 UPSERT 操作的最终一致性。

随着 Nebula v2.6.0 的公布，TOSS 性能曾经上线。但基于性能和稳定性思考，Nebula Graph 默认将该性能设为 default disable 状态。有正反向边一致性需要的小伙伴们能够在 Nebula Graph Server 的配置中找到 enable_experimental_feature 这个选项，将它设为 true 并重启 graphd。如下：