白皮書1.1

區(qū)域性銀行數(shù)據(jù)庫改造趨勢031.2

區(qū)域性銀行業(yè)務(wù)現(xiàn)狀調(diào)研032.1數(shù)據(jù)庫技術(shù)路線選擇052.2數(shù)據(jù)庫部署架構(gòu)路線選擇082.3數(shù)據(jù)存儲選型112.4容災(zāi)高可用133.1

區(qū)域性銀行數(shù)據(jù)庫方案部署架構(gòu)153.2數(shù)據(jù)庫遷移實踐174.1蘇州農(nóng)商行存貸匯業(yè)務(wù)數(shù)據(jù)庫轉(zhuǎn)型實踐224.2廣發(fā)銀行支付業(yè)務(wù)國產(chǎn)化數(shù)據(jù)庫實踐244.3江南農(nóng)商行國產(chǎn)化數(shù)據(jù)庫實踐25編制委員會主

任：倪正華副主任：陳九昌

蔣

蔚

徐小峰程啟旭編委會成員（排名不分先后）：孔

偉

韓春龍

沈劍宇張成誠唐

浩王美鈞龔

濤陳二威

郭海龍李畢生劉

洋

穆

豪

王

佳

彭成云宋華林蘇東明

方

博

王煥好

許關(guān)征徐

銘楊

勐

岳愛菊

趙經(jīng)緯

王彥旌朱小濤陶友勝李建祥

蘇積輝

江

帆劉

東李佳玲目錄01

編制委員會目錄

02在金融行業(yè)加速變革的當(dāng)下，區(qū)域銀行在我國金融體系中占據(jù)著重要地位。其地域性特點使得區(qū)域銀行的業(yè)務(wù)模式通常相對集中，雖然隨著市場需求的變化，部分區(qū)域銀行已開始向外拓展業(yè)務(wù)，進(jìn)入其他地域市場，業(yè)務(wù)體量也不斷上升，但其整體用戶量和交易頻繁程度與大型全國性銀行仍有差距。例如，單一小微企業(yè)貸款服務(wù)的數(shù)據(jù)量通常在10TB以內(nèi)，這與大型銀行在同類業(yè)務(wù)中處理的數(shù)據(jù)量相比有一定差距。此外，區(qū)域銀行的客戶基礎(chǔ)主要集中在本地企業(yè)和個人客戶，其業(yè)務(wù)雖然更貼近客戶，但非結(jié)構(gòu)化特點突出（如農(nóng)產(chǎn)品收成、商戶流水等），且數(shù)據(jù)通常分布在不同的政府部門，缺乏相對規(guī)范的財務(wù)數(shù)據(jù)。因此，盡管這些銀行在服務(wù)本地客戶方面具備優(yōu)勢，但其業(yè)務(wù)的多樣性和復(fù)雜性相對較低，導(dǎo)致數(shù)據(jù)生成速度也相對緩慢。在可預(yù)見的未來幾年中，區(qū)域銀行的數(shù)據(jù)量趨向平穩(wěn)，預(yù)計不會出現(xiàn)大幅增長，主要受限于市場需求和客戶群體的規(guī)模。當(dāng)前在數(shù)據(jù)庫創(chuàng)新的時代背景下，國有大行、股份制銀行核心業(yè)務(wù)已陸續(xù)完成創(chuàng)新改造，為匹配創(chuàng)新目標(biāo)，區(qū)域銀行正大力加速數(shù)據(jù)庫創(chuàng)新改造。區(qū)域銀行積極進(jìn)行數(shù)據(jù)庫轉(zhuǎn)型創(chuàng)新，一方面是出于自身安全可控的考量，降低對單一技術(shù)的依賴；另一方面，也是順應(yīng)金融科技發(fā)展趨勢，提升自身技術(shù)實力的契機。然而，數(shù)據(jù)庫創(chuàng)新之路困難重重。首當(dāng)其沖的是技術(shù)難題。區(qū)域銀行85%以上長期依賴傳統(tǒng)IOE架構(gòu)，在向創(chuàng)新技術(shù)棧遷移時，面臨著新舊技術(shù)難以兼容的困境。例如，傳統(tǒng)架構(gòu)下的業(yè)務(wù)系統(tǒng)與新的國產(chǎn)數(shù)據(jù)庫、服務(wù)器等可能存在適配問題，導(dǎo)致系統(tǒng)運行不穩(wěn)定，影響日常業(yè)務(wù)開展。并且，新技術(shù)整體成熟度仍有待考證，在性能、穩(wěn)定性等關(guān)鍵指標(biāo)上可能難以完全滿足銀行復(fù)雜業(yè)務(wù)的高要求，因此選擇合適的廠家非常關(guān)鍵。同時，在轉(zhuǎn)型過程中，技術(shù)債務(wù)是關(guān)鍵挑戰(zhàn)。多數(shù)區(qū)域銀行核心系統(tǒng)平均使用年限超10年，78%未完成分布式改造（據(jù)IDC2024年金融行業(yè)IT架構(gòu)調(diào)研），難以快速響應(yīng)市場變化，對接新興業(yè)務(wù)場景。而且歷史遺留的“系統(tǒng)煙囪”問題嚴(yán)重，平均每家區(qū)域銀行存在15-20個獨立業(yè)務(wù)系統(tǒng)，數(shù)據(jù)打通和整合成本平均高達(dá)數(shù)千萬，數(shù)據(jù)價值難以充分發(fā)揮，制約了基于數(shù)據(jù)的創(chuàng)新應(yīng)用，如通過精準(zhǔn)營銷、智能風(fēng)控等數(shù)字化的手段來提升其競爭力、拓展業(yè)務(wù)邊界?？傮w而言，區(qū)域性銀行交易型數(shù)據(jù)庫正處于快速發(fā)展與變革時期。在政策護航、行業(yè)趨勢推動與技術(shù)創(chuàng)新引領(lǐng)下，銀行需正視挑戰(zhàn)，通過加強技術(shù)研發(fā)、優(yōu)化人才培養(yǎng)體系、深化產(chǎn)學(xué)研合作等方式，穩(wěn)步推進(jìn)交易型數(shù)據(jù)庫的升級與轉(zhuǎn)型，為金融業(yè)務(wù)的高質(zhì)量發(fā)展提供堅實的數(shù)據(jù)支撐。區(qū)域性銀行作為金融體系的重要組成部分，在支持地方經(jīng)濟發(fā)展與產(chǎn)業(yè)升級、服務(wù)中小微經(jīng)濟、普惠金融與鄉(xiāng)村振興、促進(jìn)金融生態(tài)穩(wěn)定方面發(fā)揮著不可替代的作用。從2019年開始，國有大型銀行和股份制銀行率先啟動包括數(shù)據(jù)庫在內(nèi)的信息技術(shù)應(yīng)用創(chuàng)新工作，部分區(qū)域性銀行也逐步開展了數(shù)據(jù)庫改造探索與實踐，國內(nèi)銀行數(shù)據(jù)庫改造已從“試點”進(jìn)入“全面攻堅”階段，預(yù)計未來兩三年將全面完成數(shù)據(jù)庫改造工作。區(qū)域性銀行因為業(yè)務(wù)規(guī)模、成本效益、運維復(fù)雜度或技術(shù)熟悉度等因素，傳統(tǒng)商業(yè)集中式數(shù)據(jù)庫以其優(yōu)秀的系統(tǒng)穩(wěn)定性、良好的軟硬適配能力受到青睞，集中式數(shù)據(jù)庫在中小金融機構(gòu)仍占據(jù)主導(dǎo)地位，其實例數(shù)占比仍有80%（數(shù)據(jù)來源于《金融業(yè)數(shù)據(jù)庫創(chuàng)新發(fā)展報告（2024）》）

，展現(xiàn)出不可替代的優(yōu)勢。03

區(qū)域性銀行數(shù)據(jù)庫改造需求現(xiàn)狀區(qū)域性銀行數(shù)據(jù)庫改造需求現(xiàn)狀

041.1

區(qū)域性銀行數(shù)據(jù)庫改造趨勢1.2

區(qū)域性銀行業(yè)務(wù)現(xiàn)狀調(diào)研·

上限容量有限，一般來說集中式數(shù)據(jù)庫單庫的數(shù)據(jù)量在40TB-100TB。該能力滿足大多數(shù)核心交易業(yè)務(wù)的訴求，但較難應(yīng)對更高容量的敏態(tài)應(yīng)用或者歷史數(shù)據(jù)量很大的交易庫場景?！?/p>

