1.4　数据库架构转型

数据库的工作负载可分为事务型（On-Line Transaction Processing，OLTP）、分析型（On-Line Analysis Processing，OLAP）和混合负载（Hybrid Transactional/Analytical Processing，HTAP）。事务型数据库一般用于联机交易，关键是响应速度要快；分析型数据库大多被用于数据仓库或者决策支持系统。但也有很多场景需要综合考虑OLTP与OLAP特性。2014年，Gartner公司正式提出了HTAP，它是在保留原有在线交易功能的同时，也能够针对最新的业务数据进行实时统计分析。

本节将针对这些不同负载的需求，探讨数据库的起源、数据库的转型、数据库的国产化以及数据库的选型策略。

1.4.1　关系数据库起源

在数据库管理系统（DBMS）出现以前，数据存储在文件里，但文件对结构化的数据管理非常不方便，随着人们对数据应用和处理的要求越来越高，传统的文件系统已经不能满足人们的需要，能够统一管理和共享数据的数据库管理系统便应运而生。网状数据库和层次型数据库是最先发展起来的，但在20世纪70年代，关系数据库逐渐兴起。与网状数据库和层次数据库相比，关系数据库具有明显的优点：数据独立性高、重复性低、存取修改更方便等。这些显著的优点，使关系数据库逐渐取代了网状数据库和层次数据库。

以下是关系数据库发展过程中具有里程碑意义的历史事件。

1970年，IBM研究员E.F.Codd在Communications of ACM杂志上发表了一篇名为“A Relational Model of Data for Large Shared Data Banks”的论文，这也成为关系数据库历史上的奠基之作。

1977年6月，Oracle公司创始人Larry Ellison抓住了关系数据库这个巨大的商业机会，通过引入SQL、原子事务等关键特性，在数据库领域迅速站稳了脚跟，并在1989年正式进入中国。Oracle数据库目前最新版本为Oracle 19c。

1983年，Db2正式问世，被IBM大型机所专用，之所以名字为Db2，是由于以前已经有了一个著名的层次数据库产品Information Management System（IMS）。

1992年，IBM将Db2带向了多种开放式平台，包括Linux、UNIX以及Windows服务器，也简称为Db2 LUW，目前最新版本为Db2 V11。

1979年，Monty Widenius开发了一个名为Unireg的面向报表的存储引擎，这是MySQL数据库的最早追溯。

1996年，MySQL 1.0发布。

1999年，瑞典MySQL AB公司成立，开发出了Berkeley DB引擎，从此MySQL开始支持事务处理，这意味着开源数据库管理系统开始逐渐引领潮流。

2000年，MySQL采用GPL许可协议，正式进入开源的世界。

2005年，MySQL 5.0正式发布，这个版本加入了存储过程、触发器、视图、查询优化器的改进和支持，为MySQL迈向高性能数据库服务器奠定了基础。

2006年，MySQL InnoDB引擎发布并赢得青睐，成为最流行的开源数据库引擎。

2008年，MySQL AB公司被Sun公司以10亿美元收购，Sun公司对其进行了大量的优化和缺陷修复工作。

2009年，Oracle公司以74亿美元收购Sun公司，自此MySQL数据库进入了Oracle时代，MySQL开始出现企业版和社区版两个分支进行演进。

MySQL社区版目前最新版本为V8，随着互联网和商业银行更多的技术开发人员加入，相信它会不断完善，发展会越来越好。

1.4.2　从商业数据库到开源数据库转型

长久以来，数据库由于技术挑战大、产品成熟度和服务质量级别要求高，始终由IBM、Oracle等传统巨头紧握市场份额和获取途径。

面对着日渐繁杂且高度异构的企业环境，企业越来越无力应付数据的快速增长以及工作负载。然而，随着金融科技的发展，开源数据库因为能够满足企业新的需求，可以代替企业已有解决方案，从而逐步打开市场需求，已然成为商业银行发展进化的必要选择。

