事务处理及ACID支持
Version 2.2
本文档介绍TigerGraph平台的事务处理过程。 事务（transaction）一词表示一组有序的操作步骤的组合，每个步骤都是一个单独的逻辑工作单元。 只读操作表示该操作不会改动任何点或者边的属性值，也不会插入新点、新边，或删除任何一个已经存在的点或边。 改写操作则表示该操作会改动点或边的属性值，或者添加/删除某个点或边
TigerGraph的事务功能完整符合ACID规范（即原子性-A，一致性-C，隔离性-I和持久性-D），并能确保操作顺序的一致性。 事务的定义如下：
每个GSQL查询定义为一个事务。 每个查询中可能包含多个读或者写操作。
每个REST++的GET、POST或DELETE操作（可能包含多个改写操作）都是一个事务。
一条包含多个改写操作的事务可能会同时插入/删除多个点或边，或是同时改变多个点或边的属性值； 原子性的要求是需要让这样的事务“要么全部成功，要么全部不成功”， 即要么事务内的所有改写操作都成功完成， 要么所有的改写操作都失败。
TigerGraph的一致性是传统意义上的ACID一致性： 即事务中可以包含一些数据校验规则。 这些数据校验规则用于确保任何一个事务只能把系统从某一个有效状态（valid state）改动到另一个有效状态中。
TigerGraph也支持分布式系统的一致性： 即保证每个数据副本都按照同样的顺序执行同样的步骤。 这是目前常见的一致性模型中最严格的一种，比其它诸如因果一致性（causal consistency）之类的模型更严格。
TigerGraph支持序列化隔离级别（Serializable isolation level），它是最严格的隔离级别。 TigerGraph在其内部使用MVCC执行隔离操作。 MVCC（即多版本并发控制，Multi-Version Concurrency Control）对数据库不同的有效状态建立多个快照， 并通过不同的快照来隔离同时进行的多个数据库操作。 理论上，每个读或写操作都会生成一个快照。
任何未确认（uncommitted）的事务的数据修改结果对于同时存在的只读操作R1来说都是不可见的，并且与该事务是否先于或晚于R1提交，没有关系。
假设某个事务T1中包含多个相同的读操作，则这些读操作读取的结果是相同的； 即便在T1执行的同时，有其他事务改变了相关点或边的值，也不影响T1中的那些的相同读取操作结果的一致性。
假设某个只读事务T1中包含多个相同的读操作，则这些读操作读取的结果是相同的； 即便在T1执行的同时，有其他事务添加/删除了相关的点或边，也不影响T1中的那些的相同读取操作结果的一致性。
只有已确认的事务才会写入磁盘（固态硬盘或磁盘）。 TigerGraph支持WAL功能（即日志预写，Write-Ahead Logging）用于确保数据的持久性。
TigerGraph平台利用快照/MVCC功能隔离同时发生的操作。 简单地来说， TigerGraph平台会保存多个图数据的快照。当用户提交一个事务T1后， 它会在最新的那个快照上执行， 因为最新的快照包含了T1提交时间之前的所有已确认事务所做的改动， 而并不包含晚于T1提交时间的任何未确认事务的改动。 T1所执行的这个版本的快照，不会被任何其他事务改动，即便某些其他事务的确认时间比T1的完成时间更早也是如此。
让我们通过一些示例来演示事务处理过程：
先运行一个只读事务R1。 在R1完成前，启动一个改写事务W2。 W2的完成时间可能会早于R1的完成时间， 但R1并不能读取到W2确认之前所做的改动。（验证无脏读）。 即便W2的确认时间也早于R1的完成时间， R1对于相同数据的多次重复读取结果也是一致的，不会读到W2对数据的改动（验证重复读取）。 同时，也不会出现幻读现象。 这一切的原因都是因为R1所执行的数据快照不能被W2所改动。 简而言之： 如果R1开始于W2的确认时间之前，则对于R1来说，W2是不存在的。
先运行一个改写事务W1。 在W1确认之前， 运行一个只读事务R2。 R2会立刻执行， 而不会等待先W1完成后再执行， 就好像W1不存在一样。 随后， 即便W1在R2完成前完成并确认， R2也读取不到任何W1所做的改动。 原因在于R2所执行的图数据快照是基于R2提交的时间，该时间点上的图数据快照并不包含W1所做的任何改动。简而言之： 如果R2在W1确认之前开始， 则对于R2来说，W1是不存在的。
先运行一个改写事务W1。 在W1完成前， 执行一个新的改写事务W2。 W2会等待W1完成后再开始。 当多个改写事务同时提交到系统时，系统会根据它收到事务的时间，按序执行。