上限性能有限：高并發(fā)讀寫集中在一臺機器上，可能成為系統(tǒng)的瓶頸，性能規(guī)格在100萬tpmC。集中式數(shù)據(jù)庫的典型代表有：MySQL,

PostgreSQL,

Oracle,

SQL

Server，

openGauss，GaussDB集中式。分布式數(shù)據(jù)庫將數(shù)據(jù)拆分多分片分散存儲在多個服務(wù)器（節(jié)點）上，這些節(jié)點通過網(wǎng)絡(luò)連接協(xié)同工作，通過增加機器數(shù)量來擴展。其特點為在架構(gòu)上采用多節(jié)點集群方式，數(shù)據(jù)被分片（Sharding）存儲在不同的節(jié)點上，通過擴展分片和服務(wù)器節(jié)點來提升整體性能和容量。分布式數(shù)據(jù)庫的優(yōu)勢主要為以下幾個方面：·擴展能力，分布式數(shù)據(jù)庫理論上可以通過不斷增加分片和節(jié)點來線性提升系統(tǒng)的存儲容量和處理能力。·高可用性與容錯性：數(shù)據(jù)通常有多個副本存放在不同節(jié)點上，單個或多個節(jié)點故障不會導(dǎo)致整個服務(wù)宕機，自動故障恢復(fù)能力強?！じ卟l(fā)性能：將負(fù)載分散到多個節(jié)點上，可應(yīng)對極高的并發(fā)讀寫請求。分布式數(shù)據(jù)庫的缺點主要為以下幾個方面：·復(fù)雜性高，引入了協(xié)調(diào)節(jié)點、數(shù)據(jù)節(jié)點、事務(wù)節(jié)點、管理節(jié)點等各類節(jié)點。部署、運維、監(jiān)控和故障診斷的難度增加。·

一致性挑戰(zhàn)大，在分布式環(huán)境下，強一致性會嚴(yán)重影響性能。因此很多分布式數(shù)據(jù)庫采用最終一致性（BASE理論），可能讀到舊數(shù)據(jù)，需要應(yīng)用層處理一致性問題?！た绻?jié)點的分布式事務(wù)訪問時延開銷大，甚至有些數(shù)據(jù)庫直接不支持或支持得很差?！?/p>

單筆交易來看，時延較大，分布式數(shù)據(jù)庫節(jié)點間需要頻繁跨節(jié)點轉(zhuǎn)發(fā)，增加了協(xié)調(diào)/代理節(jié)點-數(shù)據(jù)節(jié)點的轉(zhuǎn)發(fā)，網(wǎng)絡(luò)延遲和穩(wěn)定性對數(shù)據(jù)庫性能影響較大。分布式數(shù)據(jù)庫的典型代表為：TiDB、OceanBase、TDSQL、GoldenDB、GaussDB分布式。基于集中式數(shù)據(jù)庫和分布式數(shù)據(jù)庫在架構(gòu)上的差異，區(qū)域性銀行需結(jié)合業(yè)務(wù)特點來進(jìn)行數(shù)據(jù)庫的技術(shù)路線選型。主要考察的業(yè)務(wù)指標(biāo)如下：1）數(shù)據(jù)一致性。應(yīng)用要求強一致性的（如：核心交易系統(tǒng)、銀行賬戶系統(tǒng)）建議選擇集中式數(shù)據(jù)庫。應(yīng)用可以接受最終一致性的（如：社交網(wǎng)絡(luò)點贊、評論、用戶畫像）可選擇分布式數(shù)據(jù)庫。2）基于數(shù)據(jù)容量和性能評估，數(shù)據(jù)容量<40TB，評估性能大小，普遍沒觸及集中部署的性能瓶頸，建議選擇集中式數(shù)據(jù)庫，數(shù)據(jù)量>40TB可考慮選用數(shù)據(jù)庫分布式部署，或者通過對應(yīng)用進(jìn)行單元化拆分，對應(yīng)的數(shù)據(jù)庫子庫采用集中式部署。區(qū)域性銀行對數(shù)據(jù)庫技術(shù)路線的選擇，需要對兩種架構(gòu)進(jìn)行理性分析。集中式數(shù)據(jù)庫是將所有數(shù)據(jù)存儲在一套集群上，通過提升單機性能（更強的CPU、更大的內(nèi)存、更快的磁盤）來擴展。其特點為：單機或主從架構(gòu)，為防止單點故障，生產(chǎn)系統(tǒng)一般按一主多從架構(gòu)建設(shè)。集中式數(shù)據(jù)庫所采用的數(shù)據(jù)存儲，所有數(shù)據(jù)在一套存儲系統(tǒng)上（一套存儲可能采用雙活方式保障系統(tǒng)可用性）其擴展方式為通過升級硬件（CPU、內(nèi)存、擴展存儲系統(tǒng)等）來提升性能和容量。集中式數(shù)據(jù)庫的優(yōu)點主要有以下幾點：·

單庫解決問題，不需要拆分成多個子庫或者多分片，避免了分布式事務(wù)跨分片訪問的問題，適合銀行交易核心應(yīng)用等穩(wěn)態(tài)場景。·單筆交易時延低，避免了頻繁跨節(jié)點轉(zhuǎn)發(fā)?！?/p>

簡單易用，技術(shù)成熟，生態(tài)完善，開發(fā)、運維、管理的工具鏈和人才都非常豐富。·事務(wù)支持，對復(fù)雜事務(wù)（如跨表事務(wù)）的支持完善。集中式數(shù)據(jù)庫的潛在不足如下：數(shù)據(jù)庫是信息系統(tǒng)的核心，從技術(shù)路線上可分為集中式數(shù)據(jù)庫和分布式數(shù)據(jù)庫。集中式數(shù)據(jù)庫在過去幾十年中一直是企業(yè)數(shù)據(jù)存儲的主流解決方案。其經(jīng)典的客戶端-數(shù)據(jù)庫-計算-交換機-存儲模型簡單、成熟且穩(wěn)定。分布式數(shù)據(jù)庫通過將數(shù)據(jù)拆成多分片分散存儲到多個物理節(jié)點，并通過網(wǎng)絡(luò)同步協(xié)同工作，旨在滿足敏態(tài)應(yīng)用對數(shù)據(jù)庫容量和性能有高彈性擴展的訴求。05

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

062.1數(shù)據(jù)庫技術(shù)路線選擇節(jié)點1分片2副本...節(jié)點2分片n副本...節(jié)點n分片1副本

...數(shù)據(jù)分片2數(shù)據(jù)分片n主節(jié)點備節(jié)點

數(shù)據(jù)副本

中間件或協(xié)調(diào)節(jié)點APPAPP分布式數(shù)據(jù)庫集中式數(shù)據(jù)庫讀寫讀讀寫讀寫全量數(shù)據(jù)數(shù)據(jù)分片1全量數(shù)據(jù)日志同步讀寫...數(shù)據(jù)庫系統(tǒng)的架構(gòu)選擇一直是企業(yè)技術(shù)決策中的核心問題，尤其是存算一體與存算分離兩種架構(gòu)模式的抉擇。隨著數(shù)據(jù)規(guī)模的爆炸式增長和業(yè)務(wù)需求的日益復(fù)雜，這一選擇變得尤為關(guān)鍵。從歷史演進(jìn)角度看，數(shù)據(jù)庫架構(gòu)經(jīng)歷了多次存算一體與存算分離的反復(fù)。早期的IT系統(tǒng)由于體量小，多以存算一體為主，1961年通用電氣公司開發(fā)的第一款數(shù)據(jù)庫管理系統(tǒng)IDS（Integrated

DataStore，集成數(shù)據(jù)存儲），只能運行在通用電氣的主機上，且只有一個文件存儲在本地盤上，由本機的CPU、內(nèi)存依據(jù)手工編碼的指令來讀寫。當(dāng)時的數(shù)據(jù)庫屬于高端應(yīng)用，和各種大型機、中型機緊密綁定在一起，數(shù)據(jù)量也相對較?。ㄈ绠?dāng)時銀行信貸管理系統(tǒng)的數(shù)據(jù)量只有10GB左右），使用大型機的本地存儲空間綽綽有余。隨著互聯(lián)網(wǎng)技術(shù)的興起，數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)量開始激增，傳統(tǒng)的單機數(shù)據(jù)庫服務(wù)器無法滿足不斷增長的大量數(shù)據(jù)的存儲和訪問，