（1）依托源代码不断开发、优化人才、社区、开源的生态。开源本身对工程师非常有吸引力，它的理想主义，会感召完美主义和理想主义追求者加入。

（2）通过开源数据库社区的打造，吸引技术的追求者和开源的热爱者加入，将有共同理念和梦想的人聚在一起，相互学习交流，形成积极正向循环。

（3）互联网或技术圈很喜欢进行技术分享，通过分享产品树立品牌，所以，总体社区会变成一个正向的循环，使用越频繁，问题反馈越多，修复问题越多，从而形成开源数据库的超强适应能力和修复能力。

从商业银行云平台市场环境来看，云计算已然由概念走向实践，发展势头迅猛。对未来的开发者来说，如果在云上有使用数据库的需求，这是开源数据库的用武之地。未来一切的业务都会依托云端，不管是私有云、公有云还是混合云，运维团队接触的不再是数据库服务器，而是一个个隔离的虚拟机或者容器。

1.4.3　从集中式到分布式数据库转型

20世纪70年代初兴起的关系数据库属于集中式数据库，这种数据库一直延续到21世纪初，在金融行业发挥了巨大作用。

但是，集中式数据库就像一个容器，数据就是容器中的液体，容器无论如何都有上限，能接纳的液体也是有限的。特别是随着商业银行应用（也包括互联网应用）的用户规模、数据量都越来越大，并且要求7×24 h在线。传统集中式数据库在这种环境下成为瓶颈，通常有两种解决方法：一是升级服务器硬件，这称为垂直扩展（Scale Up），这种方式简单直接，但单机处理能力有限；二是对数据分片，使用由廉价机器组成的分布式的集群，这称为水平扩展（Scale Out），但以前在一个数据库里的数据，现在跨了多个数据库，涉及关联、分布式事务时复杂度高。在集中式数据库出现性能瓶颈的时候，分布式数据库应运而生。

2009年，Google提出了Spanner方案，并随后实现了全球化的分布式关系数据库F1，用于其广告系统。

2015年，亚马逊发布了Aurora数据库，它专为云而打造，在分布式存储上提供高性能的MySQL和PostgreSQL数据库集群，既具有传统企业数据库的性能和可用性，又具有开源数据库的简单性和成本效益。

2016年，蚂蚁集团发布分布式数据库OceanBase 1.0，并在支付宝账务系统中成功上线。

2019年，中信银行与中兴通讯联合研发的GoldenDB分布式数据库在2020年5月成功上线，替代了在中信银行核心系统服役了多年的IBM AS400数据库。

当前，正处于商业银行从集中式数据库到分布式数据库转型的关键期，后续将有不断的自研分布式数据库涌现，并会有更多的系统从集中式数据库迁移到分布式数据库。

1.4.4　国产数据库发展

近两年逐渐看到一些重大的核心业务系统迁移到国产数据库上，国产数据库正在不断发展，提供了丰富的产品功能，受到各大商业银行前所未有的重视。

说起国产数据库的开山始祖，非人民大学的萨师煊教授莫属。萨师煊与其学生王珊合著的《数据库系统概论》，直到现在依旧是我国数据库领域的经典教材。早在1978年，萨师煊教授就开始为中国人民大学的学生们普及数据库的知识。

总结来看，国产数据库的自主可控之路大概经历了以下三个阶段。

第一阶段：跟随阶段。2000年前后，主要跟随国外的Oracle、Db2等数据库，国产数据库面临很大的困境，技术比国外的数据库技术落后十年以上，国外数据库成熟的产品、成熟的客户、成熟的使用案例都是国内跟随者所不具备的，国产OLTP数据库通过国家的扶持进行技术的积极拓荒。

