Trafodion事务管理怎么理解

这篇文章主要介绍“Trafodion事务管理怎么理解”,在日常操作中,相信很多人在Trafodion事务管理怎么理解问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Trafodion事务管理怎么理解”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

成都创新互联公司-专业网站定制、快速模板网站建设、高性价比六合网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式六合网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖六合地区。费用合理售后完善,10年实体公司更值得信赖。

Trafodion这个词的本意是“事务”,可见项目组对事务处理的重视程度。

事务主要用来防止和处理数据出现不一致的错误。首先理解什么是数据一致性,给出具体的定义实在太为难笔者。还是举个例子吧。笔者年轻时大家都知道“香港四大天王”,他们是刘德华,张学友,黎明和郭富城。我定义这四个名字是“一致的”,而“刘学友”或者“张德华”就不是一致性的数据。或者在介绍的时候不全:比如“香港四大天王是:刘德华,”,其他天王要不高兴了。另外,刘德华唱过《忘情水》,如果数据库查询得到刘德华唱了《吻别》,也是不一致的数据。

造成数据不一致主要有两种因素,分别用两种事务技术解决。在Trafodion中,一个技术是日志;另一个技术是多版本并发控制MVCC。

日志

第一种造成数据不一致的因素是不可预知的故障。故障会导致正在处理数据的过程异常中断,比如数据正在往磁盘中写入的时候系统断电,那么结果就是未知的,有可能写入了不完整的数据。比如应该写入”张学友”覆盖原本的”刘德华”,却只写了”张”,剩下两个字节没来得及写入,所以还是老数据,于是磁盘数据变成“张德华”,造成数据了不一致,从来没有这个天王;或者说正在顺序写入四个人的名字,断电了,只写了刘德华,其他人都没写,也是不一致,要么4位全写,要么全都不写,写一个漏掉其他算是什么意思,看不起其他天王么?

处理这类错误的方法是WAL日志,write ahead log。即每次写入数据之前,先将变化写入日志,再写数据。这样,如果有错误发生,通过查询日志,就可以进行恢复。比如前面的例子,在将“张学友”写入数据文件之前,先写入日志。这样即便发生了故障,也不会有问题,如果故障发生在写日志的过程中,那么数据文件中依然是“刘德华”。如果故障发生在写数据文件的过程中,那么虽然数据文件中是“张德华”,但是WAL日志中却是正确的数据“张学友”,我们将日志replay一下,用“张学友”覆盖“张德华”即可。
如果遇到写中断错误,则可以利用日志将做过的操作全部撤销,比如写入了刘德华,然后出错了,查询日志,发现已经写了刘德华,那么rollback就是把“刘德华”删除掉。
通过日志,保证了在任何错误情况下,事务的一致性,即ACID中的A和D。

传统的日志技术包括Redo,undo, redo/undo等。和所有其他数据库一样,Trafodion采用redo/undo日志。

Trafodion采用HBase的WAL做Redo日志,当region恢复时,HBase负责回放WAL进行恢复。

在R1.0版本中,Trafodion将写入数据缓存在内存中,提交的时候才将内存中的数据写入磁盘,因此不需要undo日志。如果事务需要回滚,只需要将内存中的数据丢弃即可。

目前计划在R1.2版本中,Trafodion将使用一种被称为SSCC的最新技术,SSCC利用HBase的多版本支持存储数据的变化历史,以便提供repeated read隔离级别,这些数据历史同时作为undo日志。

MVCC的并发控制方法

还有一种错误,靠日志也不管用,就是多个事务并发写同一个数据,这类错误和我们在多线程程序中修改共享变量时发生的race condition是同一类问题。比如我们有两个线程写数据库,都要更新歌曲排行榜的第一名。线程A写入一行数据:[ singer=>刘德华, song=>忘情水];线程B写入另一行数据[ singer=>张学友,song=>吻别]。A和B一起写,一种可能的写法为A写了歌手后被B打断,B写了歌手和歌曲,A恢复执行,写入歌曲。最后变成了[ singer=>张学友, song=>忘情水]。可是张学友没有唱过《忘情水》。

处理第二类错误的方法被称为并发控制。通常有两种解决方案,第一种是传统的数据库通常使用的方法,即锁管理器;第二种是MVCC(多版本并发控制)。Trafodion采用MVCC的方法,没有使用锁管理器。因此在Trafodion中没有因为锁而引起的读写阻塞和死锁问题。
MVCC的基本思想和人们使用SVN版本控制系统是一样的,每个程序员都是一个事务,而修改的代码就是数据库中的表。如果用sourcesafe,那么就类似锁管理,张三修改写文件A的时候别人谁都不能读写,等张三修改完check in才行。用SVN后,如果张三正在写文件A,他写的是本地的一个版本,另外的人想读,可以随时读;别的程序员也可以修改文件A。但是两个人不能都commit。先commit的人成功,后commit的人需要做merge,如果两个人修改了不同的行(类似两个事务修改不同数据行),则一般都可以commit,SVN可以自动merge。否则就有冲突,需要第二个commit的人手动merge,或者干脆放弃(Abort)。Trafodion的MVCC方法和这个过程完全一样。

