水利行业国产数据库选型思考

陈真玄 ，张 怡 ，杨 柳 ，孟庆学

（1.水利部信息中心，北京 100053；2.北京金水信息技术发展有限公司，北京 100053；3.北京沛海科技有限公司，北京 100083）

0 引言

在当前国际新形势下，信息产业推进国产化的意义之一是避免核心技术受制于人，保障网络安全乃至国家安全。“核高基”研究任务中的“基”指以数据库、操作系统等为核心的基础软件产品，其中数据库作为数据存取、管理和应用的核心工具，决定了 IT 系统运行处理数据的高效性，数据库的国产化替代是信息产业国产化进程的重要瓶颈，数据库国产化是保障网络和国家安全的必然要求[1]266。

目前，全球主流数据库产品中，Oracle，DB2，MySQL 等仍占据大部分的市场份额，在国内市场，特别在数据库最核心的交易业务中，很少能有跟Oracle 旗鼓相当的产品。中国 2 000 多家银行，核心交易系统大多采用 Oracle 或 DB2 的数据库管理软件。尽管国内数据库产品也逐渐趋于成熟，但目前主要应用于电子政务和公文流转等数据量不太大、交易查询简单的常规业务中，仍然无法进入核心交易领域，如银行、电信、能源、税务等领域[2]。

数据库国产化的难点在于：当前 IT 系统运行多年，许多对数据可靠性要求较高的、业务应用较复杂的系统长期以来对 Oracle 和 DB2 等数据库形成依赖，包括政府机构、大型企业、银行证券等。此外，国产化改造时，部分业务系统还需要改写数据库连接接口，调整查询语句的写法，修改原有数据库触发器及函数等。因此如何进行国产数据库的选型，如何在国产化改造时减少对业务系统的影响，尽可能地实现国产数据库的平滑迁移，都是数据库国产化进程中将会面临的问题[1]266。

目前水利部机关正在积极推进，逐步将业务由Oracle 等国外数据库迁移到国产数据库上，为此分析国产数据库的主要技术路线，以期为水利行业国产数据库的选型提供一些参考建议。

1 国产数据库主要技术路线

根据数据库国产化与信息安全的总体规划要求，国产数据库产业发展提速，呈现出百花齐放的景象，国内典型的数据库产品有达梦、金仓、南大通用、神舟通用、瀚高等数据库。

此外，随着水利信息化的快速发展，引发了数据量的迅猛增长，国内部分数据库厂商、尤其是大型互联网厂商开发出分布式架构的数据库系统，具有在线弹性扩容、高并发支持等能力。OceanBase和 TBase 等分布式关系数据库，具有数据强一致、高可用、高性能、在线扩展、高度兼容 SQL 标准等特点；GaussDB 采用 MPP（大规模并行处理）架构，支持行与列的存储，提供 PB 级别数据量的处理能力；RDS MySQL 等云数据库架构产品可根据云租户需求，灵活部署于虚拟机、云服务器；分布式架构的 Taurus 数据库具备可弹性扩展、高可靠性、高 I/O 吞吐能力等特点[1]267。

1.1 主从架构

达梦、瀚高等数据库为提升数据处理能力，在水平扩展方面通常采用主从架构，通过读写分离的方式，将混合负载中的读操作切换到备数据库（以下简称备库），降低主数据库（以下简称主库）压力，提高主库事务处理能力，通过 1 个或多个只读备库处理更多的查询请求。

主从架构主要应用于实时备份、容灾和读写分离等场景，具体架构如图1 所示。

图1 主从架构

主库读取日志进程获取数据库的日志，然后通过异步或同步复制等方式将其传送给备库，备库收到日志并完成应用，使主备库数据一致。同步复制方式，在主库提交事务后会等待备库收到日志并完成日志应用，才返回事务提交通知给客户端；异步复制方式，主库提交事务后即刻给客户端返回事务提交通知，读取日志进程异步进行数据复制，然后应用到备库；半同步方式，介于同步复制和异步复制之间，是指在多个备库情况下，部分备库（至少1 个备库）提交或收到主库日志后，主库才能返回事务提交通知给客户端，在主备库网络不通或备库发生故障时，备库返回超时，主库可以降级为异步模式，避免阻塞主库。

