请问一个业务流程多步nebula更新/插入操作的的原子一致性问题有可用的新版本保证了吗？
还是说目前只能业务层面来保证，nebula还不支持？
看着toss只是保证了插入单条边的最终一致性？期望的是插入多条边或点的时候，能保持一致性
你好，目前暂时不支持多个请求的一致性，需要通过业务层面来保证。
暂时没这块的规划，据我所知，如果以后加入事务的话，可能也会优先在企业版先上线。
是的，目前在排期中，不过从目前的排期看，分布式事务的优先级会相对低一些，我们还是期望先把底层的数据存储、计算性能再做得更扎实一些；
你是怎样的场景？你对事务的需求程度是怎样的？
@MuYi 就是一个业务操作中可能包含：1、对tag的修改、对边edge的插入；2、对多个tag(属于不同tag type下)的修改。1和2内的操作是一个原子操作，一起成功或失败。您应该使用过mysql吧？和mysql的事务性一样
应该还不涉及分布式事务，就是类似传统数据库mysql的acid特性
嗯，这就是分布式事务。
我想问下啊，你的生产数据是主要进入到图数据库，还是说进入到其他存储中，再同步到图数据库里？
@MuYi 目前是规划只存入图数据库，在体验使用中，发现存在数据事务问题。您的建议是应该先用具有acid保证的数据库比如mysql存储，再同步到图数据库做分析？对一致性要求高的业务系统不建议直接用图数据库存储，比较适合分析用？
2 个赞
好问题
从原则上说，我们期望是直接进入到图数据库里的。但从现状来看，图当前主要有两类应用场景：
- TP场景，主要是实时风控或者实时推荐，但这两个场景对事务的要求没那么高，所以一般是可以直接进到图数据库；
- 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 天后被自动关闭。不再允许新回复。