第二阶段：追赶阶段。针对数据仓库领域的MPP数据库技术蓬勃发展，国产OLAP数据库领域与国外同类产品的技术差距逐渐缩小，同时国内客户对国产OLAP的接受度逐渐提升。这个阶段OLAP数据库主要应用在非核心业务场景，客户对系统可靠性、稳定性接受度较好。国产OLAP数据库在数据仓库领域得到了较大的发展。

第三阶段：技术大爆发阶段。在大数据、互联网、开源等技术的发展推动下，现有数据库技术无法满足国内企业应用场景的规模和性能等需求，国内技术人员对数据库内核相关技术掌握越来越深入和全面。

随着国家对自主可控的需求不断提高，国产数据库迎来更大的发展机遇。

1．战胜Oracle的国产利器——蚂蚁OceanBase

时间到了2020年，国产数据库可谓是精彩纷呈：蚂蚁OceanBase再破TPC速度记录；阿里云PorlarDB首进Gartner数据库领域的领导者象限；华为GaussDB革命性功能全密态地发布。

随着移动互联网大潮来临，我国IT巨头应用方面的创新令人印象深刻，如O2O、共享单车、自动驾驶、移动支付等新应用，但是各大商业银行的核心数据库却一直被Oracle与Db2等国外产品牢牢把持着。

2019年，蚂蚁的OceanBase数据库成功登顶世界上最权威的数据库评测机构TPC（国际事务处理性能委员会）排行榜榜首。

2020年5月，OceanBase再次将自己之前创造的记录提升了近十一倍，将甲骨文、IBM等一众老牌数据库巨头甩在身后，正式宣告国产数据库落后于国际先进水平的时代已成过往云烟，自研数据库产品自此站起来了。

2．金融级核心数据库——GoldenDB

2019年10月26日，中信银行与中兴通讯联合研发的GoldenDB分布式数据库在中信银行信用卡核心业务系统投产；2020年5月3日，GoldenDB在中信银行总行账务核心业务系统投产。两大核心投产后，GoldenDB顺利通过网联压测、双11、年终决算、618与季度结息等现网考验，运行稳定。这标志着GoldenDB分布式数据库已是成熟稳定的产品，达到业界领先水平。

中兴通讯GoldenDB是一款具有银行基因的金融级分布式数据库产品，从架构层面保证事务强一致和数据高可靠，并可根据业务需要实现在线扩容，具备如下特点。

（1）对应用透明、实时强一致的分布式事务。银行业务逻辑相对复杂、数据一致性要求严格，当前大部分的分布式数据库产品不支持实时强一致的分布式事务，不适合直接拿来借鉴和使用。同时，银行应用迁移也要求分布式事务处理必须对业务透明，像使用传统集中数据库一样使用分布式数据库。GoldenDB通过全局事务管理器（GTM）、自动补偿机制等架构设计，保证分布式事务的实时一致性读和一致性写。基于GoldenDB分布式数据库，不仅能够快速开发新业务，银行已有的应用系统也能够平滑迁移，几十年来积淀的应用资产得以继承。

（2）系统组件高可靠。GoldenDB为分布式计算与数据存储分离的架构设计。在计算集群中，每个计算节点均为无状态设计，可以随时接入或移出计算集群，任意计算节点异常，由对等节点接管业务；表数据在数据集群中切分为多个数据分片，每个数据分片对应一个安全组，安全组由多台机器组成，通过多副本冗余机制保障数据的高可靠。

（3）两地三中心高可靠。GoldenDB支持两地三中心部署，本地机房和同城机房之间数据实时同步，本地机房故障时切换到同城机房，数据零丢失。本地机房和异地机房之间距离较远，通常采用异步方式复制。

（4）在线扩容。GoldenDB满足银行大容量存储、高并发访问的要求。当存储容量或者处理规模达到瓶颈时，通过在线增加机器设备即可实现扩容。数据节点扩容时，通过后台计划任务自动完成数据重分布，整个扩容过程不影响在线业务运行，满足银行业务7×24 h不停机要求。

3．传统数据库的终结者——PolarDB