HBase本身提供多版本服务,因此非常适合采用MVCC技术。每个写操作都会产生一个新的数据版本,而不会覆盖老版本数据。读操作根据事务开始时间,读取正确的数据版本,即数据的一个历史快照。这避免了幻读,提供了repeated read隔离级别的保证。笔者孤陋寡闻,窃以为MVCC是Oracle最先采用的,Oracle工程师经常对此非常自豪,因为读不会被写阻塞,提供了很高的并行度。后来innodb山寨了Oracle的所有实现细节,使得MySQL也拥有了类似的能力;PostgreSql则采用了和Oracle/innoDb不同的MVCC实现方法,Trafodion的实现更加类似于Postgresql,即保存多版本数据用来提供快照读取,而非用作undo日志,然后定期进行垃圾收集,删除过期的快照。而Oracle则利用了undo日志来作为历史快照;前者读取历史版本的速度很快,因为数据和快照都在一起,但需要处理每条历史数据,检查它们的可见性,比较低效;Oracle则需要到undo segment中读取历史数据,应用undo日志对数据进行回滚,貌似会比较慢;但是不需要考虑GC的问题,而且节约了空间,因为undo空间一举两得。所以笔者认为Oracle/InnoDB的模式好些,但也主要还是取决于具体的应用场景,假如并发很高,读取历史版本的比例比读取最近数据的频率还要高,则PostgreSQL/Trafodion的模式应该更好,因为它们读取快照的效率更好。
不过作者水平经验都很有限,在这里议论其他产品有点儿心中坎坷,各位如果不以为然还请不吝赐教。

在Commit的时候,进行write-write冲突检测。如果发现两个并发事务同时写一行数据,就依据”first committer win”的原则处理,第一个提交的事务成功,而其他的事务则失败回滚。如前所述的线程A和B,A写入歌手信息刘德华之后,被打断,B写入张学友唱《吻别》,这条数据不会覆盖原始数据,而是新生成一条记录,(有些人喜欢称为COW),这条记录用线程B的事务ID标记它。这时线程A被调度回来,继续写入,同样A写的刘德华唱《忘情水》也不会覆盖原始数据,而是新生成一条新的记录,用A的事务ID标记。在commit的时候,Trafodion发现,这同一行数据有两条新纪录,根据first commit win的原则,A获胜。所以如果线程A提交,会成功;而线程B提交的时候会报错,回滚。最终数据库的记录为刘德华唱的《忘情水》。是一致的。

Trafodion目前的版本为R1.0,在今后的版本中(计划在R1.2版本中)使能一种新的并发控制算法SSCC。SSCC是中科院的研究成果,Trafodion团队和中科院紧密合作,即将推出这一全新的并发控制机制,SSCC提供比SnapShot Isolation更高级的隔离级别,同时对无状态写操作有很高效的支持。
SSCC认为SQL的写操作有两种:stateful的写比如a=a+1,是有状态的;stateless的写,比如delete,或者覆盖旧数据,这类写操作和历史状态无关。
无状态写在web应用中非常普遍,比如Google的index generating。采用这一机制,Trafodion可以高效地为相关的web应用提供强大的支持。

笔者也会尝试在后续的博客中介绍SSCC这一创新的并发控制算法。

并发控制保证了ACID中的I。
最后还有ACID的C没有提到,是"一致"的意思,然而这个C却不是靠事务处理器来保证的。ACID的Consistency靠数据库的约束保证。因此笔者不喜欢用ACID来描述事务。但是这个是经典,也不得不提。

两阶段提交

对于单机的数据库,比如MySQL,Oracle (not RAC),SQL Server,PostgreSql (not xl版)等,以上两个技术就完全可以实现ACID事务了。但是Trafodion是一个分布式数据库,操作分布在集群的不同节点执行,比如两条写操作可能由两个不同的ESP在不同节点运行,所以Trafodion还需要处理分布式事务。

Trafodion的事务处理器将并发控制的职责分成两部分,TM(Transaction Manager)负责整个事务的分布式并发控制,保证事务本身的一致性;RM(Resource Manager)负责数据访问的并发控制,保证数据的一致性。

具体来说,RM采用前面所说的MVCC技术,提供Snapshot Isolation级别的数据一致性。

在Trafodion中,每个HBase的Region都是一个RM。一个事务很可能会在多个Region上操作,比如事务需要更新两行数据,而它们分别属于两个不同的Region。在这种情况下,一个事务会有多个RM参与。而HBase的Region很可能运行在不同的物理节点上,因此这是一种分布式事务。分布式事务由TM保证整个事务的一致性。

TM使用两阶段提交协议来保证分布式事务的一致性。两阶段提交是一个非常简单直观的协议,类似公司的秘书安排几个人都必须参加的会议。第一阶段:秘书发信给所有参与者:“周一下午3点开会,OK?”,如果所有有人都回复“OK”,则最终决定开会进入第二阶段;如果有人回答no,或者有人不回答,则不开会进入第二阶段;第二阶段根据第一阶段的结果进行不同处理,如果是开会,秘书给每个人发信: '确定周一下午3点开会';如果不开会,秘书给每个人发信:‘不开会’。

每个事务都由一个TM发起,事务开始的时候,TM会给事务创建一个ID。此后,事务中的每一个DML操作都带有该ID,用来在RM内部确定该读取的数据版本。

在提交的时候,TM先进行第一阶段的prepare commit,向每个RM发送prepare消息。RM在收到prepare消息时,进行write-write冲突检测,如果有冲突则返回冲突,否则返回提交成功。TM得到所有RM的回复后进行判断,如果所有的RM都提交成功,则该事务成功,否则事务失败;进入第二阶段,如果事务成功,TM向所有RM发送commit消息,每一个RM收到commit消息后将事务的所有操作都写入物理磁盘,完成事务处理;如果有任何一个RM返回冲突,或者任何一个RM超时没有反应,TM认为事务失败,在第二阶段向所有的RM发送abort消息;每个RM在收到abort消息后进行事务回滚操作。

DDL事务

从R1.1版本开始,Trafodion还支持DDL的事务处理,比如创建2个表,第一个成功,第二个失败,回滚后,两个表都不存在。

到此,关于“Trafodion事务管理怎么理解”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!


分享文章:Trafodion事务管理怎么理解
网站链接:http://scyanting.com/article/gjdsje.html