UNIX系統(tǒng)也開始大行其道，而幾乎所有的UNIX主機都具備了連接外置存儲的能力。在這一時期，存儲區(qū)域網(wǎng)絡(luò)（SAN）和網(wǎng)絡(luò)附加存儲（NAS）方案開始占據(jù)主導(dǎo)，數(shù)據(jù)庫架構(gòu)由存算一體轉(zhuǎn)向了存算分離架構(gòu)，數(shù)據(jù)庫+計算+外置企業(yè)存儲存算分離架構(gòu)開始流行，至今已經(jīng)3

0年+。商業(yè)數(shù)據(jù)庫巨頭Oracle從9i版本開始，推出了基于共享存儲的RAC（RealApplication

Clusters），各計算節(jié)點與共享存儲分離，計算節(jié)點支持橫向擴展2,4,8節(jié)點等提升并發(fā)處理能力，存儲也支持橫向擴展2節(jié)點，4節(jié)點，8節(jié)點，甚至更多，提升并發(fā)性能和容量，整體架構(gòu)解決了數(shù)據(jù)庫算力橫向擴展和容量擴展。外置存儲除了解決容量橫向擴展，更重要的是通過企業(yè)存儲軟件操作系統(tǒng)和硬件的協(xié)同實現(xiàn)了數(shù)據(jù)存儲空間的極致高可靠、高可用，對眾多的硬盤進(jìn)行統(tǒng)一池化管理，

RAID冗余管理，部件故障快速隔離，品控質(zhì)量管理等，大幅減少故障概率，達(dá)成99.9999%可靠性要求。同時集群內(nèi)數(shù)據(jù)庫節(jié)點實現(xiàn)單副本數(shù)據(jù)的共享訪問，避免的頻繁跨節(jié)點同步數(shù)據(jù)帶來的性能和時延損耗。進(jìn)入21世紀(jì)10、20年代，伴隨著web2.0、3.0的飛速發(fā)展，越來越多的業(yè)務(wù)成為互聯(lián)網(wǎng)業(yè)務(wù)，業(yè)務(wù)訪問并發(fā)量的升級帶來了數(shù)據(jù)量指數(shù)級激增。這使得存算一體架構(gòu)再次受到關(guān)注，尤其是在大數(shù)據(jù)和實時分析場景中。然而，隨著云計算技術(shù)的成熟和金融行業(yè)數(shù)字化轉(zhuǎn)型的深入，存算分離架構(gòu)因其獨特的優(yōu)勢又重新成為許多企業(yè)的選擇。3）考慮業(yè)務(wù)的增長情況，比如某個系統(tǒng)預(yù)期年業(yè)務(wù)未來增長很快，未來5年，數(shù)據(jù)量會超過40T，優(yōu)先考慮選用分布式。4）考慮業(yè)務(wù)復(fù)雜度，業(yè)務(wù)系統(tǒng)有大量的多表關(guān)聯(lián)的復(fù)雜SQL、或者存儲過程、package、函數(shù)等對象，這類系統(tǒng)分布式改造難度大，優(yōu)先選用集中式，可幫助應(yīng)用平滑遷移，改造工作量小。5）讀寫并發(fā)，

TPS一般在20000左右，超過該業(yè)務(wù)負(fù)載，考慮選用數(shù)據(jù)庫分布式部署或者通過應(yīng)用單元化拆分。6）IT團隊技能，如果IT團隊熟悉傳統(tǒng)SQL，缺乏分布式系統(tǒng)運維經(jīng)驗，建議從集中式數(shù)據(jù)庫開始。團隊擁有深厚的分布式系統(tǒng)開發(fā)和運維能力，可以考慮使用分布式數(shù)據(jù)庫。總之，要加強分布式架構(gòu)轉(zhuǎn)型的統(tǒng)籌管理，明確分布式架構(gòu)的適用范圍，基于業(yè)務(wù)規(guī)模、應(yīng)用場景、數(shù)據(jù)容量等維度，合理選擇系統(tǒng)架構(gòu)，要統(tǒng)籌規(guī)劃重要系統(tǒng)和一般系統(tǒng)的轉(zhuǎn)型方向和推進(jìn)節(jié)奏。對于性能、容量要求較小的系統(tǒng)，要加強集中式和分布式技術(shù)路線選擇評估，控制好系統(tǒng)復(fù)雜度，實事求是，技術(shù)架構(gòu)精簡為美。下面以某行的營銷管理系統(tǒng)為例，提供用戶方案設(shè)計建議：系統(tǒng)特點：·

數(shù)據(jù)量大（平均每個省大約5TB），系統(tǒng)總數(shù)據(jù)量超過100TB。·

高負(fù)載高吞吐（平均每個省大約2W），系統(tǒng)總TPS超過50W?！?/p>

業(yè)務(wù)邏輯比較復(fù)雜，即有TP類的實時交易業(yè)務(wù)，對交易響應(yīng)時延要求較高，又有復(fù)雜的分析類查詢的業(yè)務(wù)，還有批處理業(yè)務(wù)，包含大量的存儲過程。方案設(shè)計建議：·

大數(shù)據(jù)量，大并發(fā)高吞吐的系統(tǒng)從特點上看更適合選用分布式，用戶也有意向做這方面探索和嘗試。但是該業(yè)務(wù)系統(tǒng)存在較多的復(fù)雜查詢的AP類SQL，以及大量的存儲過程，選用分布式不僅應(yīng)用改造難度很大，而且可能很難充分發(fā)揮分布式本身的能力，反而會限制系統(tǒng)的性能和吞吐量。綜業(yè)務(wù)特征集中式支撐能力選型建議存儲過程或復(fù)雜SQL使用量基本未用影響較大不影響有需求對穩(wěn)定性、備份等運維高要求無需求是并發(fā)性能/單庫容量指標(biāo)滿足否是可拆庫/瘦身否評估分布式改進(jìn)難度集中式部署（優(yōu)先）分布式部署合考慮，建議用戶采用集中式?！o論從數(shù)據(jù)量還是吞吐量來說，單個集中式實例很難承載整個業(yè)務(wù)的業(yè)務(wù)量，建議應(yīng)用系統(tǒng)采用微服務(wù)進(jìn)行單元化改造，按省的粒度進(jìn)行分庫，把業(yè)務(wù)進(jìn)行拆分?！?yīng)用考慮采用讀寫分離架構(gòu)，把包含復(fù)雜查詢在內(nèi)的只讀業(yè)務(wù)放到備庫，降低主庫的壓力?！づ芘悩I(yè)務(wù)建議放到晚上進(jìn)行，避開白天的業(yè)務(wù)高峰期，避免對關(guān)鍵的交易類業(yè)務(wù)產(chǎn)生影響。07

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

082.2數(shù)據(jù)庫部署架構(gòu)路線選擇存量較大分片、分布式事務(wù)影響性能指標(biāo)當(dāng)今企業(yè)面臨的技術(shù)環(huán)境更加復(fù)雜，數(shù)據(jù)規(guī)模、業(yè)務(wù)需求和技術(shù)生態(tài)都在快速變化。存算一體架構(gòu)在自主創(chuàng)新方案不足的情況下，已逐漸暴露彈性與可靠性短板。而存算分離架構(gòu)則通過共享企業(yè)存儲隔離硬件故障，結(jié)合虛擬化技術(shù)，將物理服務(wù)器切換時間從分鐘縮短至秒級，顯著提升了業(yè)務(wù)連續(xù)性。這種演進(jìn)使得架構(gòu)選擇不再是簡單的技術(shù)決策，而是關(guān)系到企業(yè)長期發(fā)展的戰(zhàn)略決策。一、技術(shù)深度分析：存算一體vs存算分離1、存算一體架構(gòu)的技術(shù)特點存算一體架構(gòu)是一種傳統(tǒng)但成熟的數(shù)據(jù)庫設(shè)計模式，其核心特點是數(shù)據(jù)存儲與計算處理緊密耦合在相同的物理節(jié)點上。在這種架構(gòu)中，每個數(shù)據(jù)庫節(jié)點都配備了自己的計算資源和存儲資源，數(shù)據(jù)分布式存儲在各個節(jié)點的本地磁盤上，計算任務(wù)也盡可能在數(shù)據(jù)所在的節(jié)點上執(zhí)行。存算一體架構(gòu)的主要優(yōu)勢體現(xiàn)在以下幾個方面：1)部署簡易，不需要依賴類似外部共享存儲，僅依賴物理服務(wù)器部署前端和后端進(jìn)程即可完成集群的搭建。2)

