陳真玄 ，張 怡 ，楊 柳 ，孟慶學(xué)

（1.水利部信息中心，北京 100053；2.北京金水信息技術(shù)發(fā)展有限公司，北京 100053；3.北京沛?？萍加邢薰荆本?100083）

0 引言

在當(dāng)前國(guó)際新形勢(shì)下，信息產(chǎn)業(yè)推進(jìn)國(guó)產(chǎn)化的意義之一是避免核心技術(shù)受制于人，保障網(wǎng)絡(luò)安全乃至國(guó)家安全?！昂烁呋毖芯咳蝿?wù)中的“基”指以數(shù)據(jù)庫、操作系統(tǒng)等為核心的基礎(chǔ)軟件產(chǎn)品，其中數(shù)據(jù)庫作為數(shù)據(jù)存取、管理和應(yīng)用的核心工具，決定了 IT 系統(tǒng)運(yùn)行處理數(shù)據(jù)的高效性，數(shù)據(jù)庫的國(guó)產(chǎn)化替代是信息產(chǎn)業(yè)國(guó)產(chǎn)化進(jìn)程的重要瓶頸，數(shù)據(jù)庫國(guó)產(chǎn)化是保障網(wǎng)絡(luò)和國(guó)家安全的必然要求[1]266。

目前，全球主流數(shù)據(jù)庫產(chǎn)品中，Oracle，DB2，MySQL 等仍占據(jù)大部分的市場(chǎng)份額，在國(guó)內(nèi)市場(chǎng)，特別在數(shù)據(jù)庫最核心的交易業(yè)務(wù)中，很少能有跟Oracle 旗鼓相當(dāng)?shù)漠a(chǎn)品。中國(guó) 2 000 多家銀行，核心交易系統(tǒng)大多采用 Oracle 或 DB2 的數(shù)據(jù)庫管理軟件。盡管國(guó)內(nèi)數(shù)據(jù)庫產(chǎn)品也逐漸趨于成熟，但目前主要應(yīng)用于電子政務(wù)和公文流轉(zhuǎn)等數(shù)據(jù)量不太大、交易查詢簡(jiǎn)單的常規(guī)業(yè)務(wù)中，仍然無法進(jìn)入核心交易領(lǐng)域，如銀行、電信、能源、稅務(wù)等領(lǐng)域[2]。

數(shù)據(jù)庫國(guó)產(chǎn)化的難點(diǎn)在于：當(dāng)前 IT 系統(tǒng)運(yùn)行多年，許多對(duì)數(shù)據(jù)可靠性要求較高的、業(yè)務(wù)應(yīng)用較復(fù)雜的系統(tǒng)長(zhǎng)期以來對(duì) Oracle 和 DB2 等數(shù)據(jù)庫形成依賴，包括政府機(jī)構(gòu)、大型企業(yè)、銀行證券等。此外，國(guó)產(chǎn)化改造時(shí)，部分業(yè)務(wù)系統(tǒng)還需要改寫數(shù)據(jù)庫連接接口，調(diào)整查詢語句的寫法，修改原有數(shù)據(jù)庫觸發(fā)器及函數(shù)等。因此如何進(jìn)行國(guó)產(chǎn)數(shù)據(jù)庫的選型，如何在國(guó)產(chǎn)化改造時(shí)減少對(duì)業(yè)務(wù)系統(tǒng)的影響，盡可能地實(shí)現(xiàn)國(guó)產(chǎn)數(shù)據(jù)庫的平滑遷移，都是數(shù)據(jù)庫國(guó)產(chǎn)化進(jìn)程中將會(huì)面臨的問題[1]266。

目前水利部機(jī)關(guān)正在積極推進(jìn)，逐步將業(yè)務(wù)由Oracle 等國(guó)外數(shù)據(jù)庫遷移到國(guó)產(chǎn)數(shù)據(jù)庫上，為此分析國(guó)產(chǎn)數(shù)據(jù)庫的主要技術(shù)路線，以期為水利行業(yè)國(guó)產(chǎn)數(shù)據(jù)庫的選型提供一些參考建議。

1 國(guó)產(chǎn)數(shù)據(jù)庫主要技術(shù)路線

根據(jù)數(shù)據(jù)庫國(guó)產(chǎn)化與信息安全的總體規(guī)劃要求，國(guó)產(chǎn)數(shù)據(jù)庫產(chǎn)業(yè)發(fā)展提速，呈現(xiàn)出百花齊放的景象，國(guó)內(nèi)典型的數(shù)據(jù)庫產(chǎn)品有達(dá)夢(mèng)、金倉、南大通用、神舟通用、瀚高等數(shù)據(jù)庫。

此外，隨著水利信息化的快速發(fā)展，引發(fā)了數(shù)據(jù)量的迅猛增長(zhǎng)，國(guó)內(nèi)部分?jǐn)?shù)據(jù)庫廠商、尤其是大型互聯(lián)網(wǎng)廠商開發(fā)出分布式架構(gòu)的數(shù)據(jù)庫系統(tǒng)，具有在線彈性擴(kuò)容、高并發(fā)支持等能力。OceanBase和 TBase 等分布式關(guān)系數(shù)據(jù)庫，具有數(shù)據(jù)強(qiáng)一致、高可用、高性能、在線擴(kuò)展、高度兼容 SQL 標(biāo)準(zhǔn)等特點(diǎn)；GaussDB 采用 MPP（大規(guī)模并行處理）架構(gòu)，支持行與列的存儲(chǔ)，提供 PB 級(jí)別數(shù)據(jù)量的處理能力；RDS MySQL 等云數(shù)據(jù)庫架構(gòu)產(chǎn)品可根據(jù)云租戶需求，靈活部署于虛擬機(jī)、云服務(wù)器；分布式架構(gòu)的 Taurus 數(shù)據(jù)庫具備可彈性擴(kuò)展、高可靠性、高 I/O 吞吐能力等特點(diǎn)[1]267。

