[导读]替代从边缘走向核心，也从平替走到升级。
文丨刘雨琦
“数据库的国产替代，必须经过严格的考虑，保证不会出错，所以大多数企业的领导层选择按兵不动或者简单扩容。因为不换就不会错，选了很久如果选错，还可能会出现重大事故。”
某银行数据库技术人员曾对光锥智能一语道出了在数据库的国产替代中的核心难点。“真的要大刀阔斧的改革，需要领导层有魄力和决心，否则只能是边缘试探。”
下定决心全面替换，一方面是企业对国产数据库有足够的开放程度，另一方面，也要国产数据库有超过Oracle等老牌数据库的性能。一次改革，不仅完成“平替”，更能升级，帮助企业降本增效。
“数据库的国产替代，正在从边缘的OA系统，深入到核心的业务系统。如今国产数据库占20%的市场份额，传统数据库占80%的份额，这样的‘二八’分布将在三年之内颠倒过来。”Oceanbase副总裁王爽认为，国产数据库已经经历了磨砺产品性能、攻克替代难关的过程，将在三年内加速进入全面升级的阶段。
据光锥智能了解到，很多企业制定了内部战略，要在2027年做到数据库的“应替尽替”。国内企业逐渐对国产数据库重新认知并抱有开放态度，尤其在数据库最核心的金融场景，也有更多企业愿意“押注”在国产数据库上。国产数据库，从金融行业里“杀”出了一条路。
“没有经历过金融行业历练的数据库，不算合格的数据库。”
一直以来，金融场景都是数据库的最大练兵场，不仅是因为数据量庞大，同时，交易、分析、事故更加复杂，高频高并发是金融数据库的特性，更因为金融行业本身7×24小时不间断，对数据库安全性、稳定性都有更高要求，运维也更加复杂。
王爽举了一个例子：“以前银行的交易来自于营业网点，存钱、取钱、转钱，但现在已经互联网化了，频率大大增加。以前一年去营业厅也就三五次，但现在用户每天都在交易，每天点外卖、坐公交/地铁，每刷一次都会产生数据。这就造成了爆炸性的数据量增长，传统数据库处理起来，成本非常巨大。所以，并不只是为了国产替代，更是为了升级。”
此前，企业在选择国产数据库时，第一考虑的是与Oracle的适配和兼容关系，以降低应用和迁移成本。“2020年之前，几乎所有的国产数据库对企业宣传的核心价值就是兼容Oracle和MySQL。”一位数据库厂商对光锥智能讲道。
但在真正落地时发现，兼容是不够的，在适配时必须要取舍。Oracle数据库垄断了近20年，有很多特性逐渐落后，国产数据库的单纯替代没有意义，底层架构发生改变之后，性能要做到更加优化。
更重要的是，银行、保险、券商过去与Oracle进行了深度绑定，包括定义锁、治事务、嵌套表、索引组织表、PLSQL包、物化视图、Dblink、触发器、系统视图，改造难度极，如何提升庞存储过程中的识别效率关重要。
这不只依赖数据库厂商一家来完成，更需要使用方一起深度改造。太保集团与Oceanbase打磨的过程中，马波勇总结了升级过程中的三大挑战：
第一是国产数据库的性能，能否满足业务需求。“由于之前大部分系统使用传统数据库做支撑，在制定数据库的选型策略和升级方案方面，系统的兼容性、稳定性，数据迁移的便捷性、完整性是我们考虑的首要问题。第二，要考虑它在金融行业的应用案例是否广泛，是否具备足够的成熟度。第三个是在运维方面，需要具备较强的自主营运能力和支撑能力”，马波勇谈道。
第二是数据库的安全性和弹性伸缩能力。银行保险业数据量大、私密性强、波峰波谷期动荡，本地部署的数据库能保证安全性，但是相应的成本也会更高，且弹性伸缩能力差，无法灵活应变银行互联网化后的高频和多发需求。
那么，这三座“大山”，太保和Oceanbase是如何携手跨过的？
Oceanbase所升级的太保P17核心系统，同时面临着上述的三座大山。
“与一般热线系统相比，‘P17客户服务系统’涵盖了太平洋保险几乎所有子公司业务的服务入口功能，包括车险报案、车险增值服务、非车人意报案、道路救援、寿险保单查询、寿险保全受理、投保预约等等，对接周边系统超过200个，是太平洋保险关联关系最为复杂的系统之一。”
毫无疑问，对于P17的升级，是最为慎重的决定。2021年初，太保对国产分布式数据库，从功能、性能、易用性、完整性、可移植性、可靠性、扩展性、安全性等指标进行了全方位评估，最终选择了Oceanbase升级传统数据库。
2022年上半年，在不少项目暂停、放缓之时，太保和Oceanbase正在紧锣密鼓的远程协作，加班加点，只为搞定P17。
“项目刚开始时，正是上海管控最紧张的时刻。大家没办法到场地，造成了很多困难，但是OB在产业侧和技术侧联合攻坚，把这块硬骨头啃了下来。”林春谈起到项目的全过程，仍然不禁感慨。
Oceanbase的系统整体架构图
整个升级的流程，可以分为四个阶段：
第一阶段的重点，是通过Oceanbase的分布式架构彻底升级传统商用的主备架构，破除传统数据库与操作系统、中间件的耦合。据了解，与Oracle配套的DS、Cognos等产品对于Oracle深度依赖，适配改造复杂度很，将数据库分库分表，从集中式拆分成分布式，每个分片都能够独立执行读写，这个过程中需不断拆解中间件和操作系统之间的关系。
第二阶段，Oceanbase和太保并没有急着对业务进行升级，而是建立了迁移“标准”，一次次探索形成行业经验，破除替换升级的壁垒。
Oceanbase华东区金融技术服务总监郭文讲道：“厂商和用户侧的目标是希望效果稳定的与传统数据库兼容，标准化、流程化、制式化能够降低双方的人力投入，少走弯路，同时能够复制工具和经验。”
郭文介绍道：“Oceanbase通过制定33类标准规范和28类最佳实践，以及打磨了16款数据库转向工具，实现了标准化的Oracle兼容，这会极大程度破除迁移的不透明性，让企业更有信心，意识到升级不再是一件特别困难的事情。”
比如创新研发的“指南针”工具，能够对传统数据库进改造评估预扫描，包括近20个检查类，近200多个检查项，评估项全效，极提升项组问题排查的效率，缩短项周期从降低应改造成本。以“P17客户服务系统”为例，扫描出改造项约6000个，假设式排查2个问题/时，单个项即节约成本12.6/。
第三阶段，对P17中的业务场景进行逐个点测。对寿险保监会稽核接口系统、寿险营销员系统的佣金计算、智能决策服务平台和寿险统一承保平台等“一事一议”的替换。
第四阶段，从点测到全面升级。这里的全面升级，并不只是P17系统的全面升级，而是太保秉持着“先难后易”的原则，以P17这套最复杂的系统为模版，对周边配套系统进行分布式升级。在全面升级后，国产数据库的优异性能开始展现出来。据太保反馈数据，在保持了高运行性能、高可用能力的同时，数据库软件的运维费用大幅降低，每年可节省设备投入数亿元。特别是Oceanbase的高级压缩技术，结合“数据库瘦身”，将存储容量节省80%以上。
可以说，升级后的应系统弹性扩缩容、处理速度、数据加能均实现幅提升。
Oceanbase与太保的探索经验，也带动着金融数据库发展进入下一个阶段。
在整个实践的过程中能够明显发现，金融场景考验的不只是性能，更多还在于复杂业务中的灵活应变能力和适应能力。显然，诞生于金融场景的Oceanbase更懂行业的需求和痛点，也有机会能将实验室的解决方案，搬到了业务中去。
2013年，Oceanbase开始应用于蚂蚁集团的支付业务，当时大部分互联网企业都在采买Oracle，但随着双十一交易量的瞬时爆发，成本高企压力之下，促使了云厂商们开始自研数据库。
彼时Oceanbase最核心的任务，是完成降本增效和弹性伸缩。在这两个方面的经验，也在太保案例中得以体现。
林春就算过一笔账：“1TB的存储成本传统数据库要4500块钱，Oceanbase压缩到了三分之一，成本会大幅减少。另外数据库加密之后，对场地成本要求就没有那么高，也能降低硬件成本。”
2020年山东移动计费业务系统接入Oceanbase，其计费业务详单处理时长缩短至5分钟，处理效率提升30%，数据由7T压缩至0.7T，存储投入成本降低90%。
另一方面，Oceanbase的单机一体化分布式架构也能够在硬件存储资源帮助企业控制成本和灵活扩缩容。顾名思义，单机一体化的数据库，既能够适应大型企业的系统逐步替换需求，在不需要分布式架构时，也可以作为一个完整的集中数据库提供，让企业能够部署更灵活。
除此之外，全自研数据库也成为了Oceanbase换道超车的关键。
Oceanbase数据库创始人、首席科学家阳振坤此前提到，“全自研是个苦活累活，Oceanbase数据库是从第一行代码开始，到现在积累了几百万行代码量，但是好处也显而易见。”
让林春印象最深刻的是Oceanbase对Bug的修复速度非常震撼。常常很多问题，大致是第一天发现，第二天就能更新一个修复版本，这就体现了Oceanbase全自研数据库，将内核代码都掌握在自己手中的特点。Bug修复速度是技术兜底的一个很好的验证，如果没有对核心代码的掌控，从排查问题到解决问题，就做不到闪电速度。
也正是因为上述原因，让大型银行、保险业开始对国产数据库充满信心。
但这也只是万里长征的第二阶段，数字化、智能化的车轮滚滚向前，国产数据库从金融场景“杀”出来之后，千行百业中还有更广阔的星辰大海。