丢弃Oracle:为什么这么难?

时间:2021-08-23 21:18:56

丢弃Oracle的话题,可谓由来已久。从十年前阿里提出了这一口号,并率先在公司内部实现了数据库的整体丢弃Oracle开始,到后面从互联网公司到传统企业也纷纷跟进,可以说丢弃Oracle的理念已逐步深入人心。但到直到现在,我们可以看到Oracle在国内的市场依然占有相当大的比例。即使在对外的很多丢弃Oracle宣传中,也大多是以非重度O记案例或非关键业务系统居多,大量核心、关键业务系统仍然采用O的方案。那造成这一现象的原因是什么呢?本文尝试对丢弃Oracle可能存在的难点及应对策略加以分析。下面文字代表个人观点,仅供参考。

丢弃Oracle:为什么这么难?

1. 难点:功能完备度

Oracle从上世纪七十年来发展而来,经过四、五十年的发展,其功能的完备程度达到相当高的水平。可以说,Oracle仍然是数据库业内功能最为强大的一款产品。从早期关系模型的实现、率先提出集群理念、到引入多模异构存储、软硬件一体化、人工智能在数据库的应用等等。Oracle在产品能力上不断增强。在本世纪早期的一段时间内,开源、大数据、云等确实对Oracle造成了一定的冲击,但后者加速迭代更新速度,可以说现在Oracle更是一个“全能”选手。在各个领域,均有着不俗的表现,甚至从某种程度来讲,技术选型采用Oracle基本都可以满足功能需要。但也正是这一现象,造成丢弃Oracle的选择是困难的,很难找到一款产品可以完美替代Oracle的全部产品能力。

所以,丢弃Oracle的过程往往不是一个简单的“苹果换桔子”的问题,而是需要从应用架构、基础架构、数据库架构综合考虑,进而造成较大的困难。举个简单的例子,很多案例中是采用MySQL作为Oracle的替代方案。但在真正使用中,会发现很多问题。排除底层的内核差异等外,仅从承载数据规模来看,两者的差异就很大。当数据量增大后,容量、性能问题暴露出来,你不得不去考虑使用类似分库分表等方案来解决,但这势必会带来应用架构的调整。在应用通过改造、引入中间件等解决这一问题后,又会发现数据分片后的整体分析变的困难,此时又需要引入分析类产品,还要解决数据同步等问题。可以看到一个看似简单的底层数据库技术选型的改变,变得越来越复杂。如果上述过程是在“在线”的状态下完成,这个过程又将难上加难。综上可见,Oracle全面而强大的功能,是在丢弃Oracle中不得不去面对的问题。

应对策略:

在应对策略上,首先要接受这一事实,功能差异是客观存在的。不存在一个完美的产品可以替代Oracle。此时能做的更多是细化场景分析,找出更适合项目情况的技术方案(或方案组合)。细化场景的目的,就是在于对功能需求做减法,找出替换功能边界,进而为后面的选型提供参考依据。如果是一个重度O的用户,就需要梳理所有场景,提出若干种差异化的技术方案来满足不同的需要。甚至针对同一场景,也要有几种方案可选,以面对成本、风险等其他因素的考虑。例如下图是多年前在公司整理的丢弃Oracle方案总结,其中场景部分正是基于上面的考虑。

丢弃Oracle:为什么这么难?

2. 难点:性能有差异

性能问题,可以说是数据库使用中大家最为关注的,也是在很多评测中经常拿来说事的,但这点是需要理性来看待的。性能指标,是受到工作负载(workload)、软硬件环境、测试方法、验收指标等很多种因素有关。很多数据库在评测中谈到性能碾压Oracle,此时要辩证来看待。例如前一阶段国内数据库厂商OceanBase,在TPCC的评测中再次刷新了此前成绩,可以说性能指标遥遥领先,这点也确实看到国内厂商取得了长足的进步,值得夸奖;但同时也要理性看待,性能打榜成绩不能完全代表性能好。客户更为关注的是在通用场景下的性能表现及性能上持续稳定输出。基于这两点,Oracle产品无疑做的非常出色。这里面重点谈到两点,一是Oracle的优化器能力,二是其软硬一体机方案。如果说数据库是基础软件的皇 、 冠的话,那么优化器就是皇、 冠上的明珠。优化器的好坏,直接反应数据库的性能表现。

笔者之前曾有过这样的体验,某项目丢弃Oracle迁移(包括应用改造等)总共花费三天时间,但上线后的优化足足花了一个月,甚至很多代码不得不重写。造成这一问题的原因,正是优化器的差异造成同样语句,在不同数据库的表现差异巨大。通俗来说,就是写的很烂的SQL,在Oracle中也可以执行的很好。第二点是软硬一体化方案,这方面Oracle是走在各厂商的前列,其最早提出一体机的理念,经过十余年的迭代发展,其综合性能表现令人印象深刻。其将最新的硬件技术,与数据库软件相结合,爆发出强大能量。可以说在极致性能表现场景下,一体机仍然是非常好的一种选择。

