透析商业银行在云时代下的数据库需求与选型

作者介绍

洪烨 ， 多年银行业系统架构设计及DBA实战经验，2013年出版数据库书籍《DB2数据库内部解析与性能调优》。

伴随着云计算、分布式技术的逐步落地，近十年来数据库的形态也发生了很大变化，各类数据库如雨后春笋般不断涌现。 从架构形态和应用功能的角度来区分，本文将这些新兴的数据库分为三类：分布式、NoSQL及云原生数据库。

过去关系型数据库滥用的时代已经逐渐结束，分布式、NoSQL及云原生数据库的出现，也带来了如 SQL 已死、NoSQL或NewSQL取代SQL的等各类声音。 但以 目 前的发展趋势来看，将来更大可能性是会出现多种数据库共存的情况 ，各个数据库奋战在最适合的场景下。

因此，只有先对这些数据库有了深入的理解，才能更好地选择对应的场景。尤其 在 商 业银行场景下，如何通过这些数据库来 更好地实现业务诉求 ，相信是很多银行仍在持续 探索的方向 。

分布式数据库

2000年左右，以Teradata为代表的MPP架构的数据库在数据仓库系统逐步推广；2013年NewSQL一词的提出，标志着分布式数据库 开始进军 OLTP负载的领域。随着NewSQL不断发展成熟，出现了Spanner、TiDB等 主要代表性的产品 。

分布式数据库主要是将数据分布在多个物理节点上，通过网络传输的方式对多个物理节点进行协调，以横向扩展的方式突破了单机数据库在容量上的限制。但随之而来也出现了新的问题：如何保证节点间的数据一致性？如何保证多节点对外的事务一致性？如何跨节点实现join、聚合、自定义函数、存储过程等原有的SQL操作？

分布式数据库本质而言还是单机数据库的扩展，如果把单机数据库拆开来看（如图1所示），数据库的核心组件主要分为服务层（提供SQL接口，也称SQL引擎层）、引擎层（实现事务的ACID，也称为存储引擎层）及存储层（实现数据结构及物理存储）。

图1

存储层解决节点间数据一致性问题

横向扩展为了降低成本，通常会采用廉价的硬件，并且由于节点间需要通过网络传输，硬件的不可靠以及网络的不可靠也标志分布式数据库本身就处于一个不可靠的物理环境，需要通过额外的手段提升可靠性。

目前主流的实现方式都是通过将数据写入到多个副本中，来确保数据的安全，由于网络传输的先后顺序，节点间收到数据同步请求也不一致，如果等待全部节点都同步写入成功，又会对性能有较大的影响。

目前数据库产品通常采用Raft、Paxos等算法或变种来实现节点间数据一致性，节点间的数据传输通常包含应用数据、元数据及事务日志。

引擎层保证对外的事务一致性

分布式数据库中不止需要考虑节点内部事务的一致性，更需要考虑全局事务，主流的工业实现在性能以及复杂度权衡，目前基本采用二阶段提交（2PC）来实现。但二阶段提交的缺陷在于：

在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。此外，针对全局时钟及序列的实现也是数据库产品的主要关注点。

服务层实现跨节点的SQL操作

SQL可以按算子处理先后顺序为扫描、关联、汇总三个阶段，基本上所有SQL语句都包含了扫描阶段，部分SQL包含了关联（join）或汇总阶段。

对于只进行扫描的SQL（就是SET/PUT某个表的一条或多条记录），这种SQL操作比较简单，在分布式数据库中此类SQL的性能关键点往往过滤条件中在于是否包含分布键，以及节点间的数据是否存在严重偏移。

包含关联逻辑的SQL语句在分布式数据库场景下，需重点考虑SQL是否会引起跨节点的数据传输，是否能够将过滤和join逻辑下推到本地节点处理，通常会对性能产生极大的影响。聚合操作的SQL通常为group by、order by、having、limit等子句以及聚合函数，数据库在读取数据之后，需要对结果数据在协调节点进行聚合，因此对于协调节点的内存开销较重，协调节点需要能够处理大数据量的内存轮换。对于以上两类的SQL语句，常见的优化方法包含创建本地表、join下推、 排序 下推、过滤下推等方式。

