事务处理


      和传统磁盘关系数据库比较，Altibase使用1/10的CPU命令完成相同的数据库操作，因此极大的提高了并发控制中的吞吐量，降低了响应时间。

      为了满足这样的要求，Altibase 2.0引入了MVCC（多版本并发控制）技术。在数据库使用传统的2PL协议的情况下，当一个记录发生更新操作时，即使记录上只有一个记录级的锁，这个记录上的读操作也会有延迟的问题。另外，如果在特定记录的读操作之后事务没有提交，更新事务不得不经常等待。而且，当发生大量数据的读或者更新操作时，由于数据量增加会造成并发控制的处理成本增加，可能会造成内存DBMS性能的突然降低。

      然而，由于Altibase 2.0 MVCC在事务执行时提供另外一个版本，事务之前的记录级读操作不管更新操作，反之亦然。因为Altibase 2.0在记录内部保存锁信息和记录级锁机制，所以锁处理的成本几乎为0。另外，读操作被设计成没有锁信息就可以进行。此外，即使事务执行大量数据的读和更新操作，由于锁管理的成本几乎没有，所以也能保证快速的响应时间。

       MVCC的问题之一是事务不能再访问的早期版本记录的处理。内存DBMS连续使用系统内存，如果系统不删除已删除的和更新过的记录的内存空间，总有一天会发生系统内存被耗尽的问题，所以内存DBMS需要立即回收不需要的记录和索引节点的内存空间并进行再利用的机制。Altibase 2.0有一个碎片收集线程可以保证内存优化的状态。

      Altibase提供了多种提高事务性能的技术。如果Altibase使用一般的事务管理方法，由于Altibase使用MVCC实现并发控制，很难得到希望的性能。在MVCC环境中存在这样的制约，需要判断另一个正在执行的事务或者在几纳秒之前结束的事务的状态。如果这种判断的成本很高的话，就会造成MVCC处理的成本非常高。

      由于这样的要求，Altibase 2.0管理事务池并通过直接访问事务池检查事务是否正在被执行。提前构造事务池对死锁的处理有很大的好处。一般的死锁检查方法需要特定的进程或者线程检查事务之间存在的环。并周期性的检查所有的事务。毫无疑问这样的方法会导致死锁事务服务的停止。需要实时做出响应的内存DBMS不适合这种死锁检查方法，因为死锁造成的服务停止会造成致命的后果。Altibase通过提出一种消除致命延迟的索来解决这个问题。就是说，当事务进行锁申请时，利用使用事务池检查是否有死锁发生的算法可以防止这种致命的后果。

      另外，Altibase 2.0动态提供大量隔离层，包括默认的commit read，repeatable read没有phantom read，所以您可以根据应用和工作量选择适当的隔离层。