1.1 主從架構(gòu)

達(dá)夢(mèng)、瀚高等數(shù)據(jù)庫為提升數(shù)據(jù)處理能力，在水平擴(kuò)展方面通常采用主從架構(gòu)，通過讀寫分離的方式，將混合負(fù)載中的讀操作切換到備數(shù)據(jù)庫（以下簡(jiǎn)稱備庫），降低主數(shù)據(jù)庫（以下簡(jiǎn)稱主庫）壓力，提高主庫事務(wù)處理能力，通過 1 個(gè)或多個(gè)只讀備庫處理更多的查詢請(qǐng)求。

主從架構(gòu)主要應(yīng)用于實(shí)時(shí)備份、容災(zāi)和讀寫分離等場(chǎng)景，具體架構(gòu)如圖1 所示。

圖1 主從架構(gòu)

主庫讀取日志進(jìn)程獲取數(shù)據(jù)庫的日志，然后通過異步或同步復(fù)制等方式將其傳送給備庫，備庫收到日志并完成應(yīng)用，使主備庫數(shù)據(jù)一致。同步復(fù)制方式，在主庫提交事務(wù)后會(huì)等待備庫收到日志并完成日志應(yīng)用，才返回事務(wù)提交通知給客戶端；異步復(fù)制方式，主庫提交事務(wù)后即刻給客戶端返回事務(wù)提交通知，讀取日志進(jìn)程異步進(jìn)行數(shù)據(jù)復(fù)制，然后應(yīng)用到備庫；半同步方式，介于同步復(fù)制和異步復(fù)制之間，是指在多個(gè)備庫情況下，部分備庫（至少1 個(gè)備庫）提交或收到主庫日志后，主庫才能返回事務(wù)提交通知給客戶端，在主備庫網(wǎng)絡(luò)不通或備庫發(fā)生故障時(shí)，備庫返回超時(shí)，主庫可以降級(jí)為異步模式，避免阻塞主庫。

同步復(fù)制方式，由于備庫提交事務(wù)后才能返回給客戶端，因此主庫和備庫的數(shù)據(jù)是一致的，主庫發(fā)生故障時(shí)備庫不會(huì)丟失數(shù)據(jù)，但是如果網(wǎng)絡(luò)問題導(dǎo)致日志傳送發(fā)生問題或備庫發(fā)生故障，也會(huì)導(dǎo)致主庫被阻塞，影響主庫運(yùn)行；異步復(fù)制方式，網(wǎng)絡(luò)或備庫發(fā)生故障不會(huì)影響主庫運(yùn)行，但是如果主庫發(fā)生故障，此時(shí)備庫和主庫的數(shù)據(jù)是不一致的，備庫會(huì)丟失部分最新數(shù)據(jù)。

目前達(dá)夢(mèng)、瀚高等傳統(tǒng)數(shù)據(jù)庫都支持主從模式，生產(chǎn)環(huán)境中建議采用半同步或異步方式部署，在數(shù)據(jù)一致性和可用性之間進(jìn)行合理的均衡。

1.2 分布式架構(gòu)

分布式數(shù)據(jù)庫是指數(shù)據(jù)分散于多個(gè)節(jié)點(diǎn)而構(gòu)成的邏輯統(tǒng)一的數(shù)據(jù)庫，通常有 NoSQL，MPP 和支持事務(wù)的 NewSQL 等數(shù)據(jù)庫，本研究只討論 NewSQL數(shù)據(jù)庫。

分布式數(shù)據(jù)庫的主要特點(diǎn)如下：

1）支持事務(wù)，分布式數(shù)據(jù)庫可實(shí)現(xiàn)數(shù)據(jù)庫事務(wù)的原子性、一致性、隔離性和持久性；

2）高可用性，是指分布式數(shù)據(jù)庫通過多節(jié)點(diǎn)數(shù)據(jù)冗余實(shí)現(xiàn)高可用，其中 1 個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，其他冗余節(jié)點(diǎn)也可以提供服務(wù)，部分?jǐn)?shù)據(jù)庫還能實(shí)現(xiàn)跨地域的高可用；

3）可擴(kuò)展性，分為節(jié)點(diǎn)內(nèi)增加系統(tǒng)資源的垂直擴(kuò)展和節(jié)點(diǎn)數(shù)量的水平擴(kuò)展等方式，分布式數(shù)據(jù)庫能夠通過增加節(jié)點(diǎn)數(shù)量水平擴(kuò)展數(shù)據(jù)庫容量和處理性能。

1.2.1 數(shù)據(jù)同步及一致性

數(shù)據(jù)同步實(shí)現(xiàn)分布式數(shù)據(jù)庫的節(jié)點(diǎn)數(shù)據(jù)冗余，實(shí)現(xiàn)數(shù)據(jù)多份存儲(chǔ)，并且保持一致性。數(shù)據(jù)庫可以從不同節(jié)點(diǎn)訪問此數(shù)據(jù)，消除數(shù)據(jù)存儲(chǔ)的單點(diǎn)問題，避免數(shù)據(jù)丟失，進(jìn)而增強(qiáng)系統(tǒng)可用性。

