金融行业作为数据使用的“高地”，长期以来非常重视数据技术的发展。银行业作为金融业的重要组成部分，致力于构建稳健的数据基础设施。数据库作为数据的主要载体，在其中扮演着非常重要的角色。近年来，随着以分布式、云原生、多模异构为代表的新型数据库产品不断涌现，银行业正在经历新一轮的技术迭代更新周期。但是，由于银行业务系统非常复杂，很难找到一款覆盖所有业务场景的“完美”产品。如何根据金融业务场景找到最合适的数据库成为金融从业者需要面对的问题。本文试图结合银行业的特点，从业务特点、技术特点、技术路线等角度来阐述如何解决这个问题。一、银行业务场景分析银行业务非常复杂。在一个中型银行，会有成百上千个业务系统。这些系统可以根据其业务特征进行分类，不同分类的业务系统具有不同的用户、访问特征、可用性等，甚至对底层基础设施的要求也不同。下面针对业务系统本身做一个简单的分类。2、业务场景技术特征分析1）业务应用分类银行业务非常复杂。在一个中型银行，会有成百上千个业务系统。下面从业务应用的角度对系统进行简单的分类。精简系统精简系统实现实时支付、证券交易、订单等业务的发起方与接收方之间的转账功能。典型的流线型系统有银行渠道系统、转账清算系统和非银行支付机构。支付（协议支付）系统等。对于此类系统，业务请求和业务请求响应需要实时转发给业务发起方和业务接收方，对系统的实时性要求很高，但是关键数据（如交易涉及的账户数据）的一致性由业务发起方和接收方保证，流式系统记录业务的流转信息。流水线系统的幂等处理是架构设计的重点和难点，可以采用多层幂等保障机制，如用户发起业务流量链路的幂等性、实时业务的幂等性处理环节，以及交易对账环节的幂等性。基于账户的系统基于账户的系统主要实现对账户信息、用户信息等业务数据的处理和记录。此类系统需要优先保证关键数据的一致性。当发生灾难或故障时，应在实现关键数据一致性的前提下实现业务可用性。账本系统的数据一致性是架构设计的重点和难点。应结合业务模型选择方案，如关键数据同步复制、只读数据与可写数据分离、业务处理层与数据存储层协调等。工作等计算系统计算系统实现与清算清算、风险控制、商户结算等相关的计算，也包括与金融领域的科学、工程、数据分析、音视频处理等相关的各种计算。这类系统对输入的业务进行计算，并将结果输出给其他系统。计算过程所需的所有数据均来自单个计算业务请求或外部系统。此类系统专注于确保计算应用程序的可用性和准确性。采用多主动技术的计算系统，可以实现多点计算，多点输出结果。这样，多个子信息系统的输出结果可以相互校验，提高准确性，并且当一些多活子信息系统发生灾难或故障时，其他多活子信息系统的计算结果系统可以直接使用。为用户提供各类用户信息、交易记录、成交价格、订单记录、发布信息等相关查询。这类系统中的查询应用不会修改系统中存储的数据（或者查询业务流量比有数据写入和修改业务流量的系统大很多），数据主要由外部系统导入。这类系统着重于保证查询应用的可用性，以及查询数据的多副本存储和多副本查询数据之间的一致性，从而保证各多活子系统的查询结果是相同的。采用多主动技术的查询系统可以实现多点查询。查询流量可以在多个子信息系统之间共享，当一些多活子信息系统发生灾难或故障时，可以通过其他多活子信息系统查询信息。典型场景介绍日间在线业务（OLTP）专注于银行核心业务，包括客户账户查询、存取款/汇款/贷款业务、小额支付业务、收付款批处理场景等。该类场景是特点是业务时效性要求高，不同业务类型混合SQL请求，事务一致性强，小事务并发高。日终批处理业务（OLTP+OLAP），如计息结息、总分查询、记账、贷款余额查询等时效性要求不高的业务。业务时效性要求比较低，SQL是批量提交的，单位时间内对单个数据表的读写量大，大事务高并发。在处理方面，首先需要做分布式处理，然后是分布式聚合处理和查询，最后根据系统测量量和现有数据量的大小，批量提交事务。2）场景技术分类基于以上不同的需求，从技术角度按照业务场景进行分类。可以根据以下几个维度来区分。其中，重点从数据规模、事务一致性、负载特性、数据分析能力、应用适配能力等方面进行对比，并给出建议架构。3）技术指标分类上述场景比较抽象，可以从场景的技术指标角度进行分类。以下适配系统仅供参考，具体视业务系统特点而定。如图3分布式技术方案推荐近年来，分布式数据库非常活跃，很多银行也在选择分布式数据库或者已经采用了分布式数据库。分布式数据库的实现方式有很多种，主要有以下几种。1）分布式技术路线分布式中间件+单机数据库产品一般采用典型的“ShareNothing”架构，将存储与计算分离，通过上层的无状态计算节点提供弹性可伸缩的计算能力。通过增强单机数据库，提供基础存储能力和本地计算能力。该架构可以通过硬件堆叠提供近似线性的计算性能和存储容量，具备支持超大规模集群的能力。原生分布式数据库等产品普遍采用“ShareNothing”架构，存储和计算分离。与上面不同的是，底层多采用自研或裸存储引擎，数据按规则打散多份存储，通过paoxs等分布式协议保证多份之间的数据一致性/筏。上层实现了基于数据库的优化器、执行器等组件，更彻底地支持分布式事务和全局MVCC。另外，由于其底层存储引擎不依赖于某个产品，可以根据需要组织数据，所以在适配场景上更有优势，比如在一些分析场景下可以选择列存储。某种程度上，云原生数据库也是分布式的，但与前两者不同的是，它们不是ShareNothing架构，而是ShareEverything模型。它的底层是分布式云存储，本质上还是中心化的架构。上层计算部分由一组无状态节点组成。之所以没有架构，是因为这种方式需要对base有比较重的依赖，除非把整个底层都换掉，否则无法部署在金融行业相对独立的环境中。因此，在使用选择上存在一定的困难。2）分库分表类推荐场景下面针对第一种架构，即“分布式中间件+单机数据库”，结合场景和技术描述本架构适用场景的技术特点上面提到的特征。在这里说明一下，这类产品的进化速度非常快，功能也在不断增强。以下观点仅代表个人观点，不代表所有产品能力。
