导语： 本文根据黄海明老师在2018年5月10日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

达梦技术总监 黄海明

摘要

传统关系数据库经过几十年的发展，架构是否已经到了演进尽头？MPP、读写分离、共享存储、分库分表……琳琅满目的架构从何处来向何处去？未来关系数据库架构可能会如何发展？本主题以达梦数据库架构演进与创新为例，向大家分享我们的看法。

达梦数据库从上世纪80年代开始一直走自研的道路，既非基于开源，也并非源自第三方授权。

像Oracle数据库一样，达梦数据库开局也是一个单机数据库，这个单机数据库是1988年冯玉才教授研究出来的我国第一代有自主知识产权的数据库管理系统。随着达梦数据库在一些重要行业的广泛应用，为了解决高可用性的需求，达梦推出了主备架构。随着“棱镜门”事件的发展，国家对信息安全的重视程度进一步提升，国家希望能够推行芯片级的国产化，为了在芯片级国产化的场景里面真正应用起来，达梦推出了读写分离架构。2012年后大数据蓬勃发展，面对大数据分析的需求，达梦推出了大规模并行计算的架构。

达梦推出这么的架构，都是用匠人之心在做的。比如主备架构，我们的备机设计之初就是可以做只读的，Oracle 11G才支持只读，Oracle 10G的时候备机只能以mount状态启动，不能用于做查询。另外，系统在做读写分离的时候，很多报表程序想在备机上运行，这个报表程序大部分是只读的，但是很多的报表程序需要用临时表存一下中间数据，临时表上一些增删改的操作无法在备机上完成。在碰到这个需求之后，达梦对备机做了创新，就是达梦的备机可以支持对临时表的增删改，这样报表业务就可以运行在备机上面。我们的备机可以支持实时的备机和异步备机，实时的备机主要做故障切换用的，如果报表程序要单独使用一个备机的话，我们可以在实时备机的基础上在加一个异步备机。

实际上，在X86的服务器上达梦单机的处理能力已经很强悍了，我们一般一个一主一备的主备架构就足以应对很多核心的生产系统。到了芯片级的国产化环节就需要读写分离的架构，因为它的单机处理能力要稍微的弱一些。我们的读写分离和传统的开源的读写分离架构是不太一样的，我们的读写分离不需要应用也不需要中间件去做分发，它是在我们的驱动程序和服务器端做的分发，这样对于应用是透明的。另外，我们的读写分离可以同时兼顾性能和可靠性的问题，主备机之间可以做负载均衡，当主机出现故障的时候，它可以选择一台备机切换成主机对外响应业务。

在做大规模并行集群(MPP)的时候，我们也做了很多的创新，我们的MPP集群同时支持行存储和列存储。它不只是简单的做一个行存储引擎和列存储引擎，它会做很多的融合。

作为一个企业级的数据库，我们的MPP集群支持单机所有的SQL特性，包括单机支持的一些接口。对于共享存储的集群，我们也实现了跟Oracle架构完全一样的真正的数据共享集群。

我们之所以做主备集群，主要源自于国家电网的国产化项目。

在2008年，国家电网在新一代智能调度系统里开始全面做国产化，这里选用的数据库就是达梦数据库。国家电网新一代智能调度系统可用性要求是99.99%，也就是说一年的停机时间不能超过两个小时。我们以前的单机架构是无法满足这种需求的，比如升级的时候，你没有办法做滚动升级，于是我们推出了主备架构，这个主备架构也是基于REDO日志来做复制的，实现原理跟Oracle是完全一样的。

在中国铁建的财务共享平台项目中，我们针对财务系统的特点做了一个读写分离的解决方案。大家都知道财务系统的SQL语句是非常复杂的，中国铁建有十几个局，以前每一个局都有一套财务系统，随着国家对央企管理越来越严，铁建要做一个财务共享服务平台，把每个局的财务系统全部集中到一起，专门成立一个财务公司来统一管理。这样就面临着系统如何去实现国产化的问题，于是我们做了一个读写分离的架构，把日常的一些费用控制类的写操作较多的业务，放在主机上面，然后把那些SQL比较复杂的核算类的业务放在备机上去执行，这样便做了一些有效的读写分离。但是我们也遇到了一个问题，就比如每个月末和季度末要出报表了，由于备机不知支持对临时表的增删改，报表程序只能放在主机上跑，这种情况下备机不是很忙，但主机很忙。这个时候我们就希望把报表程序放在备机上面，进一步提高备机的利用率。于是我们便做了一个创新，就是在备机上面支持对临时表的插入、删除和更新的操作，这样我们的报表程序就可以非常方便的切换到我们的备机上面去运行，有效的提高了资源的利用率。

达梦的主备架构在很多的央企和政府里面获得了广泛的应用，当然大部分都是基于X86平台。众所周知，美国商务部对中兴公司进行了封锁，完全暴露出我国在国产芯片上的短板。但实际上我们的国产芯片目前的处理能力其实还是可以的，目前市面上可以买到的CPU主频可以达到1.5G以上，内核数大概在16核以上，支持的内存容量可以到64~128GB，这是目前国产CPU的整体水平，当然这和X86平台还是有一定差距的，因为它不只是芯片的问题，是一个生态问题，CPU也需要很多的外设和操作系统、数据库之间的配合，所以它在单机处理能力以及整体可用性上就和X86系统稍微有一些差距。为了实现全国产的目的，我们研发出一个读写分离的架构。 

目前全国产的系统大多数的业务场景符合读多写少的特征，这样就可以把一些写的操作放在主机上，读的操作放在备机上。整个读写分离的过程对用户来说是透明的，它通过我们的驱动程序和服务端自动做分发，也就是说单机的程序不需要做任何的修改，可以方便的移植到我们的读写分离系统上面来。比如说我们一主三备组成的集群，这四台机器任何三台出现问题整个系统都是可用的，主机出现问题的话可以选用一台备机切换到主机，这个切换可以是手动的也可以是自动的；备机出现问题可以自动将坏掉的备机剔除出集群，主备之间始终保持着严格的一致性。

那么我们是怎么去做读写分离的呢？首先我们主备机之间的复制我们称之为及时归档，就是说我们主机产生的REDO传送给备机，备机应用了之后，主机才会提交，这样可以保证主机和备机之间的强一致性。有了这个的保障之后就可以做事务级的读写分离。

第一个事务是读和写的混合事务，它的第一个SQL语句是一个查询语句，我们的驱动会自动的把它分配到备机上去执行。第二条语句是一个插入语句，我们把它分配到主机上去执行，并且在整个过程中，它下面的操作都是在主机上执行的。第一个事务是一个纯的查询类的业务直接分配到备机上去执行。主机和备机承担多少业务都是可以设置的。

上图是我们做的一个测试，是在某国产CPU平台环境下面做了一个对OA典型应用性能的测试。

系统的性能要求是500并发下所有操作的响应时间不超过5s，通过测试我们可以看出在200Vuser上，单机性能就显得非常勉强。于是我们做了一个一主五备的集群，它可以满足500并发的需求。<