CAP 定理[3]證明了在一個(gè)分布式系統(tǒng)中一致性（Consistency）、可用性（Availability）、分區(qū)容錯(cuò)性（Partition Tolerance）三者不可兼得：

1）一致性。一致性是指在同一時(shí)間點(diǎn)，保存在多個(gè)節(jié)點(diǎn)的同一份數(shù)據(jù)是相同的，此處的一致性是指分布一致性，通常分為強(qiáng)、弱和最終一致性，有別于數(shù)據(jù)庫事務(wù)的一致性。

2）可用性?？捎眯允侵阜植际较到y(tǒng)中部分節(jié)點(diǎn)發(fā)生故障，系統(tǒng)仍然能夠繼續(xù)提供服務(wù)。

3）分區(qū)容錯(cuò)性。分區(qū)容錯(cuò)性是指網(wǎng)絡(luò)通常是不可靠的，分布式系統(tǒng)在發(fā)生網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)無法訪問，整個(gè)系統(tǒng)被分成多個(gè)區(qū)域時(shí)，系統(tǒng)仍然能夠提供服務(wù)。

在分布式系統(tǒng)中，網(wǎng)絡(luò)分區(qū)是無法避免的，分布式系統(tǒng)根據(jù)需求可以選擇 CP 或 AP 2 種模式：CP指保證一致性，發(fā)生分區(qū)后部分節(jié)點(diǎn)不可訪問，但可訪問節(jié)點(diǎn)返回?cái)?shù)據(jù)是一致的；AP 指保證可用性，發(fā)生分區(qū)后所有節(jié)點(diǎn)都可以訪問，但不是所有節(jié)點(diǎn)的數(shù)據(jù)都是最新的，數(shù)據(jù)不是最新的節(jié)點(diǎn)通常在網(wǎng)絡(luò)恢復(fù)后同步為最新數(shù)據(jù)，保持一致性，此為最終一致性（BASE）。

分布式數(shù)據(jù)庫通常選擇 CP 即保證一致性，實(shí)現(xiàn)一致性的協(xié)議主要有 Paxos[4]，Raft，Zab 等。

Paxos 及其變種 Raft 協(xié)議是常見的半同步一致性/共識(shí)協(xié)議。Paxos 實(shí)現(xiàn)了在可能發(fā)生節(jié)點(diǎn)/進(jìn)程異?；蚓W(wǎng)絡(luò)故障的分布式系統(tǒng)中，多個(gè)節(jié)點(diǎn)如何對(duì) 1 個(gè)問題達(dá)成一致。Paxos 有提議發(fā)起者、接收者和學(xué)習(xí)者 3 個(gè)角色，通過提議是 1 個(gè)兩階段過程，即準(zhǔn)備和批準(zhǔn) 2 個(gè)階段，只有多數(shù)接收者收到并批準(zhǔn)發(fā)起者的提議，整個(gè)提議才能提交成功。分布式數(shù)據(jù)庫采用此算法解決多節(jié)點(diǎn)副本一致性的問題。

1 個(gè)兩階段過程每次只處理 1 個(gè)提議，如果需要處理多個(gè)連續(xù)提議則需要多個(gè)兩階段處理過程，成本比較高，另外多個(gè)提議發(fā)起者也會(huì)存在沖突問題。

OceanBase 等分布式數(shù)據(jù)庫實(shí)現(xiàn) Paxos 時(shí)使用Multi-Paxos，Multi-Paxos 引入 Leader 角色，簡(jiǎn)化了準(zhǔn)備過程，提議節(jié)點(diǎn)通過上述的準(zhǔn)備和批準(zhǔn)階段，在網(wǎng)絡(luò)中廣播競(jìng)選 Leader 請(qǐng)求，獲得批準(zhǔn)后成為 Leader 節(jié)點(diǎn)，其他節(jié)點(diǎn)為 Follower 節(jié)點(diǎn)。只有Leader 節(jié)點(diǎn)能夠提出提議，因此 Leader 節(jié)點(diǎn)提出提議不需要準(zhǔn)備過程獲取提議權(quán)，其連續(xù)的提議都是對(duì)同一提議編號(hào)的多個(gè)批準(zhǔn)過程，所以只需要接收者批準(zhǔn)即可。從客戶端角度看，Leader 節(jié)點(diǎn)對(duì)外提供強(qiáng)一致的讀寫操作，F(xiàn)ollower 節(jié)點(diǎn)負(fù)責(zé)投票，不提供讀寫或只提供弱一致的只讀服務(wù)。

TiDB 等數(shù)據(jù)庫采用 Paxos 變種協(xié)議 Raft[5]，Raft 簡(jiǎn)化了 Paxos 協(xié)議，實(shí)現(xiàn)與 Multi-Paxos 相同的功能，Raft 基于多副本復(fù)制狀態(tài)機(jī)構(gòu)建，狀態(tài)機(jī)把指令以日志方式持久化通過執(zhí)行指令進(jìn)行更新，所有節(jié)點(diǎn)從同一個(gè)狀態(tài)開始，節(jié)點(diǎn)間同步指令，各節(jié)點(diǎn)復(fù)制狀態(tài)機(jī)按順序執(zhí)行相同指令，達(dá)到相同狀態(tài)。Leader 節(jié)點(diǎn)接受請(qǐng)求，將其數(shù)據(jù)變更指令追加到自己的日志中，同時(shí)向其他 Follower 節(jié)點(diǎn)發(fā)送追加條目請(qǐng)求，當(dāng)這個(gè)指令被大多數(shù) Follower 節(jié)點(diǎn)復(fù)制寫入其日志后，Leader 節(jié)點(diǎn)收到其寫入完成反饋就將這條指令應(yīng)用于狀態(tài)機(jī)，此記錄為已提交，然后返回給客戶端，如果部分節(jié)點(diǎn)由于故障無法同步日志，Leader 節(jié)點(diǎn)會(huì)在后臺(tái)異步重試發(fā)送追加條目請(qǐng)求直至成功，使所有節(jié)點(diǎn)數(shù)據(jù)一致。

