已经实现多步update/insert的原子性保证了吗?

请问一个业务流程多步nebula更新/插入操作的的原子一致性问题有可用的新版本保证了吗?
还是说目前只能业务层面来保证,nebula还不支持?

点的原子性吗?暂时还不支持,边的话,你可以看下 TOSS 的介绍 Graph 服务配置 - Nebula Graph Database 手册

看着toss只是保证了插入单条边的最终一致性?期望的是插入多条边或点的时候,能保持一致性

@MuYi-方扬 有个事务一致性的问题。

你好,目前暂时不支持多个请求的一致性,需要通过业务层面来保证。

@MuYi-方扬 请问有计划什么时候支持吗?

:thinking: 暂时没这块的规划,据我所知,如果以后加入事务的话,可能也会优先在企业版先上线。

是的,目前在排期中,不过从目前的排期看,分布式事务的优先级会相对低一些,我们还是期望先把底层的数据存储、计算性能再做得更扎实一些;
你是怎样的场景?你对事务的需求程度是怎样的?

@MuYi-方扬 就是一个业务操作中可能包含:1、对tag的修改、对边edge的插入;2、对多个tag(属于不同tag type下)的修改。1和2内的操作是一个原子操作,一起成功或失败。您应该使用过mysql吧?和mysql的事务性一样

应该还不涉及分布式事务,就是类似传统数据库mysql的acid特性

嗯,这就是分布式事务。
我想问下啊,你的生产数据是主要进入到图数据库,还是说进入到其他存储中,再同步到图数据库里?

@MuYi-方扬 目前是规划只存入图数据库,在体验使用中,发现存在数据事务问题。您的建议是应该先用具有acid保证的数据库比如mysql存储,再同步到图数据库做分析?对一致性要求高的业务系统不建议直接用图数据库存储,比较适合分析用?

2 个赞

好问题

从原则上说,我们期望是直接进入到图数据库里的。但从现状来看,图当前主要有两类应用场景:

  1. TP场景,主要是实时风控或者实时推荐,但这两个场景对事务的要求没那么高,所以一般是可以直接进到图数据库;
  2. AP场景,需要分析的数据来源会比较广,图只是其中的一种分析模式。
    上面两种场景我们当前都有大量的应用,综合上述的两个应用场景,分布式事务的要求看起来没那么高,加上分布式事务的实现复杂度比较高,所以整体的优先级排得比较后面。

所以我也想多了解下你的场景,来完善这块的价值判断。

1 个赞

@MuYi-方扬 BIGO 的数据管理与应用实践 ,应用场景和遇到问题和这个帖子里说的情况差不多:“Nebula Graph 本身是不支持事务的,这块给我们增加了不少的工作量。最后一点,是使用习惯的转变,在查询方式上 Nebula Graph 自研查询语言 nGQL,而 JanusGraph 支持通过 Java API 和 Gremlin 进行查询。

问题出现了如何解决呢?在强弱类型转换上,BIGO 内部修改了 Atlas 的核心代码,增加参数动态判断 DDL 数据类型。简单来说,在写入数据或者执行查询时,通过特定参数来判断该条 nGQL 操作何种数据类型。在数据类型支持方面,Atlas 业务层自定义数据序列化方式来支持复杂类型。在原生索引搜索上,在系统初始化时自动创建独立索引和复合索引解决 Atlas 的搜索问题。在事务方面,在 Atlas 业务层新增半事务接口,减少 Nebula Graph 存储层数据出错的概率。”

1 个赞

本质看着都是稍微重要一点的业务数据,会担心没有事务,直接存储数据会丢失或不一致。

数据丢失的问题是不会的,只是说多条语句的一致性需要在应用层来保证。Nebula是可以保证单条语句的ACID的。

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