執(zhí)行計算時，計算節(jié)點可直接訪問本地存儲數(shù)據(jù)，充分利用機器的IO、減少不必要的網(wǎng)絡(luò)開銷、獲得更極致的查詢性能。然而，存算一體架構(gòu)也存在明顯的局限性。首先計算服務(wù)器部件隨著年限增加，故障率上升，任何部件帶來的節(jié)點故障都會殃及本地盤存儲的數(shù)據(jù)，新?lián)Q節(jié)點帶來數(shù)據(jù)重構(gòu)時間長。本地盤的故障、慢盤、超時等會導(dǎo)致節(jié)點頻繁切換，業(yè)務(wù)hang住幾十秒甚至數(shù)分鐘后，帶來交易失敗，切換后恢復(fù)重建節(jié)點數(shù)據(jù)帶來復(fù)雜的運維操作。其次，存儲與計算綁定，容量不夠，擴容需擴計算節(jié)點和存儲資源，操作不靈活，成本反而高。最后，溫冷數(shù)據(jù)成本偏高，歷史數(shù)據(jù)仍需占用CPU和內(nèi)存要求高的計算節(jié)點，成本高，但是業(yè)務(wù)量其實很小，CPU利用率低。此外，存算一體架構(gòu)在故障恢復(fù)和搬遷時都要全量恢復(fù)數(shù)據(jù)，不僅降低了可靠性，也增加了運維工作量和成本，同時遷移擴容時間不可控，需要更多資源冗余來彌補。2、存算分離架構(gòu)的技術(shù)特點3)

降低成本，存儲介質(zhì)分層分級，冷數(shù)據(jù)存儲在低廉的介質(zhì)上，成本下降70%。4)

快速故障恢復(fù)，節(jié)點宕機后，新節(jié)點直接掛載共享存儲，無需全量數(shù)據(jù)重構(gòu)。3、性能表現(xiàn)對比分析在實際性能表現(xiàn)上，兩種架構(gòu)各有特點。存算一體架構(gòu)由于數(shù)據(jù)本地化存儲，尤其NVMeSSD通常具有幾十us級的超低延時優(yōu)勢。而存算分離架構(gòu)通過FC/ROCE高速時延網(wǎng)絡(luò)，

IO讀寫到存儲緩存，實現(xiàn)極低的IO時延，接近存算一體。但是數(shù)據(jù)庫主備是要寫本地節(jié)點，同時同步要跨網(wǎng)絡(luò)寫備節(jié)點，甚至同城網(wǎng)絡(luò)同步寫備節(jié)點，而這個時延占比很大，大量的時延消耗在網(wǎng)絡(luò)傳輸上。如下圖，數(shù)據(jù)庫事務(wù)的時延是CN計算節(jié)點到數(shù)據(jù)庫節(jié)點1+同步寫數(shù)據(jù)庫從節(jié)點2或者3的時延累加，都是Xms級，而盤時延4的0.1ms的時延占比就很小了，主備同步寫網(wǎng)絡(luò)消耗時延更大。存算分離架構(gòu)是一種現(xiàn)代且靈活的數(shù)據(jù)庫設(shè)計模式，其核心思想是將計算處理與數(shù)據(jù)存儲解耦，使它們能夠獨立擴展和管理。在這種架構(gòu)中，數(shù)據(jù)持久化到共享存儲，計算節(jié)點無狀態(tài)化，實現(xiàn)存儲與計算獨立伸縮。存算分離架構(gòu)的主要優(yōu)勢包括：1)

企業(yè)存儲的可靠性高于服務(wù)器本地盤，盤的故障不會導(dǎo)致節(jié)點切換，減少數(shù)據(jù)庫節(jié)點切換概率。存儲統(tǒng)一管理硬盤的可靠性、RAID管理、冗余管理，慢盤、超時盤、故障盤等快速隔離，硬盤的品控質(zhì)量管理，盤的FW質(zhì)量和升級管理。2)

獨立彈性伸縮，計算擴容可以快速增加節(jié)點應(yīng)對流量高峰，存儲擴容可以使存儲容量按需擴展，無需數(shù)據(jù)遷移。時期主導(dǎo)架構(gòu)推動因素典型技術(shù)1960s-1980s存算一體硬件限制、數(shù)據(jù)量小IDS、IBM大型機1990s-2010s存算分離數(shù)據(jù)量增長、網(wǎng)絡(luò)技術(shù)Oracle

RAC、SAN/NAS2010s-2020s存算一體再現(xiàn)互聯(lián)網(wǎng)爆發(fā)、大數(shù)據(jù)技術(shù)Hadoop、NoSQL2020s存算分離復(fù)興云計算、金融數(shù)字化云原生數(shù)據(jù)庫、共享存儲4

,

SSD

…SSD…數(shù)據(jù)庫Node2SSD…數(shù)據(jù)庫Node1數(shù)據(jù)庫Node314

SSD

…Data

Node12

同步從節(jié)點4

,

SSD

…SSD…Data

Node2Data

Node3從某用戶數(shù)據(jù)庫性能測試數(shù)據(jù)看，數(shù)據(jù)庫低并發(fā)壓力下，存算一體有優(yōu)勢，但是隨著并發(fā)壓力增大，存算分離性能更好，時延也更穩(wěn)定，因為外置存儲是幾十甚至上百塊SSD盤池化，多盤提供性能上限更高，再加上存儲緩存技術(shù)，時延更穩(wěn)定。09

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

103表：存算一體與存算分離架構(gòu)的歷史演進(jìn)同步同城從節(jié)點CN計算節(jié)點CN計算節(jié)點內(nèi)存內(nèi)存內(nèi)存內(nèi)存內(nèi)存內(nèi)存由上述交易業(yè)務(wù)量，測算所需存儲系統(tǒng)性能如下。1)存儲響應(yīng)時間：存儲設(shè)備對請求的響應(yīng)時間，包括讀取數(shù)據(jù)、寫入數(shù)據(jù)等操作的響應(yīng)時間。存儲可支撐部署多套數(shù)據(jù)庫實例，提供穩(wěn)定時延小于0.1ms的存儲性能。2)

存儲吞吐量：存儲設(shè)備在一定時間內(nèi)處理的數(shù)據(jù)量，包括讀取數(shù)據(jù)、寫入數(shù)據(jù)等操作的吞吐量。全讀場景，提供不低于20GB/s的存儲性能。3)

存儲并發(fā)數(shù)：同時訪問存儲設(shè)備的用戶數(shù)量。2.3.2可靠性指標(biāo)銀行重要系統(tǒng)對系統(tǒng)可用性提出了高要求，區(qū)域銀行要求業(yè)務(wù)可用性99.999%，因此數(shù)據(jù)中心基礎(chǔ)架構(gòu)中的存儲可靠性需提升至99.9999%以上。1.數(shù)據(jù)可靠性1)數(shù)據(jù)正確性：數(shù)據(jù)庫記錄的信息始終保持與描述對象一致，在多個實例間不會出現(xiàn)數(shù)據(jù)沖突或矛盾。2)

數(shù)據(jù)一致性：在多個副本和不同節(jié)點之間，數(shù)據(jù)保持一致的程度。3)

數(shù)據(jù)完整性：數(shù)據(jù)在存儲、處理和傳輸過程中保持其正確性和一致性。4)

數(shù)據(jù)持久性：存儲設(shè)備故障或其他異常情況下，避免出現(xiàn)數(shù)據(jù)丟失，數(shù)據(jù)保持不變且可恢復(fù)。2.系統(tǒng)可靠性1)冗余設(shè)計：存儲節(jié)點故障不會影響整系統(tǒng)運行。2)

自動故障切換：在存儲節(jié)點發(fā)生故障時，系統(tǒng)自動切換到備用節(jié)點，以保障數(shù)據(jù)庫服務(wù)的連續(xù)性。3)