2010年前后，中国的互联网企业普遍迎来了一波流量爆发。其中，继2003年推出支付宝以后，淘宝在2005—2012年的交易迅速增长，交易额从80亿元、200亿元到1000亿，直到破万亿。不过这种爆炸式增长，也成为阿里人甜蜜的负担，因为阿里电联用户的增长速度已经渐渐超出系统处理能力的提升速度，而原来一直沿用的IOE（IBM小型计算机、Oracle数据库和EMC存储）中心化系统与这种高用户并发的场景几乎格格不入，暂且不论达到如此性能的IOE系统成本会有多惊人，问题的关键在于即使是当时最强大的科技公司，也没有经历过上亿用户同时在线的业务场景，使用国外的产品方案有如南辕北辙，无法真正解决问题。

正因此，王坚院士率先提出去IOE的目标，通过技术自研来解决用户爆发式增长的问题。

在IOE架构的系统中提升算力的思路是让服务器越来越强，云计算的分布式思路是只需要增加服务器节点的数量，就能处理更多的并发服务请求，而分布式系统的业务连续性，并不是靠高可用性来保证，而是靠整个服务体系的容错能力造就的。在不断探索的过程中，也诞生了新的分布式架构，通过发挥云计算的威力，使得看似普通的虚拟机集群，能够碾压一体机，能够为亿万用户同时提供优质的服务。

根据Gartner于2020年11月24日发布的2020年度全球数据库魔力象限评估结果，阿里云凭借PolarDB的强大性能首次挺进全球云数据库供应商的第一阵营，进入领导者（LEADERS）象限。Gartner在报告中指出“阿里云拥有丰富的数据库种类覆盖度和完善的产品布局，为用户提供了多种关系型和非关系型数据库产品，还提供了混合云环境部署，同时集成了备份、数据迁移与同步等能力。”

PorlarDB除了在索引结构、锁机制等传统数据库组件方面进行优化以外，还特别针对云服务特有的全球跨域数据同步与容灾需求，进行了重点设计。很多云服务客户的业务遍及世界各个大洲，因此对于云数据库的跨域数据同步也会有非常高的要求。PolarDB全球数据库（PolarDB Global Database Network，PolarDB-GDN）采用了数据库物理日志异步复制的方案。PolarDB-GDN通过高并发流水线技术将同步速度提升了7倍，将数据跨大洲同步延迟控制在2 s内。全局读写分离技术结合多级别的一致性能力，让业务在不做任何改造的前提下降低整体的访问延迟，全面满足了云用户的需求。

国产数据库的未来可期！

1.4.5　数据库选型策略

目前可选的数据库种类繁多，关系数据库既存在商业数据库Oracle、Db2、SQL Server、Sybase、Teradata等；也存在开源数据库MySQL、MariaDB、PostgreSQL等。那么伴随着各种数据库的发展，商业银行如何选择适合自己技术路线的数据库产品呢？

这个问题本质上是数据库技术路线规划问题。

商业银行需要结合本行数据库部署现状，结合数据库技术和市场发展方向，规划符合本行实际的数据库发展演进路线图。通过技术路线规划，指导新建系统数据库软件的使用，并对存量系统制订迁移计划，以降低运维沟通成本。

（1）梳理存量产品目录：对数据库使用情况进行梳理，形成目录清单，给出使用标准。

（2）制订产品部署标准：明确不同部署需求下数据库选择和配置标准，规范新建系统数据库使用，降低运维资源投入。

（3）规划产品技术路线：对技术方向不明确、存在路线选择的领域，给出选择意见或选择策略，制订数据库发展技术路线规划。

（4）针对人民银行推进国产化的要求，开展数据库国产化路线研究，制订评估流程、准入标准、定期评估机制等，明确数据库软件国产化的策略、节奏、路径、试错机制。

对产品目录、部署标准进行线上化管理，建立数据库特性和系统指标的关联关系，指导针对应用系统的数据库技术架构和部署架构设计。