同步复制方式，由于备库提交事务后才能返回给客户端，因此主库和备库的数据是一致的，主库发生故障时备库不会丢失数据，但是如果网络问题导致日志传送发生问题或备库发生故障，也会导致主库被阻塞，影响主库运行；异步复制方式，网络或备库发生故障不会影响主库运行，但是如果主库发生故障，此时备库和主库的数据是不一致的，备库会丢失部分最新数据。

目前达梦、瀚高等传统数据库都支持主从模式，生产环境中建议采用半同步或异步方式部署，在数据一致性和可用性之间进行合理的均衡。

1.2 分布式架构

分布式数据库是指数据分散于多个节点而构成的逻辑统一的数据库，通常有 NoSQL，MPP 和支持事务的 NewSQL 等数据库，本研究只讨论 NewSQL数据库。

分布式数据库的主要特点如下：

1）支持事务，分布式数据库可实现数据库事务的原子性、一致性、隔离性和持久性；

2）高可用性，是指分布式数据库通过多节点数据冗余实现高可用，其中 1 个节点发生故障时，其他冗余节点也可以提供服务，部分数据库还能实现跨地域的高可用；

3）可扩展性，分为节点内增加系统资源的垂直扩展和节点数量的水平扩展等方式，分布式数据库能够通过增加节点数量水平扩展数据库容量和处理性能。

1.2.1 数据同步及一致性

数据同步实现分布式数据库的节点数据冗余，实现数据多份存储，并且保持一致性。数据库可以从不同节点访问此数据，消除数据存储的单点问题，避免数据丢失，进而增强系统可用性。

CAP 定理[3]证明了在一个分布式系统中一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者不可兼得：

1）一致性。一致性是指在同一时间点，保存在多个节点的同一份数据是相同的，此处的一致性是指分布一致性，通常分为强、弱和最终一致性，有别于数据库事务的一致性。

2）可用性。可用性是指分布式系统中部分节点发生故障，系统仍然能够继续提供服务。

3）分区容错性。分区容错性是指网络通常是不可靠的，分布式系统在发生网络故障导致部分节点无法访问，整个系统被分成多个区域时，系统仍然能够提供服务。

在分布式系统中，网络分区是无法避免的，分布式系统根据需求可以选择 CP 或 AP 2 种模式：CP指保证一致性，发生分区后部分节点不可访问，但可访问节点返回数据是一致的；AP 指保证可用性，发生分区后所有节点都可以访问，但不是所有节点的数据都是最新的，数据不是最新的节点通常在网络恢复后同步为最新数据，保持一致性，此为最终一致性（BASE）。

分布式数据库通常选择 CP 即保证一致性，实现一致性的协议主要有 Paxos[4]，Raft，Zab 等。

Paxos 及其变种 Raft 协议是常见的半同步一致性/共识协议。Paxos 实现了在可能发生节点/进程异常或网络故障的分布式系统中，多个节点如何对 1 个问题达成一致。Paxos 有提议发起者、接收者和学习者 3 个角色，通过提议是 1 个两阶段过程，即准备和批准 2 个阶段，只有多数接收者收到并批准发起者的提议，整个提议才能提交成功。分布式数据库采用此算法解决多节点副本一致性的问题。

1 个两阶段过程每次只处理 1 个提议，如果需要处理多个连续提议则需要多个两阶段处理过程，成本比较高，另外多个提议发起者也会存在冲突问题。