TBase 數(shù)據(jù)庫目前版本采用的是主備同步或異步復(fù)制技術(shù)。

1.2.2 分布式事務(wù)

分布式事務(wù)的實(shí)現(xiàn)有兩階段提交（2PC）[6]、三階段提交（3PC）和 TCC（Try Confirm Cancel）、消息隊(duì)列等多種方式，滿足事務(wù)的 ACID（Atomicity，Consistency，Isolation，Durability）是分布式數(shù)據(jù)庫的核心要求，2PC 是分布式數(shù)據(jù)庫實(shí)現(xiàn)事務(wù)原子性和一致性的常見方式。

2PC 是一個(gè)中心化且滿足事務(wù)一致性的協(xié)議，有協(xié)調(diào)者和參與者 2 類節(jié)點(diǎn)：

1）協(xié)調(diào)者。協(xié)調(diào)者與所有參與者通信并控制其操作，從而完成全局事務(wù)。

2）參與者。作為全局事務(wù)的一部分，負(fù)責(zé)節(jié)點(diǎn)本地的事務(wù)提交或回滾。

2PC 的準(zhǔn)備階段，由協(xié)調(diào)節(jié)點(diǎn)向參與節(jié)點(diǎn)發(fā)送事務(wù)預(yù)處理請(qǐng)求，由其投票決定事務(wù)能否提交，如果所有節(jié)點(diǎn)回復(fù)能夠提交事務(wù)，則進(jìn)入提交階段。在提交階段，協(xié)調(diào)者通知參與者提交事務(wù)：如果所有參與者都提交成功并通知協(xié)調(diào)節(jié)點(diǎn)，則全局事務(wù)提交成功；如有參與者提交失敗，協(xié)調(diào)節(jié)點(diǎn)則發(fā)送回滾請(qǐng)求，讓參與者回滾事務(wù)。

2PC 存在同步阻塞、單點(diǎn)故障及數(shù)據(jù)不一致等問題。針對(duì)問題，通過增加額外的可提交通信階段，并對(duì)協(xié)調(diào)者和參與者都引入超時(shí)機(jī)制可解決單點(diǎn)故障問題，此為 3PC 協(xié)議。由于 3PC 會(huì)明顯降低事務(wù)性能，增加復(fù)雜性且無法解決數(shù)據(jù)不一致問題，因此較少采用。

另一種方式是在 Paxos/Raft 一致性協(xié)議基礎(chǔ)上運(yùn)行 2PC 協(xié)議，利用 Paxos 等協(xié)議使事務(wù)的信息都復(fù)制到副本節(jié)點(diǎn)，任何 1 個(gè)節(jié)點(diǎn)宕機(jī)都可通過 Paxos等協(xié)議很快選舉出另外 1 個(gè)副本節(jié)點(diǎn)代替原來節(jié)點(diǎn)，恢復(fù)原有事務(wù)狀態(tài)繼續(xù)完成事務(wù)，此種方式引入Paxos 等協(xié)議增加了復(fù)雜性和延遲，降低了性能。

在分布式數(shù)據(jù)庫的設(shè)計(jì)中都對(duì) 2PC 協(xié)議進(jìn)行了優(yōu)化和改進(jìn)，采用 Paxos 協(xié)議的 Oceanbase 和 Raft協(xié)議的 TiDB，利用多副本機(jī)制避免節(jié)點(diǎn)故障帶來的單點(diǎn)問題。Oceanbase 等數(shù)據(jù)庫采用協(xié)調(diào)者無狀態(tài)的方式，協(xié)調(diào)者不記錄事務(wù)狀態(tài)，當(dāng)協(xié)調(diào)者發(fā)生故障時(shí)，通過所有參與者的本地狀態(tài)生成事務(wù)全局狀態(tài)，避免無狀態(tài)帶來影響，弱化傳統(tǒng) 2PC 中協(xié)調(diào)者中心化帶來的問題，同時(shí)減少事務(wù)的時(shí)間延遲。

隔離是數(shù)據(jù)庫事務(wù)的另一個(gè)要素，常用的隔離級(jí)別包括 Read Committed，Repeatable Read，Serializable 等，假設(shè) 2 個(gè)事務(wù)t1和t2，只有t1的開始時(shí)間大于t2的提交時(shí)間，t1才能看到t2的修改，這才符合事務(wù)隔離要求。Oracle 等數(shù)據(jù)庫通常采用 MVCC（Multi-Vesion Concurrency Control）技術(shù)保證寫不阻塞，讀實(shí)現(xiàn) Snapshot[7]隔離級(jí)別，提供高并發(fā)事務(wù)處理能力，大部分?jǐn)?shù)據(jù)庫都支持Read Committed 和 Repeatable Read 的隔離級(jí)別。Serializable 是最嚴(yán)格的隔離級(jí)別，在 Serializable 隔離級(jí)別中事務(wù)按照順序串行并發(fā)執(zhí)行。Oracle 等數(shù)據(jù)庫通過 2PL（Two-phase Locking）全程加鎖的方式實(shí)現(xiàn) Serializable 隔離級(jí)別，以防止事務(wù)期間訪問的數(shù)據(jù)被其他事務(wù)修改，這種方式讀寫相互阻塞，效率較低，所以即使數(shù)據(jù)庫支持也很少采用。