应对策略:

如何面对性能的差异呢?企业要做到以下几点:一是理性看待性能指标,提出适合自己的性能要求。过高的指标要求,只会带来后面技术选型的偏差。比单一指标更为重要的是,性能指标的多维度。要结合场景提出自己的指标规范,是满足低延迟,还是满足大吞吐;是满足高并发,还是满足稳态输出。针对这些,要提出一个综合性的测试标准。二是构建适合企业自身的测试集,TPCC等测试标准可以用来参考,但不要完全依赖而是从更贴近企业业务入手,构建自有的测试集。三是关注长期发展,做有预测性的性能评估。产品的性能表现是存在所谓拐点现象,很难做到完全线性扩展,要在评估初期就关注到这点,并根据业务发展做好预测评估及可能的备选方案。四是注意新技术的tradeoff。很多新技术确实给人眼前一亮的感觉,例如性能表现非常好,但此时要理性注意到其背后的取舍问题,进而评估是否选择及可能的解决方案。例如以Redis为代表的KV产品,在某些场景有很好的性能表现,但它的背后是舍弃了什么?什么场景适合它?后端架构如何适配这一技术,在解决了性能问题的同时,避免其他可能带来的问题?

3. 难点:生态完整性

Oracle的生态,无疑是其成功的主要因素之一。其发展的四、五十年来,在很多领域是其引领了整个行业的发展,其产品实现方式,很大程度上也成为了事实标准。后续的很多企业在产品设计上,也参考了Oracle的做法,某种程度将Oracle成了数据库的代名词。伴随着其成熟稳定的生态,也有很多相关企业,从底层基础设施厂商、到数据库周边的备份、监控,到上层的数据建模、治理,再到应用软件开发,这些企业伴随着Oracle共同发展,共存共荣。

例如:Oracle在传统金融领域布局多年,服务了大量银行客户。而这些银行的业务系统,则是有很多ISV来开发支持,他们已经非常习惯使用Oracle作为底层数据的存储、计算基础,此时更换数据库已不是简单的一替了之,而是需要大量的应用系统改造适配的过程。这其中还需要考虑新老系统的共存、数据迁移带来的应用适配等种种问题。可以说这方面带来的工作量,是整个丢弃Oracle工作中的主体部分,也是关乎到其最终替换效果能否达到预期的关键。此前看到的陆金所的分享,正是在业务梳理、服务化改造到后面迁移、切流等做了大量工作后,才逐步将数据库从Oracle迁移到MySQL上。

应对策略:

面对Oracle成熟的生态,作为企业要做好充分的准备,认识到丢弃Oracle工作不是简单的底层替换而已,要从方方面面着手准备。后者所占的工作比例,甚至超过前者,而这些“细节”会决定最终的实际效果。那么作为技术提供方来说,不要试图仅仅通过全新建立生态来替代Oracle,而是可做两手准备,做好一定的适配Oracle的工作。一方面,要尽量兼容Oracle的生态标准,方便其周边生态企业可以非常低成本的切换过来。这也是我目前认为国内产品做的相对薄弱的部分,很多产品都号称可完美地兼容Oracle,是实际效果往往大打折扣。第二方面是做好差异化声明。一个产品要完美地兼容另一款产品是不可能的,双方的差异势必存在。重要的是,将这个差异明确地传达给客户,不要等上线后才发现两者的行为不同。第三方面是做好迁移辅助工作,可通过文档、工具、专家服务等形式,提供给客户迁移辅助能力。比如阿里的ADAM平台,就是一款迁移评估产品,可以很方便地评估两者的差异并给出建议、甚至是部分迁移逻辑的实现。这样可大大减少客户迁移的忧虑。

4. 难点:成本不便宜

成本,是大家经常来谈到丢弃Oracle可能带来收益的一个说辞,但这里是有一个误区的。仅仅从字面成本代表的经济投入来说,丢弃Oracle往往就是不划算的;再从外延所涉及的人力成本、时间成本、风险成本、机会成本来说,更是如此。先从经济成本来看,Oracle采取的绑定资源的许可证+后期服务费的方式,是比较昂贵的;而且往往在议价方面也是比较强势。很多企业也是看到这一点,因而才考虑丢弃Oracle的。

选择了丢弃Oracle,仅从经济投入角度也会带来很大一笔投入。这里面可能包括选择其他商业产品(或商业服务)可能的投入,需构建新的服务体系带来的人力投入,上下游适配带来的更换类、改造类的投入等等。

再从人力成本来看,引入一款或多款新的数据库/大数据类产品来替代O,需要人力投入;如引入例如分库分表等中间件产品,在应用架构上、应用开发上也是需要人力投入的。如采用的是开源产品,还需要企业有很好的掌控开源产品能力,在必要内核上及构建周边生态工具平台上同样需要人力投入。