OceanBase 等分布式数据库实现 Paxos 时使用Multi-Paxos，Multi-Paxos 引入 Leader 角色，简化了准备过程，提议节点通过上述的准备和批准阶段，在网络中广播竞选 Leader 请求，获得批准后成为 Leader 节点，其他节点为 Follower 节点。只有Leader 节点能够提出提议，因此 Leader 节点提出提议不需要准备过程获取提议权，其连续的提议都是对同一提议编号的多个批准过程，所以只需要接收者批准即可。从客户端角度看，Leader 节点对外提供强一致的读写操作，Follower 节点负责投票，不提供读写或只提供弱一致的只读服务。

TiDB 等数据库采用 Paxos 变种协议 Raft[5]，Raft 简化了 Paxos 协议，实现与 Multi-Paxos 相同的功能，Raft 基于多副本复制状态机构建，状态机把指令以日志方式持久化通过执行指令进行更新，所有节点从同一个状态开始，节点间同步指令，各节点复制状态机按顺序执行相同指令，达到相同状态。Leader 节点接受请求，将其数据变更指令追加到自己的日志中，同时向其他 Follower 节点发送追加条目请求，当这个指令被大多数 Follower 节点复制写入其日志后，Leader 节点收到其写入完成反馈就将这条指令应用于状态机，此记录为已提交，然后返回给客户端，如果部分节点由于故障无法同步日志，Leader 节点会在后台异步重试发送追加条目请求直至成功，使所有节点数据一致。

TBase 数据库目前版本采用的是主备同步或异步复制技术。

1.2.2 分布式事务

分布式事务的实现有两阶段提交（2PC）[6]、三阶段提交（3PC）和 TCC（Try Confirm Cancel）、消息队列等多种方式，满足事务的 ACID（Atomicity，Consistency，Isolation，Durability）是分布式数据库的核心要求，2PC 是分布式数据库实现事务原子性和一致性的常见方式。

2PC 是一个中心化且满足事务一致性的协议，有协调者和参与者 2 类节点：

1）协调者。协调者与所有参与者通信并控制其操作，从而完成全局事务。

2）参与者。作为全局事务的一部分，负责节点本地的事务提交或回滚。

2PC 的准备阶段，由协调节点向参与节点发送事务预处理请求，由其投票决定事务能否提交，如果所有节点回复能够提交事务，则进入提交阶段。在提交阶段，协调者通知参与者提交事务：如果所有参与者都提交成功并通知协调节点，则全局事务提交成功；如有参与者提交失败，协调节点则发送回滚请求，让参与者回滚事务。

2PC 存在同步阻塞、单点故障及数据不一致等问题。针对问题，通过增加额外的可提交通信阶段，并对协调者和参与者都引入超时机制可解决单点故障问题，此为 3PC 协议。由于 3PC 会明显降低事务性能，增加复杂性且无法解决数据不一致问题，因此较少采用。

另一种方式是在 Paxos/Raft 一致性协议基础上运行 2PC 协议，利用 Paxos 等协议使事务的信息都复制到副本节点，任何 1 个节点宕机都可通过 Paxos等协议很快选举出另外 1 个副本节点代替原来节点，恢复原有事务状态继续完成事务，此种方式引入Paxos 等协议增加了复杂性和延迟，降低了性能。

在分布式数据库的设计中都对 2PC 协议进行了优化和改进，采用 Paxos 协议的 Oceanbase 和 Raft协议的 TiDB，利用多副本机制避免节点故障带来的单点问题。Oceanbase 等数据库采用协调者无状态的方式，协调者不记录事务状态，当协调者发生故障时，通过所有参与者的本地状态生成事务全局状态，避免无状态带来影响，弱化传统 2PC 中协调者中心化带来的问题，同时减少事务的时间延迟。