Google Spanner[8]數(shù)據(jù)庫利用硬件實(shí)現(xiàn)全局時(shí)鐘，提供外部一致性，通過 2PL 實(shí)現(xiàn) Serializable隔離級(jí)別；TBase 分布式數(shù)據(jù)庫通過軟件生成全局邏輯時(shí)鐘，結(jié)合 MVCC 多版本機(jī)制、2PC 和 SSI（Serializable Snapshot Isolation）實(shí)現(xiàn) Snapshot 隔離級(jí)別。

2 主流國(guó)產(chǎn)數(shù)據(jù)庫介紹

目前達(dá)夢(mèng)、金倉、神舟通用、瀚高等主流國(guó)產(chǎn)數(shù)據(jù)庫已經(jīng)逐步建立較為完善的生態(tài)環(huán)境，不僅可以兼容原來市場(chǎng)上占主導(dǎo)地位的 Intel 芯片，也可兼容鯤鵬、飛騰、海光等主流國(guó)產(chǎn)芯片，不僅可以適配 Linux 和 Windows 操作系統(tǒng)，也可適配麒麟、統(tǒng)信等主流國(guó)產(chǎn)操作系統(tǒng)，以及東方通、中創(chuàng)、金蝶等主流國(guó)產(chǎn)中間件，并且各個(gè)廠商還在以更快的速度推進(jìn)國(guó)產(chǎn)環(huán)境的適配驗(yàn)證工作。

2.1 達(dá)夢(mèng)數(shù)據(jù)庫

達(dá)夢(mèng)數(shù)據(jù)庫管理系統(tǒng)是具有完全自主知識(shí)產(chǎn)權(quán)的高性能數(shù)據(jù)庫管理系統(tǒng)，最新版本是 8.0 版本，簡(jiǎn)稱 DM8。

DM8 數(shù)據(jù)庫支持各種國(guó)際和國(guó)內(nèi)相關(guān)標(biāo)準(zhǔn)，具有高性能、高可靠性和易用性，支持多 CPU，支持TB 級(jí)以上的數(shù)據(jù)和大并發(fā)量用戶，支持集群；可支撐大、中型企業(yè)和政府部門應(yīng)用，為關(guān)鍵任務(wù)的應(yīng)用程序提供高效、可靠、安全的數(shù)據(jù)管理，可滿足黨政機(jī)關(guān)、企事業(yè)單位的各種應(yīng)用需求。

2.2 金倉數(shù)據(jù)庫

金倉數(shù)據(jù)庫（KingbaseES）是有自主知識(shí)產(chǎn)權(quán)的通用關(guān)系型數(shù)據(jù)庫管理系統(tǒng)。

金倉數(shù)據(jù)庫主要面向事務(wù)處理類應(yīng)用，兼顧各類數(shù)據(jù)分析類應(yīng)用，可用做管理信息、業(yè)務(wù)及生產(chǎn)、決策支持等系統(tǒng)，以及多維數(shù)據(jù)分析、全文檢索、地理信息系統(tǒng)、圖片搜索等的承載數(shù)據(jù)庫。

金倉數(shù)據(jù)庫的最新版本為 KingbaseES V8，KingbaseES V8 在系統(tǒng)的可靠性、可用性、性能和兼容性等方面進(jìn)行了重大改進(jìn)，支持多種操作系統(tǒng)和硬件平臺(tái)，支持 Unix，Linux 和 Windows 等數(shù)十個(gè)操作系統(tǒng)產(chǎn)品版本，支持 X86，X86_64，以及國(guó)產(chǎn)龍芯、飛騰、申威等 CPU 硬件體系結(jié)構(gòu)，并具備與這些版本服務(wù)器和管理工具之間的無縫互操作能力。

2.3 神舟通用數(shù)據(jù)庫

神州通用數(shù)據(jù)庫基于產(chǎn)品組合，可形成支持交易處理、MPP 數(shù)據(jù)庫集群、數(shù)據(jù)分析與處理等解決方案，可滿足多種應(yīng)用場(chǎng)景需求。產(chǎn)品通過了國(guó)家保密局涉密信息系統(tǒng)、公安部等保四級(jí)等安全評(píng)測(cè)和認(rèn)證。

2.4 瀚高數(shù)據(jù)庫

瀚高數(shù)據(jù)庫引進(jìn)開源數(shù)據(jù)庫 PostgreSQL 內(nèi)核技術(shù)，在 PostgreSQL 社區(qū)版之上做了一系列的研發(fā)和優(yōu)化。