整体来说，分布式数据库的优势在于突破了单机数据库的容量限制，多节点可以实现高并发；而劣势在于，SQL的兼容性较差，落地过程伴随着应用程序改造，并且由于二阶段提交的问题，会导致额外的运维成本。

NoSQL数据库

2010年左右，MongoDB、 Redis 、Neo4j、HBase等各类非关系型数据库的涌现引发了大家对NoSQL的思考，当时也不断有NoSQL会替代关系型数据库的声音。随着近十年来的发展，NoSQL数据库在细分领域表现得非常优异，常见的NoSQL主要包含以下几类：

云原生数据库

2015年，全球市场份额最大的云厂商AWS发布了云原生的数据库产品Aurora，提出了log is database的新一代数据库理念，也从性能及可靠性上与RDS形成了差异化。

随后各个云厂商也推出了Aurze SQL Database、PolarDB以及CynosDB等云原生数据库。在将计算和存储等节点分离之后，各模块的性能和弹性就可以各自提升，具备应对大规模存储的能力。

以Aurura为例，通过log is database的设计哲学，将数据的更改变为只写日志，即write-once，极大地降低了数据库的写入操作。同时为了更好地适应云计算，他们认为应该将数据库系统这个“盒子”打开，在不同的层面进行扩展。

Aurora将恢复子系统委托给底层可靠的存储系统，依赖这个来保障系统服务层级（Service Level Agreement, SLA）。使得Aurora在没有引入分布式事务以及无需对应用进行改造的前提下，将性能和弹性扩展能力进行了极大的提升。

商业银行的挑战与选型思考

对于商业银行而言，随着国产化浪潮、线上支付的兴起以及大数据、AI等新技术的成熟，银行IT系统主要发展向着国产化、智能化、服务化的方向演进。银行的IT系统按功能划分大致可以分为四类：渠道服务系统、业务前置系统、账务处理系统、管理信息系统。

渠道服务系统与传统业务相比，已经与各个线上平台进行了相关对接，随着双11、618等各类平台的促销活动，高并发的支撑和资源能否快速弹性扩展成为线上渠道服务系统的必要考量因素。在这种背景下，可以采用基于私有云的弹性扩容以及云原生数据库的极致扩展来应对此类的业务爆发场景。

由于历史原因，核心账务类系统目前大多运行在IBM的大型机或小型机上，此类系统作为银行系统的心脏，并发高、一致性要求高，且兼顾联机交易及批处理场景，随着业务发展，面临着扩容成本高、扩容难度大的问题。

并且随着国际形势的变化，也必将面临着国产化之路，如何将核心数据库从Power 下移到ARM或将成为银行需要面对的课题。由于硬件本身的差异性，如何将现在的传统关系型数据库迁移到分布式数据库也必将是这个课题的核心重点和难点。

随着金融业务放宽及渠道的拓展，需要通过数据支撑贷款审批、金融诈骗、洗钱以及实时营销等场景，对于数据类系统的实时性要求提高，数据处理也从传统的T+1、D+1向着D+0及实时的方向转变。在这些需求下，图数据库、KV数据库以及文档数据库等也快速地补充了进来，提供了多模数据处理及实时分析的能力。 

总体来说，个人理解数据库的架构形态主要由三个原因引起：

1. 由于业务量及数据量的增长，对数据库的容量提出了新的要求；

2. 由于应用需求的变化，需要高速处理新型的数据类型；

3. 由于基础架构的进步，对数据库扩展性和性能提出了新的解决方案。

而以上的三类挑战，将会是今后的常态化现象，未来会出现越来越大的数据量要求、更多种类的数据类型，以及更健壮强大的基础架构。而如何不断地使用新的 工具 来 应对挑战 ， 打造可扩展的系统，支撑业务发展和业务诉 求 ，必将是银行业IT从业者长期的使命。