三从时间成本来看,丢弃Oracle往往有个周期较长的过程,是需要花费较长的时间成本。企业是否有足够的时间来完成这一过程?是否在快速业务发展中,有足够的空间来做?是采取大刀阔斧还是小步快跑的方式,这些都是与企业整体发展节奏相关,需要统筹来考虑。

四方面的风险成本,也是不可回避的一个问题。做任何技术决策都可能带来风险,针对这样的风险企业是否有足够的认知?为规避这一风险,是否采取了必要的措施?而这些措施,是否又带来了额外的经济、人力、时间成本,甚至新的风险点…(好吧,有点烧脑)

应对策略:

面对上述种种成本,企业该如何来解决呢?这里能采取的应对策略就是充分评估,将上述可能的成本因素都罗列出来。针对不同的解决方案,在不同成本投入上有所差异,这也是后面做选型时的重要考量因素之一。此外,还需要从长远及战略层面考虑这一问题,不要仅依靠成本说话。该需要长期投入的,要舍得投入;该纳入企业技术战略决策的,要敢于投入。不要被短时的成本收益所左右。

5. 难点:服务健全性

很多企业选择Oracle,是看中其良好的服务能力。所谓的“交钥匙”项目,让企业可以更安心在自身业务上,而不是技术本身。能够达成这点,一方面是Oracle产品本身发展多年,其功能完备度已经很高,并已形成了很好的交付能力;第二方面,完备的生态带来的交付闭环,大量的服务类企业保证了很好的交付质量。相比较而言,无论是国产数据库或者开源产品,都需要企业在产品服务上面有更多的关注。

应对策略:

针对这点,作为甲方的企业要更多做好选择把关工作,选择那些真正有实力交付的企业及产品。特别是某些基于开源产品衍生而言的商业产品,企业是否对内核有足够的把控力,尤为关键。此外,在其服务体系(流程、标准等)、客户案例等,都需要加以考虑。如果是企业选择自研或开源方案解决,则需要构建其成熟的运维体系,这点可参照商业解决方案。对涉及数据安全、可用性等关键指标,做好必要的预案并定期演练。而作为乙方来说,提升交付服务能力是需要一个过程,要承认与传统商业数据库厂商服务积累多年的差距。有意识地去模仿构建成熟的服务体系,同时加大对生态合作伙伴的支持,让大家共同参与到服务中来。

6. 难点:风险可控度

风险问题,是大家做丢弃Oracle选择时不得不面对的问题。作为基础软件,出现bug是难以避免的,但以Oracle为代表的大型商业数据库,经过多年的打磨积累已经可以做到风险可控。Oracle从最早物理逻辑的备份恢复、到高可用集群(RAC)、到数据卫士(DataGuard),再到独立的备份一体机。经历了数十年的发展,在多方面做到数据保障。这也是之前用户,敢于将核心、关键业务放在上面的原因之一。某种程度上讲,用户可以接受一定的服务降级,但在关键的数据安全、可用性上面,是需要严格得到保障的。与之相对比,丢弃Oracle之后的方案同样需要规避上述可能的风险。

应对策略:

为解决上述问题,甲方企业需要本着严谨的原则,将可能的风险因素都纳入到评测之后,以此来考察候选方案。同时,在推进过程中可以按照“先边缘、后核心;先局部、后整体”的原则,来推进丢弃Oracle工作。在这一过程中,不断完善打磨整个方案。作为乙方产品,如何能够打消客户的顾虑,让客户可以无忧选择也是非常值得探讨的。比如支持产品混部,将自有产品放在后端,通过全部只读->读写混合->全部可写的步骤,逐步替代的方式减少出现风险的可能。在比如支持前端路由选择,尝试使用小部分业务流量来验证,并逐步扩大等等。通过这些手段的使用,逐步提升用户使用的信心。同时,针对产品自身质量,同样需要严格把关,做好交付输出。

7. 写在最后

如何理性看点丢弃Oracle的价值?或者说,企业为何做出这样的选择?一方面,随着国内外形势变化,对国产化、自主可控有着实际要求。针对某些关键行业、关键领域,在政策上是有明确要求的。除此之外,企业更多选择丢弃Oracle是从成本、扩展性及自身技术战略出发的一种选择。此时,是需要企业冷静思考,做出最合适企业自身的选择。

从近年来的发展趋势来看,越来越多的企业开始将丢弃Oracle作为企业未来技术发展战略,同时也有很多的国产数据库或云数据库厂商加入到这一浪潮之中。这为国内的数据库发展带来新的发展机遇。丢弃Oracle本身并不是目的,如何在未来基础软件使用发展上有着自主能力才是关键。大势所趋,乘风而上;希望更多企业在丢弃Oracle中磨练自身能力,同时助力开源、国产数据库技术长远发展。