瀚高數(shù)據(jù)庫完全符合 ACID 原則，支持外鍵、連接、視圖、觸發(fā)器、存儲(chǔ)過程（多種程序語言）等功能，具有高效的并發(fā)控制機(jī)制，能夠支持 TB 級(jí)海量存儲(chǔ)，具有完善的備份恢復(fù)機(jī)制。可與 Oracle數(shù)據(jù)庫擁有完美兼容性，使得用戶現(xiàn)有的基于Oracle 數(shù)據(jù)庫平臺(tái)開發(fā)的應(yīng)用程序，無需做任何修改或只做少量修改便可運(yùn)行在瀚高數(shù)據(jù)庫上，從而實(shí)現(xiàn)高效快捷的應(yīng)用遷移。瀚高數(shù)據(jù)庫擁有多層安全防護(hù)機(jī)制，能夠從訪問控制、數(shù)據(jù)加密、數(shù)據(jù)完整性等多個(gè)維度，最大程度地保障數(shù)據(jù)庫訪問及數(shù)據(jù)存儲(chǔ)的安全。

2.5 OceanBase 數(shù)據(jù)庫

OceanBase 數(shù)據(jù)庫是完全自主研發(fā)的金融級(jí)分布式關(guān)系數(shù)據(jù)庫，具體架構(gòu)特點(diǎn)如下：

1）多副本。一般部署為 3/5 個(gè) Zone，每個(gè)Zone 由多個(gè)服務(wù)器節(jié)點(diǎn)組成。

2）對(duì)等節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)均有自己的 SQL 和存儲(chǔ)引擎，自主管理各自承載的數(shù)據(jù)分區(qū)，TCP/IP 互通，協(xié)同服務(wù)。

3）無需存儲(chǔ)設(shè)備共享。數(shù)據(jù)分布在各個(gè)節(jié)點(diǎn)上，不基于任何設(shè)備級(jí)共享存儲(chǔ)技術(shù)，不需要 SAN（Storage Area Network）網(wǎng)絡(luò)；消除了單點(diǎn)，每個(gè)節(jié)點(diǎn)都具有完備處理能力，能管理本節(jié)點(diǎn)上的數(shù)據(jù)。

4）分區(qū)級(jí)可用性。分區(qū)是可靠性與擴(kuò)展性的基本單元，自動(dòng)實(shí)現(xiàn)訪問路由、策略驅(qū)動(dòng)負(fù)載均衡、自主故障恢復(fù)。

5）高可用 + 強(qiáng)一致。多副本 + Paxos 分布式協(xié)議的高效高可靠工程實(shí)現(xiàn)，確保數(shù)據(jù)（日志）持久化在多數(shù)派節(jié)點(diǎn)成功。

2.6 TBase 數(shù)據(jù)庫

TBase 數(shù)據(jù)庫是自主研發(fā)的分布式數(shù)據(jù)庫系統(tǒng)，集高擴(kuò)展性、高 SQL 兼容度、完整的分布式事務(wù)支持、多級(jí)容災(zāi)及多維度資源隔離等能力于一體。TBase 采用無共享的集群架構(gòu)，適用于 GB～PB級(jí)的海量 HTAP（Hybrid Transaction and Analytical Process）場(chǎng)景。

TBase 數(shù)據(jù)庫集群架構(gòu)主要由以下 3 個(gè)部分組成：

1）CN。即協(xié)調(diào)節(jié)點(diǎn)，對(duì)外提供接口，負(fù)責(zé)數(shù)據(jù)的分發(fā)和查詢規(guī)劃，多個(gè)節(jié)點(diǎn)位置對(duì)等，每個(gè)節(jié)點(diǎn)都提供相同的數(shù)據(jù)庫視圖。在功能上 CN 只存儲(chǔ)系統(tǒng)的全局元數(shù)據(jù)，并不存儲(chǔ)實(shí)際的業(yè)務(wù)數(shù)據(jù)。

2）DN。即 Datanode，用于處理存儲(chǔ)本節(jié)點(diǎn)相關(guān)的元數(shù)據(jù)，每個(gè)節(jié)點(diǎn)還存儲(chǔ)業(yè)務(wù)數(shù)據(jù)的分片。在功能上，DN 節(jié)點(diǎn)負(fù)責(zé)完成執(zhí)行協(xié)調(diào)節(jié)點(diǎn)分發(fā)的執(zhí)行請(qǐng)求。

3）GTM。即全局事務(wù)管理器，主要做分布式事務(wù)，負(fù)責(zé)管理集群事務(wù)信息，同時(shí)管理集群的全局對(duì)象，如序列等，不提供其他功能。

TBase 數(shù)據(jù)庫的架構(gòu)優(yōu)點(diǎn)如下：

1）多活/多主。每個(gè)協(xié)調(diào)節(jié)點(diǎn)提供相同的集群視圖，可以從任何 1 個(gè) CN 寫入，業(yè)務(wù)無需感知集群拓?fù)洹?/p>

2）讀/寫擴(kuò)展。數(shù)據(jù)被分片存儲(chǔ)在不同的 DN上，集群的讀/寫能力隨著集群規(guī)模的擴(kuò)大而得到提升。

3）集群寫一致。業(yè)務(wù)在 1 個(gè) CN 節(jié)點(diǎn)發(fā)生的寫事務(wù)會(huì)一致性地呈現(xiàn)在其他 CN 節(jié)點(diǎn)，就像這些事務(wù)是本 CN 節(jié)點(diǎn)發(fā)生的一樣。

4）集群結(jié)構(gòu)透明。數(shù)據(jù)位于不同的數(shù)據(jù)庫節(jié)點(diǎn)中，查詢數(shù)據(jù)時(shí)，不必關(guān)心數(shù)據(jù)位于的具體節(jié)點(diǎn)。

2.7 巨杉數(shù)據(jù)庫