網(wǎng)絡(luò)鏈路冗余：鏈路端到端故障秒級切換，存儲IO不歸零，數(shù)據(jù)庫業(yè)務(wù)不中斷。綜合讀寫測試結(jié)果(本地盤NVMe,Do-rado存儲)類型并發(fā)TPSQPS平均時延(ms)95%時延(ms)本地盤484165.2366643.7411.5231.94965247.2183955.3318.2939.651929465.85151453.5720.2841.1038411915.89190654.3232.2253.8576813889.05222224.7555.2889.16存儲盤483048.4548775.2615.7422.69965180.5382888.4718.5326.681928382.18134114.9322.9032.5338413415.28214644.4928.6240.3776818056.45288903.1542.5261.08二、適用場景分析基于技術(shù)特點和性能表現(xiàn)，兩種架構(gòu)各有其適用場景。存算一體架構(gòu)適合以下場景：.簡單使用/快速使用數(shù)據(jù)庫。.業(yè)務(wù)場景無需彈性擴縮容。存算分離架構(gòu)則適合以下場景：.高可靠、高可用、高性能要求的重要生產(chǎn)系統(tǒng)?！な嵌鄠€業(yè)務(wù)使用共享同一份數(shù)據(jù)，并且有隔離計算的需求?！ば枰獦O致的彈性擴縮容，隨著業(yè)務(wù)規(guī)模的增長，算力、存力可分別靈活擴容，提升資源利用率。區(qū)域性銀行交易性數(shù)據(jù)庫場景下對存儲的要求，具體如下。2.3.1吞吐性能區(qū)域性銀行生產(chǎn)業(yè)務(wù)峰值交易量約幾百~5000TPS，單次交易平均SQL請求數(shù)約為30-50次，每次SQL請求涉及約10次以上的存儲IO讀寫，時延0.5ms，峰值業(yè)務(wù)處理所需的存儲IO請求能力約為每秒1.5-2.5百萬次讀寫，時延1ms。11

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

122.3數(shù)據(jù)存儲選型中國標(biāo)準(zhǔn)準(zhǔn)《信息系統(tǒng)災(zāi)難恢復(fù)規(guī)范》國際標(biāo)準(zhǔn)英國Share78RPORTO等保2.0技術(shù)要求Tier6-0數(shù)據(jù)丟失，自動拉起業(yè)務(wù)Tier7-0數(shù)據(jù)丟失，自動拉起業(yè)務(wù)0<15

min四級本地備份+異地備份+本地高可用+異地業(yè)務(wù)高可用Tier5-0數(shù)據(jù)丟失Tier6-0數(shù)據(jù)丟失0~30min<

2

HrTier4-電子傳輸和完整設(shè)備支持Tier5-災(zāi)備中心有實時的狀態(tài)更新2~12Hr<

24

Hr三級本地備份+異地實時備份+本地業(yè)務(wù)高可用Tier4-活動狀態(tài)的災(zāi)備中心2~24Hr<

24

HrTier3-電子傳輸和部分設(shè)備支持Tier3-電子鏈接12Hr~24Hr24Hr二級本地備份+異地定時備份Tier2-備用場地支持Tier2-PTAM卡車運送+熱備份中心24

Hr~數(shù)天24

Hr~數(shù)天Tier

1-基本支持Tier

1-PTAM卡車

運送數(shù)天數(shù)天一級本地備份Tier0-No

off-siteData數(shù)天~?數(shù)天~?同城雙集群數(shù)據(jù)庫強同步，實現(xiàn)

RPO=0，RTO＜120S。（2）兩地三中心：支持同城雙數(shù)據(jù)中心，多地容災(zāi)，實例可以在多個地域間進(jìn)行遷移。實例跨地域故障切換指標(biāo)，兩地三中心異地高可用方案實現(xiàn)RPO＜1分鐘，RTO＜10分鐘。備份與恢復(fù)（1）備份效率：支持

LanFree

級備份，數(shù)據(jù)備份流量走存儲網(wǎng)絡(luò)，降低對主機的影響，備份速率可達(dá)2GB/s。（2）恢復(fù)時間：數(shù)據(jù)恢復(fù)所需的時間。支持任意時間點恢復(fù)，百TB級數(shù)據(jù)庫分鐘級恢復(fù)。（3）數(shù)據(jù)丟失點：數(shù)據(jù)恢復(fù)時允許的數(shù)據(jù)丟失量。支持分鐘級最小保護周期，通過備份數(shù)據(jù)恢復(fù)數(shù)據(jù)庫實例允許丟失的數(shù)據(jù)量最小可達(dá)到5分鐘。3.硬盤可靠性1)SSD盤壽命提升：具備SSD盤磨損均衡和全局反磨損均衡能力。2)

最大可容忍3盤同時故障，3盤故障業(yè)務(wù)不歸零，性能無明顯影響。避免一個RAID組內(nèi)3塊SSD同時失效導(dǎo)致的數(shù)據(jù)丟失，提高系統(tǒng)整體硬盤的可靠性。3)

故障預(yù)防：硬盤故障提前識別，提前告警，提醒用戶進(jìn)行更換。4)

故障檢測&容錯：提供硬盤在線診斷能力，檢測硬盤潛在故障，識別盤故障，主動啟動數(shù)據(jù)拷貝。避免慢盤進(jìn)行寫操作，盡量不讀慢盤。出現(xiàn)慢盤后，業(yè)務(wù)不歸零，性能無明顯影響。5)

盤故障修復(fù)：單盤故障數(shù)據(jù)重構(gòu)速度高于5TB/h。圖2-4：中國和國際的信息系統(tǒng)災(zāi)備恢復(fù)標(biāo)準(zhǔn)區(qū)域性銀行核心業(yè)務(wù)對應(yīng)5-6級核心類業(yè)務(wù)，除了要求數(shù)據(jù)本身的高可用外，對業(yè)務(wù)連續(xù)性也有極高要求，具體要求如下：容災(zāi)能力要求：（1）同城雙集群：基于共享存儲的高可用方案，提供性能

更高，可靠性更強的高可用方案。支持金融業(yè)對系統(tǒng)業(yè)務(wù)連續(xù)性有著嚴(yán)格要求，其中數(shù)據(jù)庫集群尤為重要，用戶通常按照災(zāi)備建設(shè)的兩大標(biāo)準(zhǔn)和兩大衡量指標(biāo)來規(guī)劃總體容災(zāi)架構(gòu)，具體參考如下標(biāo)準(zhǔn)：13

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

區(qū)域性銀行數(shù)據(jù)庫改造技術(shù)路線選擇

142.4容災(zāi)高可用類別型號具體描述數(shù)量計算服務(wù)器64Core@2.6HZ，內(nèi)存512GB，系統(tǒng)盤

2*960SATA（raid10）6網(wǎng)格業(yè)務(wù)&管理交換機48*10Gb/25Gb以太網(wǎng)絡(luò)8存儲交換機48*25Gb以太網(wǎng)絡(luò)448*25Gb，36*100Gb以太網(wǎng)絡(luò)4存儲全閃存存儲四控（總計1TB緩存），21*7.68TBNVMe

SSD，（支持雙活/復(fù)制）2備份備份服務(wù)器（含備份軟件）裸容量400TB或者按需配置1區(qū)域性銀行數(shù)據(jù)庫存算分離解決方案是指基于數(shù)據(jù)庫+計算+網(wǎng)絡(luò)+存儲+備份為基礎(chǔ)構(gòu)建RPO=0的高可靠解決方案，該方案采用數(shù)據(jù)庫存算分離及雙數(shù)據(jù)中心架構(gòu)部署，雙數(shù)據(jù)中心之間采用存儲雙活/同步復(fù)制保證RPO=0，主數(shù)據(jù)庫中心提供讀寫業(yè)務(wù)，災(zāi)備數(shù)據(jù)中心提供查詢業(yè)務(wù)，提高數(shù)據(jù)中心的整體服務(wù)能力和系統(tǒng)資源利用率，同時采用存儲本地快照+備份軟件（Lan-free方式）雙重備份，保證數(shù)據(jù)完整性。區(qū)域銀行數(shù)據(jù)庫存算分離解決方案部署架構(gòu)該方案采用數(shù)據(jù)庫存算分離雙數(shù)據(jù)中心部署，數(shù)據(jù)中心之間首次部署初始化通過數(shù)據(jù)庫跨集群全量building，后續(xù)業(yè)務(wù)主集群節(jié)點寫xlog共享日志，通過存儲同步復(fù)制將xlog日志數(shù)據(jù)同步到備集群xlog共享卷，備集群各節(jié)點將日志回放實現(xiàn)跨集群容災(zāi)兩個數(shù)據(jù)中心均處于運行狀態(tài)，邏輯架構(gòu)圖如圖3-1所示。圖3-1：區(qū)域銀行數(shù)據(jù)庫存算分離解決方案邏輯架構(gòu)圖快照備份生產(chǎn)集群快照T0快照T1…快照激活快照Tn

