韩锋
中国计算机协会 常务理事，前 Oracle ACE
CCIA（中国计算机协会）常务理事；前 Oracle ACE，腾讯 TVP，阿里云 MVP，dbaplus 等多家社群联合创始人或专家团成员。有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席 DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富。曾著有数据库相关著作《SQL 优化最佳实践》、《数据库高效优化》。《韩锋频道》公众号作者
近年来，分布式数据库在金融领域的应用愈加广泛。在数字化转型的背景下，分布式数据库往往是金融企业核心场景进行架构转型的重要着力点。随着市场关注度增高，可用于金融行业的数据库产品也越来越多，如何选型就是摆在企业面前的一大挑战。中国计算机协会常务理事，前 Oracle ACE 韩锋带来了主题为《金融业数据库选型之路》的分享，就上述主题带来了颇具价值的见解和参考。
行业及技术背景
目前的整个数据库行业中，数据库产品呈现碎片化特点。
一方面，数据的使用场景越来越多元，如关系型、分析型等使用场景，基于文档、基于 KV 等数据模型。这是因为企业数字化转型后对于数据的重视程度越来越高，同时数据参与到企业生产经营领域中也越来越深入，企业对数据更加重视等因素。不同场景需要有对应的不同产品来解决问题。不同产品的技术路线也不太一样。同样场景的产品需求，对应的技术路线也大有不同。这样的背景下，企业选择数据库的痛点就是如何在纷纭复杂的架构体系下，选择一款适合自己的数据库产品。
另一方面，数据库开源已经成为大势所趋。从近 10 年全球数据库流行趋势来看，开源数据库在 2021 年的流行度已经超过了商业数据库，全球越来越多的用户更关注开源数据库产品。国内也有越来越多的国产数据库厂商的产品纷纷走向开源路线。
为什么现在大家这么重视开源？因为数据库作为基础性的软件，技术门槛是比较高的。开源大大降低了数据库使用门槛，同时使更多用户可以参与到开源生态中，来更好地磨合产品、打磨场景、提出更多需求。开源为数据库的发展带来了非常大的助力。特别在国内，开源可以大大加速国产数据库的普及与使用。
从公司角度来讲，从早期的架构选型到中期的开发部署，再到后期的运营维护，开源与商业方案都有一些非常明显的差异。企业要选择开源产品需要重点关注、评估这些内容。
如今数据库厂商非常多，在国内就分为传统厂商、初创厂商、云厂商和跨界厂商几类，国外则主要分为商业数据库和开源数据库两大类。有来自这么多厂商的产品可供企业选择，也让企业面临很大的困难。
从政策背景来看，国家高层已经有了非常明确的关于金融科技的发展规划。《金融科技（FinTech）发展规划（2019-2021）》中明确指出要加强数据库，特别是分布式数据库的应用研发，做好长期规划。规划要求金融企业在内部稳妥地推进分布式数据库产品的使用，确保能够平稳达成目标。
分布式数据库并不是非常新的概念，只不过最近 3-5 年我们看到分布式数据库领域的发展非常迅速，越来越多的分布式产品踊跃而出。近两年，也有越来越多的金融企业考虑在内部系统采用分布式数据库产品。
金融业落地难点
企业选择分布式数据库前需要思考几点问题：
● 基础功能待完善。数据库是非常复杂的工程化软件，分布式数据库有一些突出的亮点，但同时也存在一些先天缺陷与不足。这需要使用者在架构设计阶段就充分地关注到这一点，提取它的精华部分来规划设计系统。目前大多数国产数据库产品的基本内核能力已经相对完善，但在周边生态工具、管理工具优化方面还有较大加强空间。所以企业选型的时候就要充分考虑这一点，哪些功能较之前有所退化，要有明确的认识。我们要从更多角度考察产品，关注到方方面面。
● 运行稳定性待验证。对于金融企业，稳定性是第一位。分布式架构在解决稳定性问题时有自己的优势，但也有一些要求，比如说比较重度依赖基础设施的能力。从使用者角度来讲，持续稳定性需要长时间不断打磨，是持续改进的过程，不可避免会出现一些问题，需要厂商的产品在金融环境里经历这样的过程，不断完善产品。
● 迁移改造任务重。无论选择分布式产品还是集中式产品，企业都存在迁移改造的过程。这里面涉及到大量工作。很多数据库厂商看到了这一点，会通过提升产品能力尽量地贴近成熟的产品生态。但我们也要看到两个数据库产品不可能完全兼容，势必会有一些差异，这些差异我们要明确。另一方面，如果是从单机架构迁到分布式架构，架构本身也带来了一定的挑战，涉及到迁移前后的变化，这也是需要在选型之初要考虑的。
● 风险巨大需并行。风险问题一方面是来自于新产品带来的风险，另一方面在于迁移本身所造成的一定不确定性，以及软件本身的基本能力可能有一些隐患。金融机构有一些对应的措施，比如说应用双发等方式可以有效降低风险，当然这也需要相当大的成本投入。
● 生态环境需培育。国内数据库产品生态建设普遍比较晚，跟国外相比较为落后，需要通过积累和方方面面的努力来提升和加速。
● 信创要求时间紧。国家对金融企业的信创执行要求存在时间点的挑战，往往时间比较紧，也需要企业尽早地考虑。
金融业落地方法
具体到选型阶段，首先从场景角度来看，金融企业有非常多的场景。选型的产品是不是适用于这些场景？需要我们有非常清晰的认识。企业要从业务、数据规模、一致性要求、负载特点、分析能力等对数据库使用场景做划分。以简单的数据分片为例，很多数据库产品对于数据分片功能的支持程度是不一样的，有很多差异，这些差异需要企业用户在选型之初有充分的了解。
分布式数据库选型要关注的要点是比较多的。我们要关注用户体验、批处理、可扩展性、可维护性等维度，再通过可量化的指标做评估。这就要求我们具备具体的评估评测标准。涉及到的评测细节会非常多，不同的企业可能都有内部的评测标准。
由上图可见，我们对分布式数据库的考察细节非常多。针对每一个点都有对应的测试内容，需要厂商的产品支持这个内容、设计对应的场景、满足测试的细节。业务评测可能是另外一套标准，可以选择企业内部有代表性的业务，抽象化之后结合具体产品进行带业务的测试，这对我们来说也非常有参考意义。
下面针对当前分布式数据库的主流技术架构做一些简单的对比。
首先是分布式中间件+单机数据库模式。这种模式来自于互联网，实现了典型的存算分离架构，上层提供了弹性可计算层，底层利用单机数据库提供存储与单机计算能力。它的优势很明显，由于其功能集成于底层的单机数据库能力之上，所以产品功能比较丰富，可以做到大量定制化。它的总体稳定性比较高，主要取决于底层单机数据库。因为上层无状态，主要依赖于底层 DB 状态，它适合于对数据分片的逻辑更加关注，想做到定义化，充分利用自己的要求，把数据充分打散这样的场景。它的劣势也比较明显，因为是基于单机数据库之上构建的分布式数据库产品，所以全局事务等能力会存在一些先天的短板，需要厂商持续补强。这样的架构适合在某些超大规模、延时性非常高的场景使用。
接下来是原生分布式数据库。它通过副本协议保持一致性，上层实现基本的数据库能力，对于分布式能力封装更加完善。从底层到上层，它是完全按照分布式架构设计的产品。它的优势也非常明显，上一种架构天然短板带来的问题，在这里可以得到很好的解决。但劣势也比较明显，因为它是比较新的产品，产品的成熟度、稳定性需要积累。
还有一些是企业通过自研的方式，结合开源单机数据库开发的产品。其优势有风险小、灵活定制、对底层依赖小等，劣势则是成本和效率较低等。
具体选型时，企业可以分析各个架构的优劣势、适用场景，通过数据库标准化、轻量化工作形成内部的统一选型标准。也就是说我们要分清楚不同的场景，再去选择一款产品，而不是选择一款来适配所有的场景。不同架构的产品有自己的优势和劣势，很难完全避免。
在实践中，金融企业选择分布式数据库有几点可以参考：
1. 尊重路线之争，无关技术领先性。不同数据库产品有自己适应的场景，与它的领先性是没有关系的。我们更多需要结合业务选型。未来行业还是会出现多技术路线长期并存的状况。
2. 成熟度有待完善，但时不我待提前规划。分布式数据库的成熟度有待完善，但我们不能等待，需要帮助企业不断地打磨产品才能越用越好。所以我们要提前做好这样的规划。
3. 国产数据库百花齐放，机会无限。对企业来说我们的选择面更大了，换句话说我们也要具备非常清晰的入门标准，严格地考察这些产品，把真正有实力、质量好的产品引进进来。
4. 谨慎技术选型，不迷信宣传。我们要尽量依靠自己，而不是依靠宣传材料。有时候仅仅通过一段文字描述，很难对产品有非常全面与准确的了解，需要在自己的环境当中真正测试过才更具有说服力。
5. 结合场景需求，没有最好只有最适合。我们只有对自己的场景有了充分的了解之后，才能选择一款最合适的，而不是选一个所谓最好的产品，这是我们选型的基本出发点。
6. 不选产品选兼容性，保持最大自由度。我们不是选择一个产品，而是选择一个标准，选择尽量兼用某个通用协议的产品，这样相对自由度很大。我们尽量把底层数据库差异磨平，为后续数据库更换保持最大的自由度。
7. 保持技术敏感度，紧跟时代发展步伐。数据库是发展比较快速的产品，在不断演进变化当中。对于金融企业用户，我们要时刻关注技术发展，保持足够的技术敏感度，不断结合金融业务特点紧跟技术发展趋势。具体措施上可以采取架构前置、谨慎选型、局部试点、多线布局、掌握主动、自建增强来做相应的工作。