巨杉數(shù)據(jù)庫是新一代國(guó)產(chǎn)原生分布式數(shù)據(jù)庫，采用多模數(shù)據(jù)庫存儲(chǔ)引擎，實(shí)現(xiàn)結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一存儲(chǔ)管理。巨杉數(shù)據(jù)庫作為金融級(jí)分布式數(shù)據(jù)庫系統(tǒng)，已經(jīng)在國(guó)內(nèi)超過 50 家銀行和近百家金融機(jī)構(gòu)的生產(chǎn)環(huán)境中上線運(yùn)行，擁有目前國(guó)內(nèi)金融領(lǐng)域規(guī)模最大的獨(dú)立分布式數(shù)據(jù)集群。

巨杉數(shù)據(jù)庫基于“計(jì)算-存儲(chǔ)”分離架構(gòu)，可滿足數(shù)據(jù)存儲(chǔ)容量按需擴(kuò)展和數(shù)據(jù)庫計(jì)算能力彈性伸縮的需求。巨杉分布式數(shù)據(jù)庫支持分布式事務(wù) ACID，提供原生 API 訪問接口，并兼容標(biāo)準(zhǔn)MySQL，MonggoDB，PostgreSQL，MariaDB，SparkSQL，S3 對(duì)象訪問等多種結(jié)構(gòu)化和非結(jié)構(gòu)化計(jì)算層實(shí)例。

巨杉分布式數(shù)據(jù)庫通過行引擎存儲(chǔ)結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)及索引元數(shù)據(jù)信息，通過塊引擎存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)，基于 PC 服務(wù)器實(shí)現(xiàn)數(shù)據(jù)容量的按需擴(kuò)展。通過多模引擎，可針對(duì)具有業(yè)務(wù)關(guān)聯(lián)關(guān)系的結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行統(tǒng)一的生命周期管理，例如：將近 1 a 的業(yè)務(wù)數(shù)據(jù)（結(jié)構(gòu)化、非結(jié)構(gòu)化）統(tǒng)一存儲(chǔ)在 SSD（固態(tài)盤）組成的高性能服務(wù)器上，滿足高并發(fā)、低延時(shí)數(shù)據(jù)訪問需求；將超過 1 a 的業(yè)務(wù)數(shù)據(jù)（結(jié)構(gòu)化、非結(jié)構(gòu)化）存儲(chǔ)在大容量 SATA 盤（串行 ATA）組成的物理服務(wù)器上，實(shí)現(xiàn)歷史數(shù)據(jù)存儲(chǔ)與歸檔，而數(shù)據(jù)的分布對(duì)應(yīng)用系統(tǒng)完全透明。

在計(jì)算層：對(duì)于結(jié)構(gòu)化數(shù)據(jù)，通過對(duì)等多主的SQL 實(shí)例組，實(shí)現(xiàn)數(shù)據(jù)庫計(jì)算能力的彈性伸縮、負(fù)載分擔(dān)和無狀態(tài)切換，應(yīng)對(duì)瞬時(shí)峰值業(yè)務(wù)壓力下高并發(fā)數(shù)據(jù)庫負(fù)載；對(duì)于非結(jié)構(gòu)化數(shù)據(jù)，提供原生 API或 S3 對(duì)象訪問協(xié)議，實(shí)現(xiàn)高性能并發(fā)數(shù)據(jù)寫入。

3 主流數(shù)據(jù)庫比較

達(dá)夢(mèng)、金倉、神通等數(shù)據(jù)庫作為最早研發(fā)的國(guó)產(chǎn)數(shù)據(jù)庫，有分別針對(duì)事務(wù)型、分析型的數(shù)據(jù)庫產(chǎn)品，運(yùn)行電子政務(wù)、辦公類型的應(yīng)用是比較成熟的，但也存在以下問題：

1）事務(wù)型數(shù)據(jù)庫均為主備、主從架構(gòu)，擴(kuò)展能力有限，寫節(jié)點(diǎn)為單點(diǎn)，對(duì)于寫操作密集的業(yè)務(wù)，單個(gè)寫節(jié)點(diǎn)壓力比較大。

2）事務(wù)型數(shù)據(jù)庫存儲(chǔ)的實(shí)時(shí)數(shù)據(jù)約為 10 TB 以下，對(duì)于實(shí)時(shí)數(shù)據(jù)量比較大的業(yè)務(wù)可能存在性能問題。

OceanBase 和 TBase 等支持分布式部署的數(shù)據(jù)庫在數(shù)據(jù)庫架構(gòu)、性能、海量數(shù)據(jù)管理方面都比較有優(yōu)勢(shì)，但由于這類數(shù)據(jù)庫最初是針對(duì)互聯(lián)網(wǎng)應(yīng)用設(shè)計(jì)的，部分?jǐn)?shù)據(jù)庫存在以下一些問題：對(duì)服務(wù)器配置及網(wǎng)絡(luò)環(huán)境要求比較高；ODBC（Open-DataBase-Connectivity）接口兼容不太友好；針對(duì)Oracle 移植的情況，如復(fù)雜查詢、觸發(fā)器改寫工作量比較大；其他一些功能支持不太好，如函數(shù)索引、游標(biāo)等。

4 水利行業(yè)數(shù)據(jù)庫選型及改造建議

水利行業(yè)數(shù)據(jù)庫選型的考慮因素如下：