該方案備份采用了存儲無損快照+備份軟件進(jìn)行備份，本地備份采用全存儲無損快照進(jìn)行備份，在誤操作情況下，可以通過存儲快照快速進(jìn)行恢復(fù)，百TB數(shù)據(jù)分鐘級恢復(fù)；備份軟件采用LAN-FREE方式進(jìn)行備份，通過訪問存儲及數(shù)據(jù)卷快照間的差異數(shù)據(jù)，從存儲讀取備份數(shù)據(jù)，生成數(shù)據(jù)副本性能可達(dá)2GB/s。如圖3-2所示。圖3-2

區(qū)域銀行數(shù)據(jù)庫存算分離解決方案備份邏輯架構(gòu)圖生產(chǎn)/災(zāi)備/測試集群主生產(chǎn)中心

Region

同城生產(chǎn)中心

Region主集群

備集群13.1

區(qū)域性銀行數(shù)據(jù)庫方案部署架構(gòu)鯤鵬服務(wù)器

鯤鵬服務(wù)器鯤鵬服務(wù)器5讀GaussDB備節(jié)點鯤鵬服務(wù)器4GaussDB

備節(jié)點GaussDB

備節(jié)點GaussDB

主節(jié)點GaussDB

主節(jié)點GaussDB

備節(jié)點GaussDB

備節(jié)點日志備份備份

代理TPOPSTPOPSNoF+交換機NoF+交換機Region

1Region2讀寫GaussDB主節(jié)點鯤鵬服務(wù)器讀GaussDB備節(jié)點鯤鵬服務(wù)器數(shù)據(jù)卷RedoLogDataFile

Share

Redo

Log日志卷區(qū)域性銀行數(shù)據(jù)庫改造實踐

1615

區(qū)域性銀行數(shù)據(jù)庫改造實踐副本復(fù)制3增量日志存儲同步復(fù)制數(shù)據(jù)庫系統(tǒng)硬件推薦配置：讀

讀

讀OceanStor

Dorado存儲池OceanStor

Dorado存儲池GaussDB備節(jié)點GaussDB備節(jié)點GaussDB備節(jié)點NoF+存儲交換機*NoF+存儲交換機*NoF+存儲交換機*NoF+存儲交換機*副本T0首次全量buildingRedoLog

DataFileOceanProtectShareRedo

Log副本恢復(fù)副本歸檔2圖3-3：數(shù)據(jù)庫遷移最佳實踐一個應(yīng)用系統(tǒng)發(fā)展到一定程度后，可能應(yīng)用開發(fā)人員或DBA無法完全了解數(shù)據(jù)庫中包含哪些對象，以及應(yīng)用代碼中有多少SQL。遷移前進(jìn)行遷移評估可以幫助用戶梳理數(shù)據(jù)庫對象和應(yīng)用代碼SQL，并識別其中需要進(jìn)行改造的對象，給出改造建議，讓業(yè)務(wù)做到心中有數(shù)，降低應(yīng)用改造成本。遷移過程中配合遷移工具將數(shù)據(jù)庫對象、數(shù)據(jù)進(jìn)行完整遷移，并進(jìn)行數(shù)據(jù)校驗、仿真驗證、業(yè)務(wù)驗證，保證遷移前后的一致性。遷移完成后將應(yīng)用流量切換到新的數(shù)據(jù)庫中。提供的數(shù)據(jù)庫遷移工具集，主要包含兩個工具，分為別UGO和DRS。其中UGO是專注于異構(gòu)數(shù)據(jù)庫對象和應(yīng)用遷移的專業(yè)化工具，包含四大核心功能：預(yù)遷移評估、結(jié)構(gòu)遷移、應(yīng)用遷移和SQL審核。

DRS用于數(shù)據(jù)庫實時遷移和實時同步，支持在線遷移、離線遷移、數(shù)據(jù)校驗、錄制回放等功能。結(jié)合UGO和DRS遷移工具，實現(xiàn)主流數(shù)據(jù)庫到某廠商數(shù)據(jù)庫的自動化搬遷。圖3-4：數(shù)據(jù)庫遷移整體解決方案及工具集數(shù)據(jù)庫遷移是一項復(fù)雜的系統(tǒng)工程，不僅需要高效和成熟的專業(yè)遷移工具和遷移方法論，面對遷移場景復(fù)雜、缺乏專業(yè)人員等問題，還需要專業(yè)服務(wù)保障用戶完成數(shù)據(jù)庫遷移。3.2.1數(shù)據(jù)庫對象遷移從業(yè)務(wù)視角看數(shù)據(jù)庫遷移，考慮的是整個業(yè)務(wù)系統(tǒng)的搬遷過程中有哪些環(huán)節(jié)需要遷移和改造。展現(xiàn)層不包含數(shù)據(jù)庫對象，因此不需要考慮改造和遷移。業(yè)務(wù)邏輯層作為業(yè)務(wù)邏輯和數(shù)據(jù)庫交互的模塊，最常見的使用持久層框架如MyBatis等，或者直接使用SQL語句，其中包含了大量的SQL語句，因此需要進(jìn)行改造。存儲層包含了數(shù)據(jù)庫對象和數(shù)據(jù)，需要進(jìn)行完整遷移。3

正式遷移2

遷移演練遷移實施時間軸業(yè)務(wù)驗證普通索引/視圖/函數(shù)/存儲過程全量開始前，就啟動增量數(shù)據(jù)抽取，保證數(shù)據(jù)絕對完整用戶點擊任務(wù)完

成，進(jìn)行觸發(fā)器

和事件的遷移任務(wù)結(jié)束隨著國內(nèi)金融業(yè)數(shù)據(jù)庫升級改造進(jìn)程的不斷加速，越來越多金融機構(gòu)的存量業(yè)務(wù)系統(tǒng)亟需遷移到國產(chǎn)數(shù)據(jù)庫平臺上。對已經(jīng)穩(wěn)定運行的業(yè)務(wù)系統(tǒng)進(jìn)行跨數(shù)據(jù)庫遷移，是一項工作量巨大的工程，具有較高的復(fù)雜度和風(fēng)險，這不僅要求數(shù)據(jù)庫廠商不斷完善其數(shù)據(jù)庫產(chǎn)品與存量數(shù)據(jù)庫之間的兼容性，也要求數(shù)據(jù)庫升級改造責(zé)任主體仔細(xì)評估存量業(yè)務(wù)所采用的SQL語句和數(shù)據(jù)庫相關(guān)配置，確保應(yīng)用成功上線。提供一站式遷移解決方案、一系列完整的遷移改造工具和遷移專業(yè)服務(wù)，從調(diào)研評估、方案制定、應(yīng)用改造、遷移演練和實施等方面幫助用戶完成應(yīng)用適配和數(shù)據(jù)庫遷移。遷移實施時間軸普通索引/視圖/函數(shù)/存儲過程用戶點擊任務(wù)完

任務(wù)結(jié)束成，進(jìn)行觸發(fā)器和事件的遷移√

無需修改√√√

數(shù)據(jù)遷移√

集成驗證

數(shù)據(jù)

對象采集對象轉(zhuǎn)換兼容性評估

對象遷移JDBC協(xié)議C++PythongoCshellJava…JDBC17

區(qū)域性銀行數(shù)據(jù)庫改造實踐

區(qū)域性銀行數(shù)據(jù)庫改造實踐18對象評估/遷移(UGO)評估+轉(zhuǎn)換+遷

移數(shù)據(jù)庫對象應(yīng)用遷移評估(UGO)掃描+評估+

轉(zhuǎn)換應(yīng)用sql數(shù)據(jù)遷移(DRS)基于日志的實時

變化數(shù)據(jù)捕捉數(shù)據(jù)校驗(DRS)基于日志的增量數(shù)據(jù)實時校驗1

實施前準(zhǔn)備信息調(diào)研遷移評估工具部署3.2數(shù)據(jù)庫遷移實踐4

應(yīng)用上線商業(yè)數(shù)據(jù)庫華為云數(shù)據(jù)庫業(yè)務(wù)驗證SQL審核(UGO)錄制回放(DRS)業(yè)務(wù)仿真驗證，保證遷移后業(yè)務(wù)穩(wěn)定高效運行對象遷移轉(zhuǎn)換后對象對象對比源代碼中的sql腳本中的sql…Mybatis配置文件…程序運行時，實際存在的sql對象遷移1

全量遷移

對象遷移2增量遷移對象遷移3增量數(shù)據(jù)抽取增量數(shù)據(jù)抽取HTMLCSSJavascript代碼中SQL配置文件SQL動態(tài)JDBCSQL全量開始前，就啟動增量數(shù)據(jù)抽取，保證數(shù)據(jù)絕對完整MybatisPlusHibernateSpringDataMybatisTopLinkopenJPA一致性校驗

