银行分布式数据库选型分析

银行走向分布式是科技发展的必然趋势。具体的原因有以下几点：

随着数据处理对数据类型、数据规模、计算速度等的要求越来越严苛。传统数据库的运用到达了瓶颈，不足以满足计算的需求。而分布式数据库打破了传统计算场景的瓶颈，实现了当前数据处理的需求。

数据库作为一款基础软件，稳定性和可靠性是它的立身之本。而金融业，尤其是银行业对数据稳定性的要求最为严苛。分布式数据库通过提供高稳定性、高可靠性、低成本的数据存储处理方案满足了金融业的这点需求。这或将成为未来金融业发展中必不可少的技术基础。

银行的核心业务系统正从传统的集中式结构逐步向服务化、分布式这样的体系演进。不同规模的银行机构都启动了对于核心的改造工作，引入适合自己体系的分布式技术来支撑他们的业务发展。例如交通银行与华东师范和西北工业大学共同研发分布式数据库CBase,中信银行与中兴通讯研发了GoldenDB,光大银行在云缴费系统中使用自研的EverDB分布式数据库，北京银行在网联支付系统和网贷系统中应用了TiDB。以上案例体现了数据库方案的不同金融场景的细化。根据需求选择适合自己的数据库解决方案。

《金融科技（FinTech）发展规划（2019-2021）》中明确指出：“加强分布式数据库的研发应用。做好分布式数据库金融应用的长期规划，加大研发与应用投入力度。有计划、分步骤稳妥推动分布式数据产品先行先试，形成可借鉴、能推广的典型案例和解决方案，为分布式数据库在金融领域的全面应用探明路径。建立健全产学结合、校企协同的人才培养机制，持续加强分布式数据库底层和前沿技术研究，制定分布式数据库金融应用标准规范，从技术架构、安全防护、灾难恢复等方面明确管理要求，确保分布式数据库在金融领域的稳妥应用。”在政策指导下，银行走向分布式数据库已经成为必然。

简单地把局部最优的选择拼凑在一起未必是全局最优的方案。如果目标是对整个应用系统做彻底重构，那么要解决原来某些局部的问题，可能会有更多选择。这时候要从整体上来评估技术的复杂度和工程实施等为题，而不能只是选择局部最优的方案。

最先进的产品不一定是最完美的选择。尤其是对进度有要求时，我们往往要选择相对稳妥相对快速的办法。可能不是最优选择，但对当前目标来说，确是最合适的。

当选择一款产品时，导致了业务流程的变更，对于任何项目来说，实施难度都会增加。而通过一定的技术手段来避免这种变更往往是更好的选择。

跟随潮流并不是人云亦云，必须能够独立对技术发展趋势做出判断。比如：太过小众的技术往往不能与工程化要求兼容。但也必须要保持对新技术的敏感度和掌控力。

这种产品采用典型的“Share Nothing”架构，实现存储与计算分离，上层通过无状态的计算节点提供弹性可扩展的计算能力，下层通过增强单机数据库提供基础存储能力及本地算力。这一架构通过硬件堆叠，可近似线性地提供计算性能和存储容量，具有可支持超大规模集群的能力。

这类产品采用的也是“Share Nothing”架构，实现存储与计算分离。与上面不同的是，底层多采用自研或裸存储引擎，数据按规则打散并存储多个副本，通过paoxs/raft等分布式协议保证多个副本间数据一致。上层实现数据库基础的优化器、执行器等组件，对分布式事务、全局MVCC等支持更为彻底。此外，由于其底层的存储引擎不是依赖某一产品，可根据需要组织数据，因此在适配场景上更有优势。

在某种程度上，云原生数据库也是一种分布式，但与前两者区别是不是Share Nothing架构，而是Share Everything模式。其底层是与分布式云存储，本质上来说仍然是一种集中式架构。上层的计算部分，是无状态的一组结点组成。这种方式是需要对底座有比较重的依赖，无法在金融行业相对要求独立环境中部署，除非整个底层都更换。

这一模式是在传统单机数据库的基础上，通过业务自研完成数据拆分。在处理上，尽量通过业务单元化方式，将数据集中在单元内完成；即使极少数需要跨单元，也可以通过应用层面解决事务类问题。

银行在分布式数据库上到底要如何选型，选型应用中面临着以下几个难点：

一、复杂业务逻辑问题

包括数据库技术基因匹配性（如：数据库本身锁机制、隔离级别问题），包括技术兼任性（如存储过程、视图兼容性）。

二、应用的适配度问题

银行应用大部分都是基于单机关系型数据库机制设计的，例如大部分场景都是串行机制，发挥不出来分布式数据库的强大并发处理技术，反而分布式数据库本身的二阶段提交机制，对简单事务的延时增加问题，造成串行事务执行性能低下。

三、人员能力的匹配性

需要根据人员技术能力进行选型考虑，既要考虑现有人员对数据库技术的了解程度，又要关注数据库技术本身的开放度和社区热度，让人员可以很快地学习和提升数据库技术能力。

四、数据库自身能力问题

包括在分布式事务、数据一致性、高可用容灾等，相较于传统集中式数据库还存在不足；此外金融业在联机交易的低延迟要求、跑批类的高吞吐要求也对分布式数据库提出了更高的要求。

五、数据库运营维护问题

包括是否具备足够能力维护分布式数据库，是否能够接受数据库转型期间的业务中断时间，是否具备迁移（甚至在线迁移）能力，是否具有应用级双发能力，是都能够规避可能出现的风险能力等。

技术是为业务服务的，需要综合考虑成本和收益之间的平衡。分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其独特的优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本等。此外，在做出上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。

分布式数据库不依赖于特有硬件，标准X86服务器或者国产化服务器即可，存储多为本地存储即可，推荐使用SSD甚至是NVMe SSD，网络一般万兆网络即可。这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件投入及主备间的专线费用。

这部分是分布式数据库本身的软件成本，取决于各厂商的内部商业策略。但这部分总体来讲，较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新企业自有能力尚不具备的，建议购买原厂服务或其他三方公司的服务来降低风险。

这部分是数据库更换后，应用需要完成的必要的开发测试成本。这部分成本的差异很大。如果原有系统重度依赖数据库，那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，建议应用开发遵循数据库标准方式进行，这样如有改型也简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，需要考虑双发支持或灰度迁移的方式，这会带来一部分工作量。总体来说，这部分成本可能占整体成本的大部分。

这部分成本，包括为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决或者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的投入，且整体成本不少。

采用不同的技术路线，针对上述的成本投入是存在较大差异的。所以需要根据项目的需要慎重选择，选出最适合的。