1）考慮到目前大多數(shù)水利應(yīng)用采用 Oracle 數(shù)據(jù)庫，建議選型時(shí)考慮國(guó)產(chǎn)數(shù)據(jù)庫對(duì) Oracle 的兼容性，降低移植改造難度。目前大部分國(guó)產(chǎn)數(shù)據(jù)庫都兼容 SQL92/99 等標(biāo)準(zhǔn)語法，支持國(guó)產(chǎn)和國(guó)外主流操作系統(tǒng)，但對(duì) Oracle 兼容方面有所差別，需要根據(jù)應(yīng)用情況進(jìn)行確認(rèn)。

2）選型時(shí)不僅要考慮數(shù)據(jù)庫的功能和性能，還要考慮備份、監(jiān)控、管理工具等周邊生態(tài)問題。大部分水利部門已經(jīng)建設(shè)了成熟的系統(tǒng)監(jiān)控、備份、管理機(jī)制，如何將新的國(guó)產(chǎn)數(shù)據(jù)庫融入管理機(jī)制中，減少運(yùn)維管理的工作量，是用好國(guó)產(chǎn)數(shù)據(jù)庫的重要因素。

3）數(shù)據(jù)庫是核心的水利基礎(chǔ)設(shè)施，通常有很長(zhǎng)的生命周期，在選型過程中要根據(jù)水利業(yè)務(wù)需求選擇適應(yīng)的產(chǎn)品，既不能過度追求大而全的產(chǎn)品，也不能過度選擇太多專項(xiàng)產(chǎn)品，增加學(xué)習(xí)成本，給開發(fā)和運(yùn)維帶來難度，建議適當(dāng)選擇通用型數(shù)據(jù)庫產(chǎn)品作為水利行業(yè)核心數(shù)據(jù)庫，必要時(shí)補(bǔ)充專項(xiàng)數(shù)據(jù)庫。

具體的應(yīng)用分類及數(shù)據(jù)庫選型建議如表1 所示。

表1 應(yīng)用分類及數(shù)據(jù)庫選型表

水利行業(yè)國(guó)產(chǎn)數(shù)據(jù)庫遷移改造建議如下：

1）改造過程中建議采用 ORM 框架等技術(shù)屏蔽數(shù)據(jù)庫語法差異，減少應(yīng)用移植的工作量，需要編寫的 SQL 應(yīng)采用標(biāo)準(zhǔn) SQL 語法，以減少數(shù)據(jù)庫的依賴性。

2）由于水利行業(yè)數(shù)據(jù)庫的復(fù)雜性和重要性，建議在進(jìn)行國(guó)產(chǎn)數(shù)據(jù)庫改造應(yīng)用時(shí)，首先考慮非核心業(yè)務(wù)，通過非核心業(yè)務(wù)系統(tǒng)改造、運(yùn)行和磨合，使應(yīng)用及運(yùn)維部門可以更好地了解新數(shù)據(jù)庫，然后逐步將重要性更高的數(shù)據(jù)庫遷移到新數(shù)據(jù)庫。

3）對(duì)于核心業(yè)務(wù)系統(tǒng)的國(guó)產(chǎn)化改造，建議設(shè)置雙庫并軌試運(yùn)行階段，在試運(yùn)行階段通過應(yīng)用或工具將每份數(shù)據(jù)寫入 2 個(gè)數(shù)據(jù)庫，定期驗(yàn)證數(shù)據(jù)一致性，降低改造帶來的風(fēng)險(xiǎn)。

5 結(jié)語

近 2 a 來，水利信息產(chǎn)業(yè)積極推進(jìn)國(guó)產(chǎn)化工作，水利部機(jī)關(guān)、各流域都逐步將原有數(shù)據(jù)庫遷移到國(guó)產(chǎn)數(shù)據(jù)庫中。

傳統(tǒng)國(guó)產(chǎn)數(shù)據(jù)庫通過主備架構(gòu)實(shí)現(xiàn)數(shù)據(jù)庫高可用和讀寫分離，可基本滿足水利行業(yè) 10 TB 以下OLTP（聯(lián)機(jī)事務(wù)處理）場(chǎng)景及 50 TB 以下 OLAP（聯(lián)機(jī)分析處理）場(chǎng)景的數(shù)據(jù)庫業(yè)務(wù)需求，如電子政務(wù)、綜合辦公等常規(guī)業(yè)務(wù)。但主備架構(gòu)的技術(shù)實(shí)現(xiàn)方式，不適用于海量數(shù)據(jù)管理的場(chǎng)景；部分國(guó)產(chǎn)分布式數(shù)據(jù)庫通過 Paxos 等協(xié)議實(shí)現(xiàn)節(jié)點(diǎn)間一致性復(fù)制及數(shù)據(jù)庫的高可用，但是分布式數(shù)據(jù)庫目前存在復(fù)雜多表關(guān)聯(lián)、查詢速度慢、對(duì)觸發(fā)器支持不完善等問題，有待于進(jìn)一步完善。此外，分布式數(shù)據(jù)庫支持跨地域的多活部署，目前水利行業(yè)此類需求不多，后續(xù)隨著此類需求的增多，還要對(duì)跨地域部署的技術(shù)進(jìn)行驗(yàn)證和分析。

綜上所述，水利行業(yè)在國(guó)產(chǎn)數(shù)據(jù)庫選型時(shí)要結(jié)合不同的業(yè)務(wù)場(chǎng)景，綜合功能、性能、成本等多個(gè)因素選擇合適的數(shù)據(jù)庫，在實(shí)施改造過程中遵循系統(tǒng)工程原則考慮改造難度、成本、時(shí)間、風(fēng)險(xiǎn)等因素逐步推進(jìn)。