今年Oracle似乎又火了,火得要下掉,目前中国大概有240+数据库企业,在国产信创的大趋势下,一片欣欣向荣,国库之春已然来临。到今天为止,Oracle依旧是市场份额最大的数据库,天下苦秦久矣,Oracle在国内的这份市场,未来2-3年内注定会被瓜分得必须剩点渣,数据库市场格局也会基本定型。当年如火如荼的上,现在吹枯拉朽的下,小编君有种半夜从被窝里抓起来去扛炸药包的感觉,这么多年下来,去O才刚刚开始。
去O中数据迁移肯定是无法避免的,Oracle数据迁移的复杂度,在小编君接触的所有数据库里,应该算是最高的,庞大的功能对象和数据类型先不说,单就增量/全量数据同步上,就可以出一部专辑。我司的DBMotion数据传输迁移平台已经支持Oracle/MySQL/Mongo/openGauss/PostgreSQL的全系列,就目前中国的市场而言,Oracle和MySQL的需求量还是最大的,我们在支持这两款数据库的过程中也明显感觉,只要深入到细节,真是隔库如隔山。小编在这里列一些具体的技术点,各自体会。
1 增量数据获取
Oracle增量数据获取方式有很多,但实在不能忍受搞一堆的trigger,或者logminer那种蹩脚的dump+查表的方式,我们是直接解析的redo和归档文件,这是一件枯燥的逆向工程,自己组合数据类型,设计各种事务场景, dump分析日志输出,猜测验证日志格式,最终的效果就是速度快,实时性高, 50M/秒的redo量轻松应对,MySQL这块,我们是基于binlog的数据转换,这个文件的结构内容要清晰,精简太多。
2 事务边界
Oracle的redo日志一般是每隔3秒,或者用户commit时候刷到redo文件的,哪怕你不commit,也是有可能写到redo的,所以解析redo文件时,这个事务到底是回滚还是提交,你是不知道的,你得维护事务状态来应对即将到来的提交或回滚,包括大事务的回滚,而MySQL的binlog里面,就只有commit的事务,回滚事务是不记录binlog的,所以你只管往前解就可以,不用处理中间数据,不用考虑回滚。
3 事务的穿插混合
Oracle在10G开始就有了group commit,多个应用会话的事务在redo文件里是相互揉杂在一起的,你去解析的时候会发现,事务A开始了,操作了,下一条数据居然是事务B的,然后又是事务A的,而MySQL的binlog里面,每个事务一定是连成片的,绝对不交叉,排列得干净整齐,所以在事务的处理逻辑上Oracle需要更多的if else和结构设计。
4 列模式还是行模式
在数据库日志里面是存入行还是列?什么意思?就是你更新一行数据的A字段,日志里面是仅仅记录key+A字段的前后映像,还是将整行都记录进去?好像行业惯例里面,MySQL是全rows模式,Oracle基本是列模式,你很难扭转,这样在拼数据的完整映像时,Oracle就特别费劲,有时可能要反查源库。
5 神奇的RAC多日志流顺序
Oracle有种架构,叫RAC,多个节点,每个节点都能读写数据,现在MySQL界的Auroa架构只能实现一写多读,那么问题来了,你需要将多个Oracle RAC节点的日志流进行全局排序,保证数据更新的顺序,这个排序分批进行,不断前推,也要考虑部分节点事务未到达的等待窗口,想一想是不是和Flink多通道的CheckPoint barrier高水位有点相似了?
6 redo日志切换
Oracle的redo文件是固定的,循环覆盖使用,历史日志归档成archive文件,为了增量实时性,我们是直接解析online redo的,但当业务压力激增时,redo会击穿,你正在解析的数据可能会被抹掉,这是需要很精巧的机制去处理归档和redo的文件解析衔接,包括跨redo边界的事务处理,也有很多细节,MySQL的binlog是连续追加的,不存在这些问题。
7 基于rowid的全量抽取分片
在全量数据的抽取上,由于Oracle单表体量较大,需要考虑一些地方特色的加速方式,比如说同样是多线程抽取表数据,充分发挥并行IO的能力,每个线程获取独立的segment数据,自然是最快的,但是Oracle是堆表,根据Primary Key出来的范围数据,物理上不一定是连续的,也就是说IO层面在多线程上会交织影响的,这里有种方法,就是根据伪列rowid来计算分片边界,至少从OS角度,这个分片在物理上是连续且无交集的,pkrange和rowidrange的跑分结果如下,同样的环境,差距还是挺明显:
--fetch数据,并load加载到目标数据库,8并发,fetch size 40000笔
Bigoracle,81920000 rows,35480MBytes,pkrange parallel 8 process, ETL take 812 seconds!!!
Bigoracle,81920000 rows,35480MBytes,rowidrange parallel 8 process, ETL take 602 seconds!!!
--仅仅fetch数据,没有load操作,8并发,fetch size 40000笔
Bigoracle,81920000 rows,35480MBytes,pkrange parallel 8 process, ETL take 333 seconds!!!
Bigoracle,81920000 rows,35480MBytes,rowidrange parallel 8 process, ETL take 167 seconds!!!
rowid伪列的另外一个意义就是你可以认为Oracle所有的表都是有唯一性的,当我们处理MySQL的无主键/唯一键表时,困难就不止多了一点点。
以上只是Oracle迁移的冰山一角,可以看出,要高效处理Oracle的数据迁移,工程复杂度是挺高的。我们当初是先做的Oracle,大概花了1年多的时间,后面才做的MySQL,感觉如进了天堂一般,增量日志对接三个星期就拿下了,没任何悬念。当然解析出来的数据如何应用到目标端,同构异构,又是另外回事了。目前,我们会支持两种模式,一种是支持主流数据库的端到端;另一种是对接Kafka,设定好标准的数据格式,供下游系统订阅消费。
Oracle的历史包袱是很重的,很多业务开发重度依赖了O的各种特性,如dblink,存过包,分析函数,全局临时表,还有透明加密等等。这些功能不是在下一任里实现,就是到应用开发侧实现。在小编接触的去O中,大致分为3种,1是开发新系统,直接不用O,这是最开心的。2是借着系统重构和升级,将以前一些O系功能改造优化掉。3就是硬替,这种只发生在SQL写的很标准,基本把数据库当存储用的场景,否则没法执行。去O肯定是个持久战,也衷心希望,DBMotion能为去O贡献点绵薄之力!
原文链接:https://juejin.cn/post/7244435485175676985 作者:Squids数据库云服务提供商