(行數(shù)/內(nèi)容)業(yè)務(wù)驗證一致性校驗

(行數(shù)/內(nèi)容)業(yè)務(wù)驗證應(yīng)用SQL轉(zhuǎn)化對象遷移1

全量遷移對象遷移2圖3-5：數(shù)據(jù)庫遷移業(yè)務(wù)視角遷移規(guī)劃灰度并線割接上線持久化業(yè)務(wù)邏輯對象數(shù)據(jù)主流商用數(shù)據(jù)庫開源數(shù)據(jù)庫展現(xiàn)層存儲業(yè)務(wù)邏輯持久化協(xié)議提前識別SQL規(guī)范、設(shè)計、性能問題觸發(fā)器/事件/作業(yè)觸發(fā)器/事件/作業(yè)表結(jié)構(gòu)/主鍵/唯一鍵表結(jié)構(gòu)/主鍵/唯一鍵持續(xù)運行，實時同步數(shù)據(jù)

改造點分析

云上RDS3RD自研內(nèi)核增量遷移（短期）門禁集成兼容評估PLSQL遷移改造建議DDL遷移應(yīng)用改寫流量捕獲數(shù)據(jù)同步應(yīng)用掃描列級比對行級比對SQL采集在線遷移實時轉(zhuǎn)換流量仿真內(nèi)容比對SQL轉(zhuǎn)換組合校驗DML遷移數(shù)據(jù)訂閱一鍵審核遷移評估多活災(zāi)備性能分析

業(yè)務(wù)系統(tǒng)持續(xù)采集應(yīng)用SQL對象初始化時執(zhí)行一次初始化時執(zhí)行一次比對數(shù)據(jù)準(zhǔn)確性門禁化持續(xù)運行 OpenAPI

轉(zhuǎn)換后sql對象遷移3應(yīng)用遷移改造后

ODBC

展現(xiàn)層PostgreSQLMySQLGaussDB線下DDS云上……圖3-9：應(yīng)用遷移圍繞業(yè)務(wù)邏輯和數(shù)據(jù)庫連接開展在某大型銀行的應(yīng)用改造實踐中，數(shù)據(jù)庫工具成功支撐了對該銀行上億行SQL語句的改造，其中超過95%的SQL語句為數(shù)據(jù)庫自身兼容或通過遷移工具轉(zhuǎn)換而兼容，極大降低了人力投入，提升了兼容性轉(zhuǎn)換效率和準(zhǔn)確率。3.3.3數(shù)據(jù)庫數(shù)據(jù)遷移對象遷移完成后進(jìn)行業(yè)務(wù)數(shù)據(jù)遷移，數(shù)據(jù)遷移分為存量數(shù)據(jù)遷移和增量數(shù)據(jù)實時同步。相關(guān)工具可解決如何在業(yè)務(wù)近乎不停機的情況下快速將用戶的存量數(shù)據(jù)和增量數(shù)據(jù)遷移過來，并保證數(shù)據(jù)在任何情況下不丟、不錯、不亂，同時提供靈活、多樣的數(shù)據(jù)比對和修復(fù)能力，降低數(shù)據(jù)庫之間數(shù)據(jù)流通的復(fù)雜性，有效地幫助用戶減少數(shù)據(jù)傳輸?shù)某杀?。圖3-7：對象遷移圖示3.2.2應(yīng)用改造遷移應(yīng)用遷移可以提取并分析應(yīng)用程序中的SQL語句，用戶在需要改造業(yè)務(wù)應(yīng)用時可以使用遷移工具的應(yīng)用遷移功能。借助遷移工具，數(shù)據(jù)庫升級改造責(zé)任主體可以快速評估應(yīng)用改造工作量及改造難度，以工具評估結(jié)果為基礎(chǔ)合理安排應(yīng)用改造計劃和資源投入，可以確保應(yīng)用改造有序開展并取得最終的成功。遷移工具需采集業(yè)務(wù)代碼Mybatis

XML、Java代碼、SQL腳本等文件中的SQL語句，對采集到的SQL語句進(jìn)行評估和轉(zhuǎn)換。圖3-8：應(yīng)用遷移圖示針對應(yīng)用改造，主要圍繞整個業(yè)務(wù)系統(tǒng)的業(yè)務(wù)邏輯層和數(shù)據(jù)庫連接層來開展，重點審視三類對象中的SQL語句：·代碼中內(nèi)嵌的SQL語句·配置文件中的SQL語句·動態(tài)生成的SQL語句預(yù)遷移評估循環(huán)校正轉(zhuǎn)換計劃持續(xù)驗證圖3-6：數(shù)據(jù)庫評估圖示對象遷移可以根據(jù)評估結(jié)果用戶自行遷移方案的配置，且轉(zhuǎn)換前可以過濾對象，因為并非所有采集出來的對象都需要進(jìn)行遷移，用戶可以結(jié)合業(yè)務(wù)進(jìn)行過濾，然后進(jìn)行自動轉(zhuǎn)換。這也是異構(gòu)數(shù)據(jù)庫遷移的核心訴求，用戶在要進(jìn)行實際的數(shù)據(jù)庫對象遷移時可以使用相關(guān)工具的對象遷移功能。目標(biāo)庫選型GaussDB改造工作量評估測試&上線工作量(人天)

20數(shù)據(jù)庫評估可以評估異構(gòu)數(shù)據(jù)庫語法轉(zhuǎn)換率，提前識別遷移風(fēng)險，可以連接源庫進(jìn)行數(shù)據(jù)庫對象采集，性能采集等，基于采集的信息分析語法兼容性和到各個目標(biāo)庫之間的兼容性，用戶可以結(jié)合評估出來的數(shù)據(jù)進(jìn)行目標(biāo)庫類型和規(guī)格的選型以及遷移人力安排，能幫助用戶決策與工作規(guī)劃。SQL采集動態(tài)采集

靜態(tài)采集…

…應(yīng)用遷移源代碼中的sql腳本中的sql…Mybatis配置文件…程序運行時，實際存在的sql…19

區(qū)域性銀行數(shù)據(jù)庫改造實踐

區(qū)域性銀行數(shù)據(jù)庫改造實踐

20SQL評估…ObjectTypeValueCountModificationSuggestionTableREVERSE100XXXXXXXFunctionxxx90xxxTableBITMAP80XXXXXXXSQL轉(zhuǎn)換…源碼改造…目標(biāo)數(shù)據(jù)庫云數(shù)據(jù)庫本地數(shù)據(jù)庫源數(shù)據(jù)庫云數(shù)據(jù)庫本地數(shù)據(jù)庫JDBC數(shù)據(jù)源庫畫像

需要改造SQL列表

需要改造源碼列表

C

C++Pythongo shell

Java…

對象兼容性

HTMLCSSJavascriptMybatisPlusHibernateSpringDataMybatisTopLinkopenJPA動態(tài)JDBC

SQL配置文件SQL代碼中SQLDBA工作量(人天)20開發(fā)工作量(人天)5評估報告不兼容語法點TomcatJBossSQL改造位置Spring-boot

C#源、目標(biāo)對比SQL改造列表轉(zhuǎn)換報告MybatisxmlJAVA改造提示改造確認(rèn)輔助人工改造自動改造展現(xiàn)層業(yè)務(wù)邏輯存儲持久化協(xié)議TOP不兼容特性目標(biāo)庫確認(rèn)…MYSQLPGGAUSS驗證上線對象校正源庫采集語法轉(zhuǎn)換語法差異分析OpenAPIODBC對象語法解析DBDBDBDBUGO◆發(fā)展現(xiàn)狀簡介：總部位于蘇州市吳江區(qū)，截至2025年上半年資產(chǎn)總額2232億元，擁有95家網(wǎng)點，是服務(wù)地方的區(qū)域性銀行。戰(zhàn)略愿景：推動規(guī)模、效益與質(zhì)量均衡發(fā)展，“5年再造一個蘇州農(nóng)商銀行”。科技投入：截至2025年6月，全行員工1953人，科技員工157人，年科技投入高于行業(yè)3%平均水平（24年，5.4%）。◆業(yè)務(wù)挑戰(zhàn)業(yè)務(wù)挑戰(zhàn)：面臨大行/股份制