隔离是数据库事务的另一个要素，常用的隔离级别包括 Read Committed，Repeatable Read，Serializable 等，假设 2 个事务t1和t2，只有t1的开始时间大于t2的提交时间，t1才能看到t2的修改，这才符合事务隔离要求。Oracle 等数据库通常采用 MVCC（Multi-Vesion Concurrency Control）技术保证写不阻塞，读实现 Snapshot[7]隔离级别，提供高并发事务处理能力，大部分数据库都支持Read Committed 和 Repeatable Read 的隔离级别。Serializable 是最严格的隔离级别，在 Serializable 隔离级别中事务按照顺序串行并发执行。Oracle 等数据库通过 2PL（Two-phase Locking）全程加锁的方式实现 Serializable 隔离级别，以防止事务期间访问的数据被其他事务修改，这种方式读写相互阻塞，效率较低，所以即使数据库支持也很少采用。

Google Spanner[8]数据库利用硬件实现全局时钟，提供外部一致性，通过 2PL 实现 Serializable隔离级别；TBase 分布式数据库通过软件生成全局逻辑时钟，结合 MVCC 多版本机制、2PC 和 SSI（Serializable Snapshot Isolation）实现 Snapshot 隔离级别。

2 主流国产数据库介绍

目前达梦、金仓、神舟通用、瀚高等主流国产数据库已经逐步建立较为完善的生态环境，不仅可以兼容原来市场上占主导地位的 Intel 芯片，也可兼容鲲鹏、飞腾、海光等主流国产芯片，不仅可以适配 Linux 和 Windows 操作系统，也可适配麒麟、统信等主流国产操作系统，以及东方通、中创、金蝶等主流国产中间件，并且各个厂商还在以更快的速度推进国产环境的适配验证工作。

2.1 达梦数据库

达梦数据库管理系统是具有完全自主知识产权的高性能数据库管理系统，最新版本是 8.0 版本，简称 DM8。

DM8 数据库支持各种国际和国内相关标准，具有高性能、高可靠性和易用性，支持多 CPU，支持TB 级以上的数据和大并发量用户，支持集群；可支撑大、中型企业和政府部门应用，为关键任务的应用程序提供高效、可靠、安全的数据管理，可满足党政机关、企事业单位的各种应用需求。

2.2 金仓数据库

金仓数据库（KingbaseES）是有自主知识产权的通用关系型数据库管理系统。

金仓数据库主要面向事务处理类应用，兼顾各类数据分析类应用，可用做管理信息、业务及生产、决策支持等系统，以及多维数据分析、全文检索、地理信息系统、图片搜索等的承载数据库。

金仓数据库的最新版本为 KingbaseES V8，KingbaseES V8 在系统的可靠性、可用性、性能和兼容性等方面进行了重大改进，支持多种操作系统和硬件平台，支持 Unix，Linux 和 Windows 等数十个操作系统产品版本，支持 X86，X86_64，以及国产龙芯、飞腾、申威等 CPU 硬件体系结构，并具备与这些版本服务器和管理工具之间的无缝互操作能力。

2.3 神舟通用数据库

神州通用数据库基于产品组合，可形成支持交易处理、MPP 数据库集群、数据分析与处理等解决方案，可满足多种应用场景需求。产品通过了国家保密局涉密信息系统、公安部等保四级等安全评测和认证。

2.4 瀚高数据库

瀚高数据库引进开源数据库 PostgreSQL 内核技术，在 PostgreSQL 社区版之上做了一系列的研发和优化。

瀚高数据库完全符合 ACID 原则，支持外键、连接、视图、触发器、存储过程（多种程序语言）等功能，具有高效的并发控制机制，能够支持 TB 级海量存储，具有完善的备份恢复机制。可与 Oracle数据库拥有完美兼容性，使得用户现有的基于Oracle 数据库平台开发的应用程序，无需做任何修改或只做少量修改便可运行在瀚高数据库上，从而实现高效快捷的应用迁移。瀚高数据库拥有多层安全防护机制，能够从访问控制、数据加密、数据完整性等多个维度，最大程度地保障数据库访问及数据存储的安全。

2.5 OceanBase 数据库

OceanBase 数据库是完全自主研发的金融级分布式关系数据库，具体架构特点如下：

1）多副本。一般部署为 3/5 个 Zone，每个Zone 由多个服务器节点组成。

