大咖论道｜银行核心系统国产分布式数据库选型思考
写在开头：
关于国产数据库的选择，以下为我在多年工作中的思考、认知和积累，还不太成熟，谨供有共同兴趣的同学参考，同时热烈欢迎讨论和质疑，谢谢大家！
作者｜陈书华
内容｜本篇共3096字，预计阅读时间9分钟
首先，回答一个问题：
有没有一个最好的国产数据库产品，适合所有银行的核心业务系统？
我给出的结论是：
没有。
我这么说，可能有点粗线条，不严谨。换一个说法，包打天下，适合所有银行的国产数据库产品，没有。但，不同的银行，业务规模不同，银行自身DBA团队大小、知识积累不同，选择能适合银行实际使用的国产数据库产品还是有可能的。
可能的点，在哪些方面呢？我认为可以分四个维度来看、来评测：
产品成熟度、技术路线、数据库性能、运维能力。
为了扣题，这四个维度就不在本文逐项解析了，以后有机会再分别写几篇文字，和大家分享。我想表达的是，希望选择这四个维度都优秀，希望选择一款和Db2、Oracle能够比肩的国产数据库，目前基本上是不太现实的。别急，话还没有说完，此处应加上——“但前景是光明的”。
二十多年前，我曾经在当时比较知名的技术论坛网站担任过一段时间的Db2版主。Db2从大机下移到AIX开放系统后，首期应用到国内银行的v4.0适配，美国IBM实验室的同学在现场修改Db2源代码、我们核心系统同时进行测试，再修改、再测试……也并不容易。看我们当前国产数据库选型测试，也是同样的，厂商参加测试的工程师，都会派专家根据测试需求，边修改边测试，情景是如此相似。我相信，在银行方、数据库厂商、核心应用厂商共同努力下，过些年定会磨砺出与Db2、Oracle比肩的国产分布式数据库产品。
国产分布式数据库的选型，对银行技术路线来讲，大家都有共识——是至关重要的。我也常常“危言耸听”：一旦选错，十年二十年翻身都会很困难。为了规避这个问题，在选型中，可以提前参考一些因素。
选型中，要考虑哪些因素呢？我按照个人有限的认知，尝试着总结了以下几个要点，供同学们一起探讨、拍砖。
一、选择一家与银行有战略合作的数据库厂商
所谓“有战略合作”是指和银行是共同合作的，而不是单纯的、产品和服务的商业购买。这一点，我觉得很重要，所以放在第一点，因为国产数据库当前状况基本都是“可用不好用”的状态。这方面的例子，中信银行与GoldenDB的合作共研、邮储银行与GaussDB的合作共研、贵阳银行等与QianBase的升级打造，都是成功的典范。
二、核心系统的应用厂商选择，也建议从战略合作的角度考虑
当前的核心系统建设，和十年二十年前已大不相同。以前，选择一家产品成熟度好、国内外银行先进业务经历得多的核心系统厂商，就可以了，底层IOE都是成熟的。而现在，我国银行业已经今非昔比，在银行业务丰富度、客户体验度、支付便捷度、技术架构先进程度等方面，已经领先国外绝大多数银行；技术研究、人员能力、经验沉淀、业务知识，银行科技部门整体上也要优于供应商。只是在专项领域，需要与有追求、有研究、有综合实力的应用厂商战略合作，共同研究，来协助银行核心系统建设更精准、更安全、更高效、更合理。
通过POC选定某家应用厂商的产品，可以完美匹配银行实际投产的可能性并不高。虽然应用厂商会提供针对产品的培训和知识转移，但要完全消化这些知识，并在短期内完全掌握产品优缺点，这是一件有相当难度的事情。
举个例子，银行现有核心系统，已经经历了十年左右的维护优化。这些优化，除了一部分因业务需求的功能而增加，大部分是各种控制、各种流程调整，十年左右的控制优化和流程优化，在短短18-20多个月的新核心建设期间，都增补到POC来的产品里，也不大现实。因此，需要选择一家有战略合作的厂商，建设一个变更快速、调整更敏捷的核心系统产品，可以把原来一两周的升级窗口缩短到三五天，更符合银行的实际需要。
此外，底层的适配、调优也是一个长期的过程，与银行进行战略合作的数据库厂商会持续优化，核心系统也就需要伴随着进行持续优化。
过去因为Oracle、Db2的可靠可用性良好，应用系统可以承担的部分，也让数据库承担了很多。如今，例如触发器、存储过程、自定义函数、序列号等等，可以尽量从应用系统层面来实现，把数据库限定在ANSI SQL92这个通用标准范围。
把数据库功能限定尽量小些，避免使用数据库的特定功能、特定语法。这样国产数据库的选择范围也扩大了不少，银行投产使用的风险也减少很多，而这一目的也需要通过核心系统应用厂商和银行科技部门的密切合作、共同努力来实现。
三、国产分布式数据库
一方面，看数据库厂商本身的公司规模、研究队伍实力、战略定力。数据库和芯片、操作系统一起，被并称为“IT皇冠上的明珠”。对于国内研发数据库的公司，无论套壳还是从底层研发，无论是十几人的小作坊还是三百五百初具规模的公司，我对他们都是无比尊敬和佩服的，也不会对他们泼冷水、砸砖头。
目前，国内数据库厂商正处于百花齐放、人员分散的创业初期，相信在银行行业扶持下，将很快进入高速发展阶段，涌现出很多战略坚定的公司，而不是三心二意、路线摇摆。这方面的信息，您可以参考工信部国产数据库行业发展趋势分析和墨天轮等网站，俺就不对这些公司进行点评了。
另一方面，我们也需要深入了解数据库的技术架构，深入了解数据库的特点。尤为重要的是，要尝试深入了解数据库的实际缺点，在核心应用角度形成开发规范，规避或换个方式来实现。硬逼数据库厂商做不可为而为之事，按下葫芦浮起瓢，反而会产生次生灾害。
而深入了解国产数据库存在的缺点，事实上这一点是很难做到的，因为没有战略合作关系，没有一个数据库厂商会十分清晰的把自己的缺点摆在明处，以求共同提升；作为友商和核心系统使用厂商，一般也只会比较含蓄地提出竞品和合作厂商的差距。
四、选型测试
具体到选型测试，需要详细参考工信部、人民银行颁布的国产分布式数据库规范。规范是由官方机构集合业界知名同业和产品厂商、应用厂商共同经验形成的宝贵结晶，站在巨人的肩膀上能少走许多弯路。例如，国标15387.1-2014、17532-2005、25069-2010、30994-2014、32633-2016、20273-2019、20009-2019，人民银行颁布的行标JR/T 0203-2020、JR/T 0204-2020、JR/T 0205-2020，这些都是可以从公开渠道获取的。还有金融信息技术创新生态实验室我司鼎力参与贡献的一些数据库测试规范，也是很好的参考标准。
五、鱼与熊掌不能兼得
前面我已经表述过，没有一种数据库是完美的，我们应专注关心它是否适合核心系统特点、适合银行的业务场景，适合就大胆地去用吧。只有大规模使用了，才能在它上面积累足够的应用开发、运维、优化方面的经验，这些才是对银行最为关键的。
例如，核心系统应用是分布式微服务架构的，是云原生体系的，是Java技术路线的，去关注它与Oracle的兼容度，去关注它是否具备静态动态嵌入式SQL的编译能力，就没有必要。
每家的数据库产品，架构都各有特点。前面说过，需要深入分析了解数据库的架构，但目标不明确地去分析，价值也不大。纯粹的技术研究对银行核心系统的数据库选型并无太大的帮助。
在分析、深入了解数据库架构的时候，需要从核心系统的特点出发，明确需要从分布式数据库中获得什么样的能力，从而进行相关选型比较。
例如，以高可用为目的选型，就不要再得寸进尺、得陇望蜀地把在线可扩展能力、分布式事务极致性能作为主要选型指标。以异地多活为目的选型，就无法奢望线路成本又低、RPO也为零。
再例如，各家HTAP数据库厂商都说，它既适合交易型数据库又适合分析型数据库，我可以偏激地说，对于我们银行的关键业务系统，不能作此奢望，因为浓眉大眼的Oracle数据库，也不灵呢。
最后，回答很多同学问我的，大家都关心的分布式数据库选型，同业都有哪些关注，趟了哪些坑。
简而言之，都是痛苦而艰难的。
选择一家有追求的、诚实的、愿意投入的厂商，同时银行也愿意对它重点扶持，对于当前为了“活下去”而不得不追求短期利益的营商环境，这个是可遇不可求的，不容易！