“數(shù)字化”下沉業(yè)務(wù)渠道、同區(qū)域其他城商/農(nóng)信激烈競爭?？萍继魬?zhàn)：核心系統(tǒng)承載在老舊的Power小機+IBM存儲，性能和穩(wěn)定性存在風(fēng)險。存貸匯業(yè)務(wù)是銀行最核心、最基礎(chǔ)的三項業(yè)務(wù)，是銀行生存和發(fā)展的根基，也被形象地稱為銀行業(yè)的“三大基石”，負(fù)責(zé)全行存貸款業(yè)務(wù)，對于數(shù)據(jù)庫的性能、高可用性、穩(wěn)定性等方面都有嚴(yán)格的要求。系統(tǒng)建設(shè)目標(biāo)及挑戰(zhàn)：1.平滑替換DB2，提升性能及安全等級，持續(xù)推動業(yè)務(wù)穩(wěn)定運行。雙集群強一致方案規(guī)避數(shù)據(jù)丟失風(fēng)險、提升了管理效率、聯(lián)機響應(yīng)時間縮短至30毫秒，日終批處理時間由80分鐘壓縮至18分鐘，關(guān)鍵性能指標(biāo)穩(wěn)居同業(yè)前列。2.

熱點數(shù)據(jù)沖突，突破熱點賬戶并發(fā)控制、歷史數(shù)據(jù)遷移校驗等技術(shù)難題，日均交易承載能力提升10倍。3.

極簡運維，業(yè)務(wù)長穩(wěn)測試TPS峰值抖動率<6%，容災(zāi)演練及高可用（RTO<90s）要求通過核心業(yè)務(wù)高峰模擬指標(biāo)要求?！艮D(zhuǎn)型實踐早在2020年，該行便以敏捷交付模式啟動分布式技術(shù)布局；2023年，在人行支付系統(tǒng)率先應(yīng)用國產(chǎn)高斯數(shù)據(jù)庫，并通過銀聯(lián)業(yè)務(wù)系統(tǒng)、核心歷史庫系統(tǒng)等樣板工程驗證國產(chǎn)技術(shù)可行性。這場核心系統(tǒng)升級并非一蹴而就，而是歷經(jīng)3年，在渠道服務(wù)、風(fēng)險管理、基礎(chǔ)設(shè)施等領(lǐng)域?qū)崿F(xiàn)階梯式躍遷：云原生分布式架構(gòu)打破數(shù)據(jù)孤島，

A類超網(wǎng)系統(tǒng)創(chuàng)新實踐積累適配經(jīng)驗，最終形成“試點驗證—流程優(yōu)化—圖3-10：數(shù)據(jù)遷移圖示整個遷移過程需提供向?qū)竭w移，進(jìn)入數(shù)據(jù)庫復(fù)制服務(wù)控制臺->開始創(chuàng)建遷移任務(wù)->選擇遷移鏈路和類型->配置源庫、目標(biāo)庫和任務(wù)配置信息->預(yù)檢查及任務(wù)確認(rèn)->查看遷移任務(wù)狀態(tài)。數(shù)據(jù)庫遷移工具可提供在線遷移能力，通過全量數(shù)據(jù)遷移和增量數(shù)據(jù)遷移幫助用戶實現(xiàn)在線遷移，減少業(yè)務(wù)停機時間。全量數(shù)據(jù)遷移通過查詢源庫表數(shù)據(jù)，并將查詢結(jié)果寫入目標(biāo)庫實現(xiàn)數(shù)據(jù)遷移，增量數(shù)據(jù)遷移通過CDC技術(shù)實時解析數(shù)據(jù)庫日志，并將解析到的數(shù)據(jù)實時寫入目標(biāo)庫。21

區(qū)域性銀行數(shù)據(jù)庫改造實踐

區(qū)域性銀行數(shù)據(jù)庫改造案例

224.1蘇州農(nóng)商行存貸匯業(yè)務(wù)數(shù)據(jù)庫轉(zhuǎn)型實踐日均交易量承載能力(萬筆)100010倍100現(xiàn)網(wǎng)

GaussDB日終批處理時間(分鐘)3倍10030現(xiàn)網(wǎng)

GaussDB◆發(fā)展現(xiàn)狀隨著科技轉(zhuǎn)型的不斷提速，行里重要系統(tǒng)數(shù)據(jù)庫需進(jìn)行創(chuàng)新改造，以應(yīng)對業(yè)務(wù)發(fā)展對于數(shù)據(jù)庫平臺提出的更高級別的性能、可靠性要求?！魳I(yè)務(wù)挑戰(zhàn)隨著國內(nèi)數(shù)據(jù)庫改造的持續(xù)演進(jìn)，金融重要交易系統(tǒng)對數(shù)據(jù)庫整體架構(gòu)提出了明確要求。首先，數(shù)據(jù)庫架構(gòu)要求極致的高可靠，穩(wěn)定、可靠的軟硬件架構(gòu)，硬件冗余，各個組件故障能夠快速隔離，不能導(dǎo)致業(yè)務(wù)受影響，敏感數(shù)據(jù)不能丟失，數(shù)據(jù)安全得到保障。其次，算力資源和存儲資源可要獨立便捷擴容，提升資源利用率，節(jié)省成本。第三，交易時延低而且穩(wěn)定均衡。第四，運維簡單高效，硬件的故障，比如盤的故障不切數(shù)據(jù)庫節(jié)點，業(yè)務(wù)無感，數(shù)據(jù)重建業(yè)務(wù)無感?！艮D(zhuǎn)型實踐GaussDB數(shù)據(jù)庫作為數(shù)據(jù)庫創(chuàng)新改造的主路線，采用GaussDB+OceanStor

Dorado的數(shù)據(jù)庫存算分離方案進(jìn)行數(shù)據(jù)庫系統(tǒng)的創(chuàng)新改造。數(shù)據(jù)庫架構(gòu)采用生產(chǎn)中心和同城1主3備+1仲裁單集群拉遠(yuǎn)部署，各節(jié)點的存儲資源采用OceanStor

Dorado存儲池劃分的LUN資源，生產(chǎn)到同城實現(xiàn)數(shù)據(jù)庫集群內(nèi)雙活，數(shù)據(jù)庫主備節(jié)點同步復(fù)制，確保RPO=0。生產(chǎn)中心同城中心災(zāi)備中心全量切換”的成熟升級路徑，為行業(yè)創(chuàng)新轉(zhuǎn)型提供實踐指南。核心庫采用集中式存算分離強一致方案部署，備節(jié)點開啟只讀模式，提供讀寫分離，下游取數(shù)庫通過存儲快照快速構(gòu)建近實時數(shù)據(jù)（生產(chǎn)庫）供下游數(shù)據(jù)庫讀取數(shù)據(jù)?！?/p>

生產(chǎn)庫主、備集群都有完整的數(shù)據(jù)，主集群異常情況下可實現(xiàn)自動容災(zāi)切換，保障業(yè)務(wù)連續(xù)性?！ず诵膸觳捎眉惺揭恢鲀蓚洳渴鸱桨浮Ｖ骷号c備集群之間采用同步復(fù)制進(jìn)行數(shù)據(jù)同步，保證RPO=0?！は掠稳?shù)庫通過存儲快照快速構(gòu)建近實時數(shù)據(jù)（生產(chǎn)庫）供下游數(shù)據(jù)庫讀取數(shù)據(jù)，分?jǐn)傊鲙斓呢?fù)載?！艮D(zhuǎn)型效果通過與華為GaussDB+企業(yè)存儲存算分離整體方案的合作，蘇州農(nóng)商行在存貸匯核心系統(tǒng)上取得了顯著的成果。從硬件服務(wù)器到高斯數(shù)據(jù)庫，再到應(yīng)用層，實現(xiàn)全棧創(chuàng)新替代，搭建起自主可控的金融科技底層架構(gòu)?；贕aussDB的分布式架構(gòu)，新系統(tǒng)性能實現(xiàn)跨越式提升：日均交易量承載能力從100萬筆躍升至1000萬筆，系統(tǒng)交易峰值處理能力從200筆/秒到可達(dá)6800筆/秒，聯(lián)機響應(yīng)時間縮短至30毫秒，日終批處理時間由80分鐘壓縮至18分鐘，關(guān)鍵性能指標(biāo)穩(wěn)居同業(yè)前列。主集群主

備

ETCD

備

備GaussDB

GaussDBGaussDB

GaussDB

GaussDB23

區(qū)域性銀行數(shù)據(jù)庫改造案例

區(qū)域性銀行數(shù)據(jù)庫改造案例

244.2廣發(fā)銀行支付業(yè)務(wù)數(shù)據(jù)庫創(chuàng)新實踐OceanStor

Dorado

OceanStor

Dora