2）对等节点。每个节点均有自己的 SQL 和存储引擎，自主管理各自承载的数据分区，TCP/IP 互通，协同服务。

3）无需存储设备共享。数据分布在各个节点上，不基于任何设备级共享存储技术，不需要 SAN（Storage Area Network）网络；消除了单点，每个节点都具有完备处理能力，能管理本节点上的数据。

4）分区级可用性。分区是可靠性与扩展性的基本单元，自动实现访问路由、策略驱动负载均衡、自主故障恢复。

5）高可用 + 强一致。多副本 + Paxos 分布式协议的高效高可靠工程实现，确保数据（日志）持久化在多数派节点成功。

2.6 TBase 数据库

TBase 数据库是自主研发的分布式数据库系统，集高扩展性、高 SQL 兼容度、完整的分布式事务支持、多级容灾及多维度资源隔离等能力于一体。TBase 采用无共享的集群架构，适用于 GB～PB级的海量 HTAP（Hybrid Transaction and Analytical Process）场景。

TBase 数据库集群架构主要由以下 3 个部分组成：

1）CN。即协调节点，对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图。在功能上 CN 只存储系统的全局元数据，并不存储实际的业务数据。

2）DN。即 Datanode，用于处理存储本节点相关的元数据，每个节点还存储业务数据的分片。在功能上，DN 节点负责完成执行协调节点分发的执行请求。

3）GTM。即全局事务管理器，主要做分布式事务，负责管理集群事务信息，同时管理集群的全局对象，如序列等，不提供其他功能。

TBase 数据库的架构优点如下：

1）多活/多主。每个协调节点提供相同的集群视图，可以从任何 1 个 CN 写入，业务无需感知集群拓扑。

2）读/写扩展。数据被分片存储在不同的 DN上，集群的读/写能力随着集群规模的扩大而得到提升。

3）集群写一致。业务在 1 个 CN 节点发生的写事务会一致性地呈现在其他 CN 节点，就像这些事务是本 CN 节点发生的一样。

4）集群结构透明。数据位于不同的数据库节点中，查询数据时，不必关心数据位于的具体节点。

2.7 巨杉数据库

巨杉数据库是新一代国产原生分布式数据库，采用多模数据库存储引擎，实现结构化、半结构化、非结构化数据的统一存储管理。巨杉数据库作为金融级分布式数据库系统，已经在国内超过 50 家银行和近百家金融机构的生产环境中上线运行，拥有目前国内金融领域规模最大的独立分布式数据集群。

巨杉数据库基于“计算-存储”分离架构，可满足数据存储容量按需扩展和数据库计算能力弹性伸缩的需求。巨杉分布式数据库支持分布式事务 ACID，提供原生 API 访问接口，并兼容标准MySQL，MonggoDB，PostgreSQL，MariaDB，SparkSQL，S3 对象访问等多种结构化和非结构化计算层实例。

巨杉分布式数据库通过行引擎存储结构化业务数据及索引元数据信息，通过块引擎存储非结构化数据，基于 PC 服务器实现数据容量的按需扩展。通过多模引擎，可针对具有业务关联关系的结构化与非结构化数据进行统一的生命周期管理，例如：将近 1 a 的业务数据（结构化、非结构化）统一存储在 SSD（固态盘）组成的高性能服务器上，满足高并发、低延时数据访问需求；将超过 1 a 的业务数据（结构化、非结构化）存储在大容量 SATA 盘（串行 ATA）组成的物理服务器上，实现历史数据存储与归档，而数据的分布对应用系统完全透明。

在计算层：对于结构化数据，通过对等多主的SQL 实例组，实现数据库计算能力的弹性伸缩、负载分担和无状态切换，应对瞬时峰值业务压力下高并发数据库负载；对于非结构化数据，提供原生 API或 S3 对象访问协议，实现高性能并发数据写入。

3 主流数据库比较

