金融数据库转型有多个国产数据库案例，其中有书籍出版很少。在有限的书籍里，由太保数智研究院的首席数据库架构师林春老师撰写的《金融数据库转型实战：基于OceanBase》（后简称《数据库转型》又是将国产数据库转型困难和技术介绍的最为详细的。本文是这本书的读后感，也有结合自己以往在金融客户推广OB的经验的个人思考。同时本文也可以认为是一篇面向个人公众号粉丝的书籍推荐语。
金融行业数据库转型最早始于支付宝的去 IOE 决策，其中取代 ORACLE 的就是 OceanBase ，其难度在当时好比愚公移山。今天大家乐于说道这个故事一是这事成了，二是这事是发生在别人的身上。当这移山的责任落在某个人或某个团队身上时，估计没有人会很开心。OceanBase 对外推广的难度也不必前面去 O 低。OceanBase 早期对外推广时首选金融行业并且是银行业务也是因为支付宝业务（包括网商银行）就是一个金融行业案例。尽管如此，传统金融银行并不一定放心，在业务选型上普遍遵循先非核心业务试用2-3年，再核心业务。比如说常熟农商行先是互联网中台业务使用 OB 1.4，两年后就开始核心改造替换使用 OB 2.2 。保险业务比银行业务还要复杂，太保在数据库选型中还采取“先难后易”的思想更显得魄力非常大。 当然，每个行业的核心业务都有自己的复杂之处，OceanBase 在运营商行业的去 O 也是很值得大书特书（不过还没有书籍出来）。《数据库转型》这本书是 OceanBase 的第一本介绍核心业务数据库转型经验的，这是这本书值得推荐的第一个理由。
数据库转型绝不是数据库团队的独角戏。数据库转型是数据库团队的机遇，更是技术团队、业务团队转型的机遇。阿里和蚂蚁在去 IOE 运动中孵化了 PolarDB 和 OceanBase 两大数据库品牌（严格说还有大数据数据库产品，如 ADB ），同时也孵化了 EDAS、SOFA 等分布式服务产品。这里说的并不全，往大了说诞生了阿里云。阿里云上售卖的大部分产品都是跟去 IOE 孵化出来的。其原因是数据库转型不是单纯的数据库平替。业务技术架构如果不变化只做数据库转型就有点类似“刻舟求剑”。传统的应用技术架构并不一定适合转型后的 OceanBase ，说具体一点就是不能将 OceanBase 的优势发挥出来。而业务需求是一直向前跑，单纯的数据库平替，很可能导致最后业务发展的瓶颈又会落在数据库上，从而导致数据库转型这个项目失败。 所以数据库转型也要求业务技术团队转型。应用要做分布式改造。应用自身要具备高可用、扩展性能力。应用改造的思想是要模块化设计，大的模块之间解耦，使用微服务。此外，数据库平替对数据库兼容性要求很高。OceanBase 对 ORACLE 和 MySQL 的兼容性也不是完全兼容的，是一路多个版本逐步完善的。所以面对 OceanBase 对 ORACLE 和 MySQL 兼容性做的不好的地方或者兼容了但是性能不好的地方，也需要应用改造。只不过越往后使用 OceanBase 应用为兼容性改造的成本越低。《数据库转型》书里总结了应用改造成本在 60% 左右，这个是很中肯的。业务的转型就好说了，互联网的发展，2B 和 2C 业务都得到发展，业务也追求更高的价值，商业上需要不断的拓展，传统的业务架构设计更多的是掣肘。 所以数据转型这样的大项目能成功，首先是要先感谢技术团队和业务团队的支持。《数据库转型》书里详细的介绍了技术在传统数据库上的痛点，以及在数据库替换为 OceanBase 后面临的新的挑战和解决思路。这里面不是单纯的数据库技术说明，而是结合业务去谈技术。这种业务的数据库转型具体案例的技术分析的阐述在数据库类技术书籍里比较少，是很有借鉴意义的。这是这本书值得推荐的第二个理由。
阿里在去 IOE 之前，拥有当时国内1/3 的 ORACLE 顶尖技术专家。去 IOE 后，这些 ORACLE 专家大部分要么转型到 MySQL 要么就出走了。技术的发展既能提高生产力，也会引起生产关系的变化。传统的 ORACLE 专家在互联网行业失去了昔日的荣耀，大批 MySQL 和 PostgreSQL 技术专家涌现，以及大批应用架构、中间件技术等产品以及专家涌现。如今数据库转型的大潮也开始蔓延到传统企业。江山代有人才出，各领风骚数十年。按如今的技术发展速度，说十年都有点长了（大模型又一次改变了这个技术生态，跟本文无关就不展开说）。OceanBase 技术是可以媲美 ORACLE 技术的产品，其功能体系还在继续膨胀中。但是由于自动化运维技术的发展和普及，以及 OCP 的优秀能力，OceanBase 的运维门槛得到极大的降低。很多客户都说试过多个国产数据库，OceanBase 的运维平台（OCP）、开发者平台（ODC）以及数据迁移（OMS）是做得最好的（好看且好用）。所以如今的年代单纯的懂数据库技术（比如说 OceanBase），并不一定能复刻往日的 ORACLE 或 DB2 DBA 的荣耀。在企业里，既懂数据库又懂业务的人才发展的会更好。《数据库转型》一书里介绍了太保保险的客户服务系统业务，以及业务的数据库开发和运维方面的一些技术细节。这里提到的技术在 OceanBase 里并不算深奥，也不难理解和掌握。这里有价值的是业务分析和技术方案的案例。在互联网大厂里有个岗位叫解决方案架构师，就是专门做这个事情的。不同的行业需要不同的解决方案架构师，传统大型企业在数据库转型过程中不能一味依赖数据库厂商，要培养自己的解决方案架构师。《数据库转型》其实是为数不多的介绍业务解决方案的书，这是这本书值得推荐的第三个理由。
当真的开始数据库转型项目，难度和风险是很大的。这有多方面原因。一方面是数据库产品自身的不确定性。虽然在其他行业或者同行里已经有案例了（更不用说还没有行业案例的场景），但每个企业的业务还是有差别的。数据库可能会遇到 BUG 或者使用不当导致性能不好等问题。另外一方面就是客户自身的不确定性。数据库转型项目需要业务和技术团队一起协同作战，涉及到的人越多这种沟通协调就越难。很难确保大家对一件事有相同的看法。 在具体的风险应对方案里，《数据库转型》提到一个很好的经验这里值得特别说明，就是为了降低应用改造成本，将一些风险提前在 ORACLE 数据库端就识别并解决掉。书中风趣的提到，很多业务的 ORACLE 数据库都是“带病运转”，在迁移到 OceanBase 数据库后大概率会“水土不服”。比如说 ORACLE 里高逻辑读的 SQL 到了 OceanBase 后，逻辑读肯定还是很高，国产服务器的 CPU 能力以及数据库对硬件的使用能力都不一定比以前好，最终这些 SQL 性能很可能会更差。提前优化这类 SQL 就能起到事半功倍的效果。除了降低 SQL 的CPU逻辑读，还有个经验是提前梳理数据库中不用的大表。有很多还是备份表（带日期或名字）。有些表是历史数据可以归档。清理这些表可以极大的降低数据迁移的成本。 这里就衍生出一个有新的话题，责任心问题。这类事情可做可不做，做了还不省心可能还惹来问题。做这样的事情就需要极高的判断能力和责任心。这也是数据库转型项目成功的必要条件之一，只不过书里并没有强调这点。《数据库转型》中诸如此类经验都是很实在的，这也是这本书值得推荐的第四个理由。
如今的技术行业非常的卷。自媒体很多，各种文章、视频分享很多，接收这样的信息就像吃快餐一样，一时满足，长久看又没留下有益的。《数据库转型》用文字的方式介绍金融行业数据库转型的挑战，解决思路，以及介绍了OceanBase 的架构原理、部署和开发设计经验。虽然 OceanBase 技术迭代也很快，书中的技术观点大部分都不会变。留着这样一本书放在案前，时不时翻一翻，可以有助于自己思考解决自身类似业务问题。对于 OceanBase 初学者而言，这本书就是一个直接呈现一个 OceanBase 数据库专家在工作中如何思考业务和数据库问题的指导书。这也是这本书值得推荐的第五个理由。
我与林春老师初次相遇是很多年前在银行做 OceanBase 交流时认识。林春老师很忙，当时在食堂里咨询很多OceanBase 技术问题。因为很少有客户能问的这么深，所以林老师就给我留下深刻印象。再见林老师已经是若干年后 OceanBase 的 OCEC 专家交流会上。此时林老师已经带领太保完成 OceanBase 数据库转型并对外分享转型经验。林老师对 ORACLE 和 OceanBase 数据库都很了解，并且非常热心的解答其他同行的疑问。林春老师既懂 OceanBase 数据库，又能说善写，最重要的还很热心，这也是这本书值得推荐的最后一个理由。
最后附上书籍链接：
其他参考：
