規(guī)劃（2022-2025年）》中，強調(diào)打造數(shù)字綠色服務(wù)體系，建設(shè)算一體架構(gòu)可以有效滿足金融新興業(yè)務(wù)初期對快速和敏捷交付的需求，但隨著金融業(yè)務(wù)的增長和基礎(chǔ)設(shè)施規(guī)模的擴大，存算一體架構(gòu)在可靠性和擴展性方面的局限性逐漸顯現(xiàn)。因此，開金融業(yè)數(shù)據(jù)庫技術(shù)架構(gòu)演變歷 金融業(yè)應(yīng)用對數(shù)據(jù)庫的需求現(xiàn) 金融場景業(yè)務(wù)特 金融業(yè)數(shù)據(jù)庫應(yīng)用的基礎(chǔ)架構(gòu)問題和需 主流數(shù)據(jù)庫存算分離架構(gòu)技術(shù)分 集中式數(shù)據(jù)庫存算分離技 分布式數(shù)據(jù)庫存算分離技 云原生數(shù)據(jù)庫存算分離技 數(shù)據(jù)庫存算分離架構(gòu)選型評估指標(biāo)與建 性能指 可靠性指 可用性指 成本效益分 能耗指 擴展性指 安全性要 運維指 演進能 總 數(shù)據(jù)庫存算分離架構(gòu)演進方 外置存儲的存算分離架 存算協(xié)同的存算分離架 金融業(yè)數(shù)據(jù)庫存算分離架構(gòu)應(yīng)用實 工商銀行數(shù)據(jù)庫存算分離架構(gòu)實 農(nóng)業(yè)銀行新一代存算分離數(shù)據(jù)庫實 平安銀行MySQL數(shù)據(jù)庫存算分離架構(gòu)探 上海銀行數(shù)據(jù)庫存算分離架構(gòu)的應(yīng)用試點實 微眾銀行TDSQL+OceanDisk存算分離架 人保壽險數(shù)據(jù)庫存算分離架構(gòu)轉(zhuǎn)型升 總 第一階段（19601970年代）：采用存算分離架構(gòu)的文件狀數(shù)據(jù)庫（IDS）和層次數(shù)據(jù)庫（IMS）等形態(tài)。IBM于1966年第二階段（19702000年左右）：關(guān)系型數(shù)據(jù)庫蓬勃發(fā)榮時代。盡管如此，Oracle和DB2依然是市場最主流的商用與此同時，RAIDSCSI接口標(biāo)準(zhǔn)的發(fā)布，以及展性等方面實現(xiàn)顯著提升。由此，ITIBM小型第三階段（2000年至今）：數(shù)據(jù)庫技術(shù)呈現(xiàn)多元化發(fā)展趨X86服務(wù)器憑借其價格優(yōu)勢和通用性，一定程度上擴展了傳統(tǒng)NVMeOverFabric、RDMA和存儲介質(zhì)等技術(shù)11鑒于生產(chǎn)交易系統(tǒng)的聯(lián)機事務(wù)處理（OLTP）特性，OLTP在處理聯(lián)機分析處理（OLAP）OLAP數(shù)據(jù)庫憑借其對復(fù)雜查詢的高效處理、靈活的數(shù)據(jù)分析能理和分析的需求。在金融業(yè)數(shù)據(jù)庫應(yīng)用中，OLAP數(shù)據(jù)庫實例數(shù)傳統(tǒng)封閉架構(gòu)向開放解耦架構(gòu)轉(zhuǎn)型的過程中面臨諸多挑戰(zhàn)，包2率超過50，數(shù)據(jù)量年增長率約為30。新興業(yè)務(wù)模式拓寬金融業(yè)務(wù)量的激增對數(shù)據(jù)基礎(chǔ)設(shè)施的性能和吞吐量提出更高要s。一般銀行業(yè)務(wù)平均SQL請30-50QL10O讀IO1.5-2.5百萬次IOCPU在業(yè)務(wù)處理方面的心基礎(chǔ)架構(gòu)的可靠性需提升至99.9999以上，以滿足整體業(yè)務(wù)1000-3000筆每秒，RAID卡或硬盤用于在數(shù)據(jù)故障后提供冗余保護。然而在可靠性方面，RAID卡35個9，實現(xiàn)2個數(shù)量級的提升。456存儲同步復(fù)制方案，結(jié)合數(shù)據(jù)庫層的日志異步復(fù)制方案，如OracleRAC+OracleADG。該方案可以保障同城跨數(shù)據(jù)中心雙集群實現(xiàn)RPO=0，即數(shù)據(jù)無丟失，并通過疊加異地容災(zāi)技術(shù)，實現(xiàn)兩地三中心分鐘級678LANFree備9通過Quota配額和QoS服務(wù)質(zhì)量實現(xiàn)應(yīng)用的隔離和資源保障。存1011業(yè)使用比例僅為17.51，而證券和保險行業(yè)這一比例甚至不足1215個，分表據(jù)庫服務(wù)器，運維人員增加了66，開發(fā)人員增加了5倍，5年數(shù)據(jù)庫分庫分表及或多副本冗余機制會導(dǎo)致集群規(guī)模的擴省電信為例，數(shù)據(jù)庫改造后CPU利用率僅有5，數(shù)據(jù)庫服務(wù)器數(shù)量增加逾10倍，新增年功耗22萬千瓦時，增幅高達65，顯然無法滿足企業(yè)降本增效的需求。某國有大行數(shù)據(jù)庫改造后，存儲資源利用率僅3，CPU利用率僅不到10，數(shù)據(jù)庫服務(wù)器數(shù)而引發(fā)數(shù)據(jù)庫集群主備兩端數(shù)據(jù)不一致的問題。因此，在實際操間的主從切換可能會造成業(yè)務(wù)的短暫中斷或應(yīng)用報錯，影響業(yè)SQL13“OceanBase+專業(yè)存儲”華為GaussDB存算分離雙集群方案能夠?qū)崿F(xiàn)數(shù)據(jù)庫高可14“GaussDB+專業(yè)存儲”15下圖展示了PolarDB采用計算與存儲分離的設(shè)計理念，滿足公共云計算環(huán)境下根據(jù)業(yè)務(wù)發(fā)展彈性擴展集群的需求。在16PolarDBHTAP存算分離部署來實現(xiàn)HTAP能力。17GaussDBHTAP將存儲池化和內(nèi)存池化技術(shù)與HTAP相結(jié)合，可以為18TDSQL-C隨著云計算技術(shù)的不斷發(fā)展，Serverless已成為云原生數(shù)據(jù)戶的多樣化需求。因此，Serverless數(shù)據(jù)庫需具備智能彈性能力。Serverless數(shù)據(jù)庫未來的關(guān)鍵能力之一，有萬tpmC@10ms(90th)。（注：90th表示90比例）。0.1ms的存儲性能。于20GB/s的存儲性能。5TB/h。能力?！缎畔踩夹g(shù)信息系統(tǒng)災(zāi)難恢復(fù)規(guī)范》對信息系統(tǒng)的災(zāi)可用方案可實現(xiàn)RPO=0，RTO<120S。實現(xiàn)RPO=0，RTO<120S。中心異地高可用方案實現(xiàn)RPO＜1分鐘，RTO<10分鐘。LanFree級備份，數(shù)據(jù)備份流量走存復(fù)，百TB級數(shù)據(jù)庫分鐘級恢復(fù)。5分鐘。1RTO/RPO2(臺高度（(臺高度（-30.8RAIDTP（允許3本地盤存儲（三副本-50消耗的能量，包括CPU、GPU等。要6臺服務(wù)器；2）采用存算分離共享存儲架構(gòu)，2臺服務(wù)器+14-39盤為兩套MySQL集群，功耗預(yù)計節(jié)省39。于5。提供存儲陣列級加密，性能影響小于20。簡化維護：分離架構(gòu)使得系統(tǒng)維護和升級更為簡單，在金融業(yè)的業(yè)務(wù)系統(tǒng)中，數(shù)據(jù)庫承擔(dān)著關(guān)鍵的角色，涉及大量在評估存算分離架構(gòu)和存算一體架構(gòu)時，需要從多個維度進行深入5vs.節(jié)點的故障可能會影響更多服務(wù)。輸能力，實現(xiàn)數(shù)據(jù)庫IOPS性能提升，IO時延下降。19內(nèi)及數(shù)據(jù)中心間的數(shù)據(jù)一致性和完整性；三是采用標(biāo)準(zhǔn)SAN協(xié)據(jù)庫類型，以及ARM、X86等多計算平臺。場景1：客戶關(guān)鍵類業(yè)務(wù)系統(tǒng)，兩地三中心部署，要求同城場景210至60TB左右，采用數(shù)據(jù)務(wù)標(biāo)記，存儲通過快照讀取備份數(shù)據(jù)，備份性能可達2GB/s，103：客戶批量改造現(xiàn)網(wǎng)數(shù)據(jù)庫，若采用sharenothing數(shù)據(jù)4：數(shù)據(jù)庫全棧改造升級，需要在滿足當(dāng)前業(yè)務(wù)性能基2090個?；叶确峙辛骱蛻?yīng)急回切等措施來規(guī)避。和復(fù)雜計算批量場景的需求，具備百萬級QPS能力。分離架構(gòu)與廠商進行大型業(yè)務(wù)系統(tǒng)0racle數(shù)據(jù)庫轉(zhuǎn)型的多集群步，異地園區(qū)間通過異步方式實現(xiàn)增量日志同步，具備本地RPO=0&RTO<30RPO=0&RTO<180分鐘&RTO<10,RPO=0&RTO<180秒的回切能力。同城雙集群署架構(gòu)示意如圖2122為解決遷移轉(zhuǎn)換工作量大，測試覆蓋難等問題，工商銀行聯(lián)合本壓降90以上，突破了數(shù)據(jù)庫轉(zhuǎn)型的技術(shù)瓶頸和實施障礙。自覆蓋率達95，保障數(shù)據(jù)庫架構(gòu)轉(zhuǎn)型過程平穩(wěn)可控。15OGB/小時。經(jīng)過大量實踐，工商銀行形成了一套無需整體重構(gòu)Oracle進一步提升產(chǎn)品易用性，引入集群單浮動IP和跨集群單浮動IP。通過vmware虛擬化進行資源隔離，操作系統(tǒng)是REDHAT，存儲2315分鐘甚至更久，難以滿足金融業(yè)的需求。但是使用的VMWARE虛擬化技術(shù)、紅帽操作系統(tǒng)、服務(wù)器硬件四是虛擬機OSOS方案一：存算分離虛擬化方案一：存算分離虛擬化ARM/海光信創(chuàng)服務(wù)器；二是24方案二：容器化方案二：容器化MYSQL上容方案，可能是未來的部署方案，目前還只是在現(xiàn)Serverless能力。25上圖為容器化后MYSQL的架構(gòu)方案，該方案使用外接共享一是RTO和RPO的提升。存算分離后，在容器化部署中，K8S的調(diào)度能力做到切換到雙活的MYSQL進行對外提供服務(wù)。為此試點使用TDSQL數(shù)據(jù)庫（使用集中式實例模式）和集中式服務(wù)器/26管控系統(tǒng)：負責(zé)TDSQL集群的監(jiān)控運維，包括高可用切換、27通過實際性能測試比較，使用集中存儲陣列(OceanStorDorado18500V6)、全閃SSD硬盤（NVME協(xié)議），相比本地27存力和算力剝離，各司其職。計算節(jié)點DN節(jié)點負責(zé)執(zhí)行NVMe協(xié)議連接計算節(jié)點和存儲，達到充分利用SSD的高速讀寫能力和低延遲特性。NVMe協(xié)議通信,IO密集型數(shù)據(jù)庫，使用集中式存儲相構(gòu)不影響性能，降低IO的敏感度。微眾銀行TDSQL+OceanDisk微眾銀行TDSQL數(shù)據(jù)庫前期采用存算一體架構(gòu)，在線業(yè)務(wù)數(shù)據(jù)存放于數(shù)據(jù)庫服務(wù)器本地SSD盤，該架構(gòu)存在以下幾個問經(jīng)過產(chǎn)品調(diào)研和POC測試，選用華為分布式存儲設(shè)備OceanDiskTDSQL在線業(yè)務(wù)數(shù)據(jù)，實現(xiàn)TDSQL存算分離架構(gòu)。該架構(gòu)可提升TDSQL可靠性，提高資源利用率。TDSQL采用存算分離架構(gòu)，計算層采用X86或ARM架構(gòu)服務(wù)OceanDisk，數(shù)據(jù)庫服務(wù)器通過高速RoCEOceanDiskTDSQL以資源池的形式交付，CPU資源限制。每個實例使用獨立的邏輯卷，借助例獲得的IOPS、吞吐量和IO時延在可接受范圍內(nèi)。將數(shù)據(jù)庫主備節(jié)點均勻分布在不同的OceanDisk上，實現(xiàn)存儲負載均衡。為OceanDisk穩(wěn)定可靠運行，需控制其負載在一定閾6T，需避免因單實例過大導(dǎo)IOPS能力。通過OceanDisk的SmartQoS功能，為不同TDSQL實例或數(shù)據(jù)庫配置IOPS限額，避免資源競爭，保障關(guān)鍵業(yè)務(wù)的性設(shè)置指標(biāo)告警閾值（如CPU、IOPS、IO時延等），超過源消耗較大的SQL；前發(fā)現(xiàn)隱患SQL。TDSQL運維管理平臺覆蓋了80以上的日常運維操作，包點重建、故障分析等。WEB頁面操作通過設(shè)置多重檢查規(guī)則，高OceanDisk內(nèi)置web管理臺DeviceManager，操作功能完善，通過開發(fā)系列工具，對接TDSQLOSSOceanDiskRestfulAPITDSQL和OceanDiskTDSQL28需求。但對比本地SSD盤，OceanDisk較高的訪問時延會帶來性能影響，如SQL28IO讀時延上。影響數(shù)據(jù)庫性能，SQL執(zhí)行耗時上漲，上升，數(shù)據(jù)庫QPS呈下降趨勢。業(yè)務(wù)應(yīng)用系統(tǒng)使用TDSQL存算分離架構(gòu)前，應(yīng)針對各業(yè)務(wù)均衡資源使用率，提高資源利用率。1個TDSQL資源組包3單臺服務(wù)器上CPU、內(nèi)存的均衡使用，單臺OceanDisk容量、IOPS、IO時延的均衡。TDSQL盡量均衡。同時應(yīng)兼顧實例重要程度，保障關(guān)鍵實例的IOPS能力及IO時延。TDSQL的性能和故障問題可能與數(shù)據(jù)庫自身、OceanDisk或規(guī)格支持從10G到6T，支持在線擴容。靈活容量管理也帶來了務(wù)器CPU和內(nèi)存利用率。拷貝數(shù)據(jù)帶來的IO、帶寬資源消耗，以及重建時間較長帶來的OceanDiskRAID6配置。要基于傳統(tǒng)的小型機+SAN網(wǎng)絡(luò)+集中式存儲解決方案。然而現(xiàn)次改造的核心目標(biāo)是將現(xiàn)有的小型機+SAN網(wǎng)絡(luò)+集中式存儲的本項目通過選用基于存算分離架構(gòu)的平臺為Oracle數(shù)據(jù)庫21套災(zāi)備環(huán)20GB/s的吞吐。每一套環(huán)境根據(jù)容量需求使用6臺或5臺