最近，赛迪顾问发布了一份《关键业务系统数据库升级实践指南》，引起了潭主的兴趣。
不由想起了之前写的科技观察，《信创数据库，只有第一！没有第二？》。
文章主要谈及了潭主对分布式数据库市场和选型的看法，但并没过多谈论技术。
本期，潭主写个续，聊聊信创数据库的技术架构。
前情回顾与信创展望
7月，IDC发布了《中国金融行业分布式事务型数据库市场份额，2023》。
潭主根据报告得出：主流数据库厂商的市场份额无显著差距，产品都可用。
IT分析师们倒是很乐观，认为以银行为代表的金融行业已经基本完成技术验证，可以快速复制标杆案例成功经验，迎接高增长。
可能是受限于自身原因，潭主对此持保留意见。
信创已持续推进几年，行业用户都在积极落实信创要求，作为金融排头兵的银行业更是遍地开花，硕果累累。
但信创的根本目的是实现关键领域、重点行业的自主可控。
所以，不是简单花了多少钱，买了多少信创设备，也不是外围系统的信创适配，而是关键核心系统的全栈信创改造。
相信未来还会有进一步的政策出台，深化推进核心信创。
唯有如此，才能真正攻坚克难，最终实现信创。
保险行业信创标兵
以潭主所在的保险行业为例，看看头部险企的信创成果。
中国人寿：业内规模最大核心系统全面升级
不愧是中字头险企，信创一马当先，态度坚决，以“百团大战”之势用时一年即实现核心系统全量信创迁移。
百库”闪电战“的成功得益于OceanBase和达梦都是行业里对Oracle兼容做的最好的产品，直接降低了客户应用改造的工作量和难度。
中国太保：业内首个全险种核心系统升级
完成了80多个应用系统的全栈信创改造，场景覆盖承保、理赔、保全、再保等各业务环节。
太保采用了OLTP和HTAP OceanBase集群隔离部署的策略，并实施了无损容灾和异地多活。
从公开资料看，国寿和太保的案例都是以系统平滑迁移为主。
关键业务升级路径
赛迪报告显示：现阶段行业关键业务系统升级以平滑迁移为主，即我们常说的平切换库，前述的两家险企都选用OceanBase平替Oracle。
如上图所示，用户升级需求主要集中在Oracle、DB2和MySQL。
OceanBase在兼容性和升级路线上综合得分最高；达梦排名第二，对Oracle兼容性最好。
这也是潭主选择参加达梦和OceanBase技术认证的原因。
此外，PingCAP得分也不错，但TiDB对MySQL的支持竟只有4分，有点小意外。
值得一提的是，很多产品对DB2的支持都不怎么样，这应该是银行DB2核心系统选择应用整体分布式重构的重要因素。
关键业务系统升级路线对比
此次赛迪的报告并没有局限于集中式或分布式，将信创数据库升级改造分为三条路线：
集中式数据库架构
基于中间件的类分库分表的分布式数据库架构
原生分布式数据库架构
集中式架构，主要对标Oracle，顶配也就是Oracle RAC+ADG（OGG）的模式。
优势是架构经验可复用，运维难度低，性价比适中。
鉴于目前信创硬件以及国产数据库在类RAC架构上还需完善，目前的主流其实是主从复制架构，且在高端场景，信创架构还存在可用性、可扩展性的挑战。
接下来，再说说分布式数据库的两派内斗。
一派是以TDSQL和GoldenDB为代表的，基于分库分表和中间件的分布式架构。
该架构将数据做分片，专业叫Sharding，每个分片（小库）是一个独立的一主两从或多从架构。
业务请求经过数据库中间件解析和路由分发到不同的数据分片，实现分布式功能，并通过GTM保证事务全局一致性。
其实，潭主更喜欢称这种多分片叫分形架构，本质上是小库主从架构的组合式创新。
虽然可以横向扩展，但缺点是对应用有一定的侵入性，且跨数据分片的事务访问性能较差。
另一派则是以OceanBase和TiDB为代表的原生分布式架构。
原生分布式架构跟云架构有点类似，也有Region和Zone的概念。
该架构数据基于Paxos和Raft一致性组和多数派实现多副本的高可用性。
相较于分库分表架构，原生分布式架构对应用透明，应用可以像访问集中式据库一样使用分布式，简化了应用开发和维护成本。
潭主也认为原生分布式架构才是关键业务系统升级的最优路线。
不过，不同用户诉求不同，技术最优的并不一定是最适合的。
分布式数据库，架构定胜负
潭主过往运维过Oracle和DB2，在数据库高可用、容灾架构上也实战多年。
以潭主的经验看，分布式数据库架构还是原生的OceanBase更胜一筹。
总结几个OceanBase的卖点：
首先是多租户架构：行业客户的核心和关键系统基本是商业数据库，但也累积了不少散装的MySQL，而OB的MySQL和Oracle多租户能力，既可以实现高端一对一，也可以实现散装多对一的整合。
对于高端核心，借助多租户配合单元化分而治之，另一方面，多租户整合了MySQL和低端，可借助集群统一进行架构管理。
其次是高可用性和容灾架构：OceanBase在V4版本推出了新的仲裁方案，相比传统的多副本方案增添了新选项，有助于分布式降本增效。
如果说分布式比集中式好在哪儿，潭主觉得其“两地三中心”的业务连续性能力比传统方案有了进一步的增强，而且是集群规模式增强。
在Oracle平滑迁移这事上，不要听厂商忽悠说兼容做的好，要实测。
兼容这事绝对是谁做的时间长，做的项目多，谁的经验多，兼容性自然做得更好。
当年，谁先拉条幅喊去IOE来着。
兼容性高意味着工作量少，省去了很多隐性成本。
另外，潭主之前测分布式对DB2的兼容性，OceanBase的结果是尚可，但遥遥领先的UGO却中看不中用。
最后，除了架构，兼容性、性能外，OceanBase的存储设计也有利于提升数据压缩效率，节约存储空间。
其实，上述特性可能厂商的产品都有，但是有和优不一样。
以多租户为例，GaussDB的多租户其实是逻辑集群，很难满足数据库整合和提升资源利用率的需求。
写在最后
当年O记一家独大，数据库不存在选型问题，系统架构标准化程度高，参考Best Practice即可。
现阶段，除了集中式和分布式架构之外，还要在厂商中间做权衡。
信创数据库百花齐放，既要关注厂商的产品研发能力，代码自主可控，还要关注其产业背景和行业经验，选型相对变得复杂。
信创选型最重要的是明确企业自身需求，了解自身的技术和资源禀赋，再结合技术架构做选型。
在潭主看来，核心信创改造既是技术改造，也是业务改造，有时候解决问题并不一定完全靠产品技术。
同样，信创改造也不是一锤子买卖，也需要长期主义。
总之，信创不仅要搞好计划生育，更要重视优生优育。
现在，是不是有些认同了潭主的看法，分布式数据库，原生的比亲生的更重要！
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
推荐阅读