达梦、金仓、神通等数据库作为最早研发的国产数据库，有分别针对事务型、分析型的数据库产品，运行电子政务、办公类型的应用是比较成熟的，但也存在以下问题：

1）事务型数据库均为主备、主从架构，扩展能力有限，写节点为单点，对于写操作密集的业务，单个写节点压力比较大。

2）事务型数据库存储的实时数据约为 10 TB 以下，对于实时数据量比较大的业务可能存在性能问题。

OceanBase 和 TBase 等支持分布式部署的数据库在数据库架构、性能、海量数据管理方面都比较有优势，但由于这类数据库最初是针对互联网应用设计的，部分数据库存在以下一些问题：对服务器配置及网络环境要求比较高；ODBC（Open-DataBase-Connectivity）接口兼容不太友好；针对Oracle 移植的情况，如复杂查询、触发器改写工作量比较大；其他一些功能支持不太好，如函数索引、游标等。

4 水利行业数据库选型及改造建议

水利行业数据库选型的考虑因素如下：

1）考虑到目前大多数水利应用采用 Oracle 数据库，建议选型时考虑国产数据库对 Oracle 的兼容性，降低移植改造难度。目前大部分国产数据库都兼容 SQL92/99 等标准语法，支持国产和国外主流操作系统，但对 Oracle 兼容方面有所差别，需要根据应用情况进行确认。

2）选型时不仅要考虑数据库的功能和性能，还要考虑备份、监控、管理工具等周边生态问题。大部分水利部门已经建设了成熟的系统监控、备份、管理机制，如何将新的国产数据库融入管理机制中，减少运维管理的工作量，是用好国产数据库的重要因素。

3）数据库是核心的水利基础设施，通常有很长的生命周期，在选型过程中要根据水利业务需求选择适应的产品，既不能过度追求大而全的产品，也不能过度选择太多专项产品，增加学习成本，给开发和运维带来难度，建议适当选择通用型数据库产品作为水利行业核心数据库，必要时补充专项数据库。

具体的应用分类及数据库选型建议如表1 所示。

表1 应用分类及数据库选型表

水利行业国产数据库迁移改造建议如下：

1）改造过程中建议采用 ORM 框架等技术屏蔽数据库语法差异，减少应用移植的工作量，需要编写的 SQL 应采用标准 SQL 语法，以减少数据库的依赖性。

2）由于水利行业数据库的复杂性和重要性，建议在进行国产数据库改造应用时，首先考虑非核心业务，通过非核心业务系统改造、运行和磨合，使应用及运维部门可以更好地了解新数据库，然后逐步将重要性更高的数据库迁移到新数据库。

3）对于核心业务系统的国产化改造，建议设置双库并轨试运行阶段，在试运行阶段通过应用或工具将每份数据写入 2 个数据库，定期验证数据一致性，降低改造带来的风险。

5 结语

近 2 a 来，水利信息产业积极推进国产化工作，水利部机关、各流域都逐步将原有数据库迁移到国产数据库中。

传统国产数据库通过主备架构实现数据库高可用和读写分离，可基本满足水利行业 10 TB 以下OLTP（联机事务处理）场景及 50 TB 以下 OLAP（联机分析处理）场景的数据库业务需求，如电子政务、综合办公等常规业务。但主备架构的技术实现方式，不适用于海量数据管理的场景；部分国产分布式数据库通过 Paxos 等协议实现节点间一致性复制及数据库的高可用，但是分布式数据库目前存在复杂多表关联、查询速度慢、对触发器支持不完善等问题，有待于进一步完善。此外，分布式数据库支持跨地域的多活部署，目前水利行业此类需求不多，后续随着此类需求的增多，还要对跨地域部署的技术进行验证和分析。

综上所述，水利行业在国产数据库选型时要结合不同的业务场景，综合功能、性能、成本等多个因素选择合适的数据库，在实施改造过程中遵循系统工程原则考虑改造难度、成本、时间、风险等因素逐步推进。