《金融信息化研究所：2024金融數據庫存算分離架構選型白皮書（84頁）.pdf》由會員分享，可在線閱讀，更多相關《金融信息化研究所：2024金融數據庫存算分離架構選型白皮書（84頁）.pdf（84頁珍藏版）》請在三個皮匠報告上搜索。

1、本白皮書版權屬于北京金融信息化研究所有限責任公司，并受法律保護。轉載、編摘或利用其他方式使用本白皮書文字或觀點的，應注明來源。違反上述聲明者，將被追究相關法律責任。主主任：任：潘潤紅副主任：副主任：黃程林、莊文君編委會成員編委會成員（排名不分先后，按姓氏拼音排序）（排名不分先后，按姓氏拼音排序）：董曉杰、何東川、何佳佳、胡盼盼、黃濤、簡麗榮、王鵬沖、楊傳輝、張子鑒、朱鵬編寫組成員編寫組成員（排名不分先后，按姓氏拼音排序）（排名不分先后，按姓氏拼音排序）：鮑思佳、陳燦榮、陳輝、程靜、從平平、崔志偉、董里、金振山、李會亮、李云龍、李中原、梁燕、廖美東、劉常、劉方彪、劉昭、羅蘭瑞婧、馬攀、馬濤、明玉

2、琢、邵志杰、盛玉、萬里、王愛國、王成、王帥強、王耀強、徐贊、楊尚、張剛、張羿、趙蒙主編主編單位：單位：北京金融信息化研究所中國農業銀行股份有限公司中國郵政儲蓄銀行股份有限公司平安銀行股份有限公司上海銀行股份有限公司深圳前海微眾銀行股份有限公司中國人壽財產保險股份有限公司中國人民人壽保險股份有限公司華為技術有限公司北京奧星貝斯科技有限公司武漢達夢數據庫股份有限公司參編參編單位：單位：北京酷克數據科技有限公司阿里云（北京）科技有限公司平凱星辰（北京）科技有限公司中電科金倉（北京）科技股份有限公司北京海量數據技術股份有限公司天津南大通用數據技術股份有限公司成都虛谷偉業科技有限公司天津神舟通用數據技術

3、有限公司金融業作為信息技術應用的前沿陣地，展現出對新技術的較高敏銳度和快速響應能力。中國人民銀行印發的金融科技發展規劃（2022-2025 年）中，強調打造數字綠色服務體系，建設綠色高可用數據中心，架設安全泛在的金融網絡，布局先進高效的算力體系，夯實數字基礎底座，助力數字金融高質量發展。在創新發展和安全可控的雙重驅動下，我國數據庫作為金融信息系統的重要組成部分，在金融機構中的持續創新應用有效推動數字金融安全生態的構建。隨著金融業數字化轉型的深入，金融數據庫架構正逐步從傳統封閉走向創新開放。在此過程中，數據庫存算一體架構可以有效滿足金融新興業務初期對快速和敏捷交付的需求，但隨著金融業務的增長和基

4、礎設施規模的擴大，存算一體架構在可靠性和擴展性方面的局限性逐漸顯現。因此，開放解耦的存算分離架構，不僅能夠根據業務需求實現計算和存儲資源的獨立擴展，提供靈活的彈性擴縮容計算能力，還能利用存儲的高可靠性優勢，進一步提升整個集群處理海量數據的可靠性，重新成為數據庫場景的架構選擇。本報告針對金融業務場景的特點和需求，深入剖析當前主流數據庫存算分離技術架構方案，總結數據庫存算分離架構選型評估指標體系，構建數據庫存算分離架構實施路線，并總結金融機構的探索實踐經驗，為推動金融業數據庫架構創新發展貢獻力量。1.1.金融業金融業數據庫數據庫技術架構演變歷程技術架構演變歷程.1 12.2.金融業應用對數據庫的需

5、求現狀金融業應用對數據庫的需求現狀.3 32.1 金融場景業務特性.32.2 金融業數據庫應用的基礎架構問題和需求.53.3.主流數據庫存算分離架構技術分析主流數據庫存算分離架構技術分析.13133.1 集中式數據庫存算分離技術.143.2 分布式數據庫存算分離技術.163.3 云原生數據庫存算分離技術.224.4.數據庫存算分離架構選型評估指標與建議數據庫存算分離架構選型評估指標與建議.28284.1 性能指標.284.2 可靠性指標.294.3 可用性指標.314.4 成本效益分析.344.5 能耗指標.354.6 擴展性指標.374.7 安全性要求.384.8 運維指標.394.9 演進

6、能力.414.10 總結.415.5.數據庫存算分離架構演進方案數據庫存算分離架構演進方案.42425.1 外置存儲的存算分離架構.435.2 存算協同的存算分離架構.446.6.金融業數據庫存算分離架構應用實踐金融業數據庫存算分離架構應用實踐.46466.1 工商銀行數據庫存算分離架構實踐.466.2 農業銀行新一代存算分離數據庫實踐.546.3 平安銀行 MySQL 數據庫存算分離架構探索.576.4 上海銀行數據庫存算分離架構的應用試點實踐.616.5 微眾銀行 TDSQL+OceanDisk 存算分離架構.646.6 人保壽險數據庫存算分離架構轉型升級.717.7.總結總結.76761

7、金融業的數據庫技術架構演變緊跟金融業務的發展步伐，同時與數據庫和存儲等技術的進步相互促進，共同推動金融業創新發展。在過去的半個世紀里，數據庫技術架構的演變主要經歷了以下三個階段：第一階段第一階段（19601960 到到 19701970 年代年代）：采用存算分離架構的文件采用存算分離架構的文件系統數據庫，支持單體應用。系統數據庫，支持單體應用。早期的數據管理系統主要以文件系統為基礎，先后發展出網狀數據庫（IDS）和層次數據庫（IMS）等形態。IBM 于 1966 年推出的層次型數據庫 IMS，與該公司的服務器、存儲和中間件等產品緊密結合，提供了一站式解決方案，有效滿足核心業務交易和數據處理對高

8、可用性的需求，被廣泛應用于金融、航空和制造等領域。即便在互聯網飛速發展的時代，這些行業依然在使用IBM 的 IMS 數據庫。然而，由于單一廠商的封閉系統帶來昂貴的服務費用和有限擴展能力，這種解決方案成為僅在金融等少數行業應用。第二階段第二階段（19701970 年到年到 20002000 年左右年左右）：關系型數據庫蓬勃發關系型數據庫蓬勃發展，存算分離成為基礎架構。展，存算分離成為基礎架構。1970年代，IBM率先提出關系數據庫模型并發布了SQL標準。1979 年，Oracle 公司推出了首個商用關系型數據庫，而 IBM 直到 1983 年才發布其關系型數據庫 DB2。此后，Sybase、SQ

9、L Server等其他商用關系型數據庫也陸續進入市場，開啟關系型數據庫的繁榮時代。盡管如此，Oracle 和 DB2 依然是市場最主流的商用2數據庫產品。與此同時，RAID 磁盤專利和 SCSI 接口標準的發布，以及 EMC推出的高端存儲產品，都在吞吐性能、系統可靠性和容量擴展性等方面實現顯著提升。由此，IT 產業逐步形成以 IBM 小型機、Oracle 數據庫和 EMC 存儲為核心的 IOE 架構。這一架構成為“開放”和“解耦”的存算分離架構的基石，推動金融業信息化應用的發展，并促進金融業集中業務處理的區域性數據中心建設。第三階段（第三階段（20002000 年至今）：數據庫技術呈現多元化發

10、展趨年至今）：數據庫技術呈現多元化發展趨勢，存算分離架構依然是重要的架構方向。勢，存算分離架構依然是重要的架構方向。2000 年前后，隨著互聯網技術的廣泛應用，數據庫技術進入多元化混合發展的時代，數據庫應用更加多樣化。在此期間，X86 服務器憑借其價格優勢和通用性，一定程度上擴展了傳統IOE 架構的“開放性”，但由于 x86 服務器在吞吐性能上的局限性以及可靠性方面的不足，相較于傳統 IOE 架構的服務器，新興數據庫應用被迫采用一主多副本、分庫分片等存算一體的架構形態，以提升吞吐性能和可靠性。在金融互聯網應用的初期，存算一體架構促進了互聯網技術在金融業務場景中的迅速推廣，成為金融業技術架構的重

11、要補充。但是，在存算一體架構下，上層應用對數據庫不再是單一的數據訪問，還需要考慮數據分布和可靠性等需求。這導致數據庫架構設計對應用的侵入性增強，應用與數據庫之間深度耦合，進而加劇了架構的“封閉性”。同時，隨著金融新興業務的擴張和基礎設施規模的增大，存算一體架構在可靠性和擴展性方面的局限性逐漸顯現，比如：存算一體架構中任意單節點的計算或存儲3故障都可能引發數據丟失和業務中斷，帶來業務連續性風險；存算一體架構無法實現存儲和計算資源的獨立擴展，兩者必須同步擴展，造成一定的資源浪費。另外，隨著 NVMe Over Fabric、RDMA 和存儲介質等技術的成熟應用，計算與存儲之間的網絡帶寬得到顯著提升

12、，有效緩解了存算分離架構在吞吐性能上的瓶頸。通過利用存儲的 RAID 和快照等高可靠特性，可以設計出多層次的容災和備份方案，既簡化了系統架構和運維，又提高了整體業務系統的可靠性。2.12.1 金融場景業務特性金融場景業務特性金融業的業務場景多種多樣，根據面向客戶和內部管理的不同需求，可將業務系統主要分為兩大類：生產交易系統（TP）和數據智能分析系統（AP）。圖 1 金融業主要業務場景生產交易系統主要為客戶提供一系列對外服務，覆蓋支付與清算、核心交易、中間業務、銀行卡、信貸管理、用戶管理以及4渠道接入等關鍵領域。這類系統對實時數據處理、隨機數據訪問和業務連續性有著極高要求，因此通常采用本地雙活加

13、異地主備的容災方案。鑒于生產交易系統的聯機事務處理（OLTP）特性，OLTP 數據庫因其出色的實時響應能力、高并發處理能力、強數據一致性以及高可用性等優點而受到青睞。根據金融信息化研究所金融業數據庫創新發展報告（2024）數據顯示，在金融業的數據庫應用領域中，OLTP 數據庫實例數占比 65%，充分體現了其在維護金融服務穩定性方面的核心地位。數據智能分析系統雖不直接面向客戶，但在輔助銀行實現高效運營和管理方面發揮著重要作用。該平臺支持多種業務系統，如反欺詐和反洗錢等風險管理系統、銀行產品績效管理、用戶畫像和精準營銷等。數據智能分析系統正逐步演進為支持準實時處理的系統，為關鍵業務提供及時的決策支

14、持。這類系統具備批量數據處理和順序數據訪問的特點，因此容災方案主要采用同城或者異地的主備容災方案，鮮有本地雙活方案。在處理聯機分析處理（OLAP）業務的數據智能分析平臺中，OLAP 數據庫憑借其對復雜查詢的高效處理、靈活的數據分析能力以及支持多維數據模型等優勢，滿足數據智能分析平臺對數據處理和分析的需求。在金融業數據庫應用中，OLAP 數據庫實例數占比約為 21%。5近年來，隨著大數據技術的迅猛發展，金融數據分析平臺的數據湖和湖倉一體正逐步轉向存算分離架構。然而，在生產交易場景中，數據庫處理的業務不僅至關重要，而且結構極為復雜，使得從傳統封閉架構向開放解耦架構轉型的過程中面臨諸多挑戰，包括性能

15、、可靠性、擴展性、成本和能耗等多個方面。因此，本文將著重分析生產交易場景下數據庫處理的業務特性。2.22.2 金融業數據庫應用的基礎架構問題和需求金融業數據庫應用的基礎架構問題和需求隨著金融數字化轉型的深入，金融業務形態發生顯著變化，特別是面向客戶提供服務的網上銀行、手機銀行和支付網關等新興技術的應用，使得金融業務模式從傳統的線下網點服務擴展到線上服務，從原來的 5*8 小時服務延長到 7*24 小時不間斷業務服務。這些業務模式的變化，極大地推動了移動金融服務的快速發展，也正在深刻影響并重塑著金融業數據庫應用的基礎架構。6圖 2 金融業生產交易場景的基礎架構從多數銀行公布的年報來看，新興金融服

16、務交易量年均增長率超過 50%，數據量年增長率約為 30%。新興業務模式拓寬金融服務的觸達渠道，延長服務時間，同時也正在重塑金融業的數據中心基礎架構。為適應未來業務發展，數據中心基礎設施必須在性能、可靠性、擴展性、能耗和總成本之間尋求最優架構。具體表現如下：2.2.12.2.1 吞吐性能吞吐性能業務量的激增對數據基礎設施的性能和吞吐量提出更高要求，例如數據庫讀寫時延需小于 1ms。一般銀行業務平均 SQL 請求數約為 30-50 次，每次 SQL 請求涉及約 10 次以上的存儲 IO 讀7寫。以中等銀行生產業務峰值交易量約 5000 筆/秒（即 5000TPS）為例，峰值業務處理所需的存儲 I

17、O 請求能力約為每秒 1.5-2.5百萬次讀寫（IOPS）。這種吞吐性能對傳統存算一體架構的服務器構成巨大挑戰，因為服務器 CPU 算力不僅要負責業務處理，還要完成數據可靠性、數據加密和數據壓縮等復雜的存儲處理任務，導致 CPU 資源緊張。然而，通過采用存算分離架構，所有數據存儲的 IO 請求可以卸載到外置存儲系統中處理，從而減輕服務器CPU 的負載，使其無需處理存儲 IO 請求，進而提升服務器 CPU在業務處理方面的能力。2.2.22.2.2 可靠性可靠性服務時間的延長對整體架構的可用性提出更高要求，數據中心基礎架構的可靠性需提升至 99.9999%以上，以滿足整體業務可用性 99.999%

18、的要求。中等規模銀行的核心系統交易量通常在 1000-3000 筆每秒，每秒的系統中斷和不可用都會導致 1000 筆以上的交易損失和用戶流失。存算一體架構的 x86 服務器在可靠性上僅能達到 99%。金融業統計顯示，x86 服務器使用超過 5 年，故障率超過 0.5%。如果采用服務器本地磁盤作為數據庫存儲，服務器上的 RAID 卡或硬盤亞健康等故障都可能影響數據庫的數據訪問，給生產交易系統的業務連續性帶來嚴峻挑戰。而在存算分離架構下，服務器僅負責數據邏輯處理，數據的持久化和可靠性等能力則由存儲設8備統一承擔，且存儲設備的可靠性遠高于服務器，通過存儲陣列RAID 技術和快照技術等特性，可以極大提

19、升整體業務的可靠性。服務器本地盤通過 RAID 卡串聯多塊硬盤組成 RAID 組，主要用于在數據故障后提供冗余保護。然而在可靠性方面，RAID 卡本身存在單點故障的風險。圖 3 存算一體和存算分離架構的存儲冗余設計對比圖通過對兩種系統形態的詳細測算，可以看出本地盤數據可用性僅為 3 個 9，而存算分離形態采用了全并行冗余架構，數據可用性可達到 5 個 9，實現 2 個數量級的提升。圖 4 存算一體和存算分離架構可靠性對比圖2.2.32.2.3 業務連續性業務連續性金融業對系統業務連續性有著嚴格要求，其中數據庫集群尤為重要，用戶通常按照災備建設的兩大標準和兩大衡量指標來規劃總體容災架構。9圖 5

20、 中國和國際的信息系統災備恢復標準的對應關系圖例如，對于 5-6 級核心類業務，除了要求數據本身的高可用外，對業務連續性也有極高要求。業界普遍做法是采用存儲本地雙活或存儲同步復制方案，結合數據庫層的日志異步復制方案，如 Oracle RAC+Oracle ADG。該方案可以保障同城跨數據中心雙集群實現 RPO=0，即數據無丟失，并通過疊加異地容災技術，實現兩地三中心分鐘級 RTO 恢復時間的容災能力。圖 6 存儲同步復制和數據庫異步復制方案示意圖2.2.42.2.4 擴展性擴展性隨著業務種類的增加，金融機構對數據庫的需求變得更為多10樣，對各類運營數據和報表系統等從生產系統數據庫中獲取數據的實

21、時性要求也隨之提高。銀行生產交易系統作為各類系統運營數據和報表等系統的數據源，如何實時獲取有效數據的同時最小化對生產系統業務的影響，成為各業務系統與生產交易系統之間的一大挑戰。在存算一體架構下，通常采用專用 ETL 工具抓取數據，會對業務系統造成性能干擾，因此只能選擇在夜間業務低谷時段抽取數據，這對后端系統分析數據的實時性造成影響。另外，每日批量作業需要在每日夜間定時從主庫快速生成一個數據庫集群，用于執行每日的讀寫操作。在存算分離架構下，可充分利用存儲的一致性快照和克隆等能力，快速構建生產交易系統的數據庫副本，滿足各類后端系統對業務數據實時性需求，并且對生產端數據庫的性能影響最小。11圖 7

22、基于存儲克隆實現數據快速復用示意圖證券機構在驗證系統變更后的業務連續性時，希望能在周末對主庫進行快照，用于通關測試。測試完成后，通過整庫閃回使數據庫恢復到測試前的狀態。在存算分離架構下，可以充分利用存儲快照和閃回特性，快速實現對源庫數據和狀態的保護及快速恢復，具有較高的閃回效率和最小的業務影響。12圖 8 基于存儲快照技術加速數據庫閃回示意圖另一方面，越來越多的數據庫集群在日常作業中涉及數據庫備份、每日批量作業或周末通關測試。為解決大容量數據庫場景下的快速備份問題，通過數據庫和存儲協同，實現 LAN Free 備份，提升備份速度，縮短備份窗口時間并減少對業務的影響。圖 9 存算分離架構和存算一

23、體架構下的備份方案對比圖132.2.52.2.5 系統運維系統運維多樣化的技術平臺（虛擬化和容器平臺）承載著多樣化的業務，產生更加多樣化的數據（包括結構化及非結構化數據），這使得各平臺的運維復雜度不斷增加。銀行業務種類繁多，各類應用平臺混合存在，因此數據庫種類多樣，對存儲的訴求也各不相同。在存算一體架構下，隨著集群節點的增加，各類數據庫的容災、備份和日常運維等工作量呈指數級增長。同時，數據中心的空間占用和耗電量也急劇增加，導致大多數銀行的數據中心面臨新建或擴建的需求。在存算分離架構下，采用分層解耦、按需分配的統一資源池方式，可以根據業務系統的等級分配不同的計算和存儲資源，并通過 Quota 配

24、額和 QoS 服務質量實現應用的隔離和資源保障。存算分離架構能夠兼顧物理服務器計算資源、虛擬化平臺和容器平臺的多樣性數據讀取需求，提高整體資源利用率和運維效率。此外，隨著全閃存儲的普及應用，存算分離架構下的全閃存儲在數據中心空間使用和能耗等方面進一步降低數據中心總體成本。隨著數字化轉型的加速推進，業務形態正經歷深刻變革，傳統應用與云及互聯網業務場景日益融合，業務動態性顯著增強。這不僅對基礎設施資源的靈活性和利用率提出更高要求，還伴隨著數據量的指數級增長和數據類型的多元化，給數據庫帶來實現14高性能和高可靠的挑戰。與此同時，業務高峰的持續上升還要求數據庫具備出色的彈性伸縮能力、持續服務能力以及合

25、理的成本。在多重因素的驅動下，無論是云原生、分布式還是傳統集中式數據庫市場，都在積極探索存算分離領域，數據庫部署架構呈現從“存算一體”向“存算分離”的演進趨勢。3.13.1 集中式數據庫存算分離技術集中式數據庫存算分離技術集中式數據庫的核心特征在于數據的集中存儲，這種架構為用戶提供了與單機數據庫相似的使用體驗，數據在邏輯上可以統一訪問，從而簡化應用開發和運維工作，無需過多考慮數據分片、分布式事務等問題，更好地支持存儲過程、多表關聯和復雜查詢。我國集中式數據庫主流架構可分為主備多副本和存算分離。據金融信息化研究所金融業數據庫供應鏈安全發展報告（2022）的數據顯示，在金融業中集中式數據庫占據主導

26、地位，整體占比達到 89%。具體來看，銀行業中的占比接近 79.62%，證券業和保險業的占比均超過 90%。詳細情況如下圖所示。15圖 10 金融業集中式數據庫占比情況示意圖集中式數據庫憑借其較強的功能黏性、優秀的系統穩定性和良好的軟硬適配能力，在金融業的應用仍占據絕大多數份額。隨著金融業數字化轉型的不斷深入，集中式數據庫需要更有效地支持海量、高并發、高吞吐量的新型金融業務應用系統。實現這一目標的關鍵在于提升專業共享存儲能力，并結合高帶寬、低延遲網絡優化數據庫架構。集中式數據庫可以采用存算分離的部署方式，以適應不斷變化的金融業務需求。圖 11 集中式數據庫從本地盤部署到存算分離部署架構圖16目

27、前，國內基于主從多副本架構的集中式數據庫由于實現簡單、技術門檻低，應用較為廣泛。然而，這種架構的數據庫主要存在如下瓶頸：一是受制于服務器可靠性導致存算一體架構爆炸半徑大、本地盤數據重構時間長；二是存算資源無法靈活擴展導致主從多副本架構需要較多硬件冗余，資源利用率較低，故障后數據庫服務恢復速度較慢；三是由于日志同步過程中產生的性能損耗較大，特別是有大量變更或大事務時，采用同步復制會明顯影響性能，使得一些主從多副本數據庫產品在高可用設計中不得不在性能和數據一致性之間做出權衡。采用存算分離架構的集中式數據庫能夠有效解決以下關鍵問題：一是使用可靠性更高的專用存儲設備提升數據持久化可靠性，同時減少硬盤故

28、障及故障恢復重構對數據庫服務的影響；二是通過存儲的高可用能力，替代傳統的數據庫日志復制方式進行持久化和容災，減小對性能的影響。存算解耦使得計算和存儲資源能夠按需分配，提高資源利用率；三是隨著存儲能力的提升，存算分離架構允許數據庫進一步實現副本縮減、容災、備份能力下沉，以及 IO 縮減和性能加速。通過采用控制器等針對數據庫優化的專業存儲設備，可以有效提升數據庫性能，加速數據庫密集型負載的處理。3.23.2 分布式數據庫存算分離技術分布式數據庫存算分離技術分布式數據庫在金融業主要應用于敏態業務場景，其核心特17征是數據跨多個節點分散存儲，并通過分布式事務實現并行處理，從而提升數據庫的并發性能和容量

29、。相較于集中式數據庫，分布式數據庫有效解決橫向擴展的難題，但由于分片間的數據同步和匯總依賴于網絡通信，尤其是在維護分布式事務的強一致性時，性能開銷顯著，因此更適合一些數據能夠完美分片的業務場景。當面臨大量分布式事務或復雜的多表間關聯查詢時，分布式數據庫的性能可能會大幅下降，進而影響其線性擴展。據金融業數據庫供應鏈安全發展報告顯示，我國分布式數據庫在銀行業使用比例僅為 17.51%，而證券和保險行業這一比例甚至不足4%。究其原因是我國數據庫研發周期短且應用范圍有限，其產品能力尚不完善。隨著分布式數據庫在核心業務不斷深入應用，當前多數國產數據庫采用存算一體、一寫多讀的架構，并通過單集群拉遠的方式來

30、實現容災，導致在數據庫升級過程中頻繁遇到一系列問題。圖 12 數據庫存算一體部署架構圖183.2.13.2.1 業務改造難度大，風險高業務改造難度大，風險高在進行我國數據庫改造時，需要通過分庫分表的方式，將大型數據庫拆分為多個小型數據庫，以提高系統的并發訪問能力和容量。然而，這種方法也帶來了一系列挑戰。一是復雜性增加。業務系統改造涉及數據拆分、數據路由和數據同步等方面工作，這增加系統的復雜性和實施難度。例如，一家頭部股份制銀行在升級改造中，分庫數量超過 15 個，分表數量超過 500 張，大幅增加了運維難度，甚至需要專門開發運維平臺來應對系統復雜度的提升。二是分布式事務影響性能。我國數據庫在處

31、理跨節點分布式事務時，可能導致數據庫性能下降。例如，北京某銀行在未進行業務改造前測試一款分布式數據庫時，發現因分布式事務導致性能下降了 50%。三是管理和維護困難。改造后的系統需要更多服務器節點來支持運行，增加故障定位定界的復雜度，導致運維投入顯著增加。以某全國性銀行的信用卡數據庫系統為例，原系統僅需 4 臺小型機，而分布式改造后采用服務器本地盤方式部署則需要 120 臺數據庫服務器，運維人員增加了 66%，開發人員增加了 5 倍，5 年整體擁有成本比原來提高了 60%以上。綜上所述，當前數據庫轉型升級面臨諸多挑戰，包括改造難度大、涉及面廣以及管理和維護難度的增加，都可能帶來重大的業務風險。1

32、93.2.23.2.2 雙碳集約目標面臨挑戰雙碳集約目標面臨挑戰數據庫分庫分表及或多副本冗余機制會導致集群規模的擴大和服務器數量的激增，同時服務器資源利用率卻極低，進而造成投資浪費、能耗增加、運維困難以及機房空間不足等問題。以某省電信為例，數據庫改造后 CPU 利用率僅有 5%，數據庫服務器數量增加逾 10 倍，新增年功耗 22 萬千瓦時，增幅高達 65%，顯然無法滿足企業降本增效的需求。某國有大行數據庫改造后，存儲資源利用率僅 3%，CPU 利用率僅不到 10%，數據庫服務器數量更是達到了 20000 多臺，迫使該行因機房空間不足而需擴建數據中心。這種大規模的數據庫服務器部署和極低的資源利用

33、率，對金融業踐行雙碳集約目標、實現成本精細化控制以及推進綠色節能的數據中心建設帶來較大挑戰。3.2.33.2.3 系統可靠性下降系統可靠性下降服務器本地盤的健康狀態關乎數據庫的穩定性。分布式數據庫大量使用本地盤，而本地盤因為硬盤固件異常、存儲介質異常、數據跳變或硬盤達到使用壽命等原因，可能引發數據庫響應遲緩、數據丟失，甚至數據庫“夯死”和業務中斷。然而，當前許多服務器缺乏專業的亞健康檢測、故障處理和自愈恢復等可靠性保障機制，進一步加劇此類故障的風險。3.2.43.2.4 系統高可用能力存在短板系統高可用能力存在短板采用本地盤部署的數據庫通常通過將集群分布于不同的機20房并利用邏輯日志復制的方式

34、來實現容災。然而，在實際應用中，網絡抖動/服務器異常等因素常導致同步復制降級為異步復制，進而引發數據庫集群主備兩端數據不一致的問題。因此，在實際操作中，很多金融機構選擇暫時關閉日志同步功能，目的是優先保證業務的順利運行，而后再重啟容災功能，雖然保證業務的即時需求，但暫時犧牲數據庫的高可用性。另外，在主從架構下，主備節點之間的主從切換可能會造成業務的短暫中斷或應用報錯，影響業務連續性。例如，某國有大行采用此種容災方案時，頻繁遭遇大事務堵塞、慢 SQL 執行或主備網絡異常等問題，導致主備數據庫數據不一致，最終只能通過業務回溯來進行數據補償。為應對這一挑戰，業界主流做法是通過引入專業存儲來實現存算分

35、離架構的創新，助力實現多讀多寫、多副本歸一、雙集群容災等關鍵技術突破，解決服務器以及硬盤的可靠性問題，如壞盤、慢盤和磨損等，同時提升資源利用率。針對這些瓶頸，我國數據庫廠商已經開始對數據庫架構進行優化。例如，OceanBase 通過存算分離部署，可滿足金融級高可靠要求，在存儲節點接口卡、控制器故障及存儲 IO 路徑阻塞等場景下，數據庫切換時間可達到秒級（RTO8s）。具體而言，數據庫層的集群內主節點故障時，從節點能自動升級為主節點，主從切換時間為秒級。在鏈路層通過 NoF 組網實現存儲與服務器間故障場景的秒級切換。在存儲層采用全互聯 A-A 架構，LUN 無歸屬，控制器之間實現負載均衡，故障倒

36、換時間極短。在軟硬件結合，服務器、存儲和 NoF 網絡的全面加持下，數據庫性能大幅提升。21圖 13“OceanBase+專業存儲”存算分離方案架構圖華為 GaussDB 存算分離雙集群方案能夠實現數據庫高可靠容災，確保 RPO=0。圖 14“GaussDB+專業存儲”存算分離雙集群方案架構圖223.33.3 云原生數據庫存算分離技術云原生數據庫存算分離技術云原生數據庫的快速發展與其獨特的架構優勢密不可分，主要體現在以下幾個方面：一是高效利用硬件資源，通過資源池化來提供大容量、資源利用率高且具有高性價比的服務；二是具備極致彈性，支持計算和存儲等組件的獨立擴展，實現無服務化；三是具備出色的數據庫

37、容災能力，確保數據庫的高可用性。圖 15 云原生數據庫存算分離架構圖云原生數據庫的設計理念是構建一種更契合“資源彈性管理”理念的數據庫架構，充分利用云平臺的資源池化特性，適應云平臺基礎設施，實現資源規格的靈活控制、應用的多模、更優的彈性擴展能力以及有效的成本控制。云原生數據庫適用于多種應用場景，包括滿足高彈性流量需求、保障數據庫高可用、實現高時效性、應對混合負載挑戰以及滿足彈性化、智能化的成本管理需求等。其中，計算和存儲分離架構是核心，而存儲能力的建設是關鍵。233.3.13.3.1 多級高可用，提供異地災備能力多級高可用，提供異地災備能力具備多級高可用能力是云原生的核心要求，這對于抵御不同級

38、別的異常情況、保障客戶業務的平穩運行至關重要。云原生數據庫通過提供全球數據庫網絡服務、支持單個實例跨可用區部署、多副本、跨可用區和跨地域的多可用區熱活高可用等技術，實現數據庫容災。這些技術保障了即使在主集群或任何可用區發生地域級別故障的情況下，存儲一致性也不會被破壞。存儲作為云原生數據庫底座，其可用性和可靠性直接影響系統整體。下圖展示了 PolarDB 采用計算與存儲分離的設計理念，滿足公共云計算環境下根據業務發展彈性擴展集群的需求。在PolarDB 中，數據庫的計算節點僅存儲元數據，而數據文件、RedoLog 等則存儲于遠端的存儲節點。各計算節點之間僅需同步 RedoLog 相關的元數據信息

39、，顯著降低主節點和只讀節點間的復制延遲。在主節點故障時，只讀節點可以快速切換為主節點。24圖 16 PolarDB 存算分離方案架構圖3.3.23.3.2 多級多級 HTAPHTAP 釋放潛能釋放潛能整合存儲資源池、內存資源池技術與 HTAP 是云原生數據庫領域的一大發展趨勢，融合了 OLTP 和 OLAP 能力的技術，結合了存儲池化和內存池化等軟硬協同優化手段，可以顯著降低網絡吞吐量，提高數據庫的性能和響應速度。下圖展示了 GaussDB 通過存算分離部署來實現 HTAP 能力。25圖 17 GaussDB HTAP 存算分離架構圖將存儲池化和內存池化技術與 HTAP 相結合，可以為 HTA

40、P 提供更為穩定和高效的支持，主要體現在以下幾個方面。一是以存強數，進一步提升數據庫性能：使用專為數據庫優化的存儲結構，不僅可以消除傳統存儲陣列的瓶頸，還能用于卸載數據庫處理工作；存儲服務器中的 CPU 可用于加速數據庫密集型負載；通過將算子下推至存儲，使存儲參與 SQL 運算，提升數據庫整體性能。二是減少網絡通信開銷：通過內存池技術，可以將數據緩存在本地內存中，減少對遠程存儲的訪問和網絡通信開銷，提高系統整體性能和響應速度。三是提高數據一致性和可靠性：存儲池疊加內存池技術可以保證數據的一致性和可靠性，避免因網絡延遲或數據同步不及時導致的數據不一致問題。四是實現資源共享和動態擴展：通過存儲池化

41、和內存池技術，可以實現資源的共享和動態擴展，使系統可以根據實際需求靈活26擴展和收縮，提高系統的可擴展性和可用性。騰訊 TDSQL-C 通過實施計算存儲分離，構建共享存儲架構，實現云原生資源的解耦和池化，進而提供資源獨立彈性擴展能力。圖 18 騰訊 TDSQL-C 存算分離架構圖3.3.33.3.3 智能彈性助力降本增效智能彈性助力降本增效隨著云計算技術的不斷發展，Serverless 已成為云原生數據庫的重要發展趨勢。然而，僅提供無服務器計算無法滿足所有用戶的多樣化需求。因此，Serverless 數據庫需具備智能彈性能力。智能彈性指數據庫能夠基于歷史負載數據，自動構建用戶畫像，快速預測未來

42、的負載曲線，并預先準備相應資源以實現彈性伸縮。使得數據庫能迅速響應需求變化，防止負載觸及資源上限，減少資源浪費。智能彈性是 Serverless 數據庫未來的關鍵能力之一，有助于數據庫在處理大量數據時保持高效性能，確保27系統的穩定性，降低運營成本，提高資源利用率，提升用戶體驗。3.3.43.3.4 AIAI 助力構建智能化數據庫助力構建智能化數據庫未來的云原生數據庫將深度融合 AI 技術，通過 AI 助力云原生數據庫提效，以及云原生數據庫與向量能力的結合，朝著全場景智能數據庫的方向邁進，為各種應用場景提供更加智能、高效和安全的數據管理服務。在這一背景下，AI 存儲和具備高可用、高性能的專業存

43、儲將發揮重要作用，有效實現數據庫的智能化洞察、評估和優化，確保數據庫服務的安全、穩定及高效。這意味著數據庫將能夠自動檢測和診斷問題，進行自我調優和運維，同時保證數據的安全性和可靠性。3.3.53.3.5 云原生數據庫變得更加普惠云原生數據庫變得更加普惠云原生數據庫正處在快速發展階段，云服務提供商正致力于提升產品的性價比、性能和穩定性。金融機構在選擇云原生數據庫時，需要考慮遷移成本、技術可控性、對云廠商的依賴程度以及總體成本等因素。目前，大部分云原生數據庫仍然依賴于云服務提供商自身的技術底座與硬件環境。未來，云原生數據庫應朝著普惠化方向發展并具備以下特點：低門檻、開箱即用；提升遷移效率，支持跨平

44、臺、跨地域部署；與各類應用和工具良好兼容以及數據庫本身的高穩定性等。28在進行數據庫存算分離架構選型時，應當通過一系列評估指標來進行綜合比較，不同業務系統對指標要求的側重點有所不同，因此這些指標的選擇應根據具體的業務需求和使用場景來確定，以確保所選架構最符合實際應用要求。一般來說，金融行業普遍關心的技術指標有以下幾類：性能、可靠性、可用性、成本收益、能耗、擴展性、安全性和運維等。4.14.1 性能指標性能指標數據庫系統涉及金融行業大量的交易數據、客戶信息和風險管理信息。金融機構對數據庫性能指標有著極高要求，需要數據庫系統不僅能處理大量的數據請求和交易，還能快速響應查詢請求。關鍵的性能指標包括以

45、下幾個方面。4.1.14.1.1 數據庫性能數據庫性能數據庫響應時間：數據庫對請求的響應時間，包括讀取數據、寫入數據、查詢數據等操作的響應時間。數據庫實例性能不低于50 萬 tpmC10ms(90th)。（注：90th 表示 90%比例）。（1）數據庫吞吐量：數據庫在一定時間內處理的數據量，包括讀取數據、寫入數據、查詢數據等操作的吞吐量。（2）數據庫并發數：指同時訪問數據庫的用戶數量。294.1.24.1.2 網絡性能網絡性能（1）網絡帶寬：網絡設備的傳輸帶寬，包括數據庫到計算節點的網絡帶寬。（2）網絡延遲：網絡設備的傳輸延遲，包括數據庫到計算節點的網絡延遲。4.1.34.1.3 存儲性能存儲

46、性能（1）存儲響應時間：存儲設備對請求的響應時間，包括讀取數據、寫入數據等操作的響應時間。存儲可支撐部署多套數據庫實例，提供穩定時延小于 0.1ms 的存儲性能。（2）存儲吞吐量：存儲設備在一定時間內處理的數據量，包括讀取數據、寫入數據等操作的吞吐量。全讀場景，提供不低于 20GB/s 的存儲性能。（3）存儲并發數：同時訪問存儲設備的用戶數量。4.24.2 可靠性指標可靠性指標數據庫可靠性是金融業系統穩定運行的關鍵。除了要保證傳統數據事務的正確性和可靠性，還需要關注整系統的可靠性。數據庫業務連續性和業務體驗要求數據庫系統在遇到各種異常和錯誤情況時，能夠維護數據的一致性和完整性。數據庫可靠性能力

47、是指數據庫系統在面對異常和錯誤時，確保數據的一致性和完整性的能力，目標是實現 99.9999%的數據可靠性標準。304.2.14.2.1 數據可靠性數據可靠性（1）數據正確性：數據庫記錄的信息始終保持與描述對象一致，在多個實例間不會出現數據沖突或矛盾。（2）數據一致性：在多個副本和不同節點之間，數據保持一致的程度。（3）數據完整性：數據在存儲、處理和傳輸過程中保持其正確性和一致性。（4）數據持久性：存儲設備故障或其他異常情況下，避免出現數據丟失，數據保持不變且可恢復。4.2.24.2.2 系統可靠性系統可靠性（1）冗余設計：計算節點和存儲節點故障不會影響整系統運行。（2）自動故障切換：在計算極

48、端或存儲節點發生故障時，系統自動切換到備用節點，以保障數據庫服務的連續性。（3）網絡鏈路冗余：鏈路端到端故障秒級切換，存儲 IO 不歸零，數據庫業務不中斷。4.2.34.2.3 硬盤可靠性硬盤可靠性（1）SSD 盤壽命提升：具備 SSD 盤磨損均衡和全局反磨損均衡能力。（2）最大可容忍 3 盤同時故障，3 盤故障業務不歸零，性31能無明顯影響。避免一個 RAID 組內 3 塊 SSD 同時失效導致的數據丟失，提高系統整體硬盤的可靠性。（3）故障預防：硬盤故障提前識別，提前告警，提醒用戶進行更換。（4）故障檢測&容錯：提供硬盤在線診斷能力，檢測硬盤潛在故障，識別盤故障，主動啟動數據拷貝。避免慢盤

49、進行寫操作，盡量不讀慢盤。出現慢盤后，業務不歸零，性能無明顯影響。（5）盤故障修復：由于采用存算分離架構，單盤故障數據重構速度高于 5TB/h。4.34.3 可用性指標可用性指標數據庫是數據業務的核心基礎設施，因此必須保障其高可用能力。信息安全技術 信息系統災難恢復規范對信息系統的災難恢復目標進行了明確要求：“災難恢復目標是通過有效的技術與管理手段，確保組織在災難發生時迅速恢復信息系統運行，最大限度地降低損失和影響，保障數據的完整性和可用性，保障業務的連續性?！?。具體來說，數據庫高可用性是指在系統發生故障時，數據庫仍然能夠持續提供服務的能力。這對確保應用系統的穩定運行至關重要。同時，高可用能力

50、可以減少數據丟失和業務中斷的風險。為了實現數據庫高可用，需要采取一系列措施，如數據中心內集群高可用容錯、數據中心間集群冗余保護以及數據庫備份恢復等。這些方案旨在最大限度地減少系統停機時間，32保證業務連續性和數據可靠性。為了保證金融業信息系統的安全穩定運行，金融管理部門及相關行業協會在信息系統災難恢復標準制定方面制訂了多個管理規范和指引，以加強金融業信息安全保障體系建設，規范金融領域信息系統災難恢復工作。金融業監管機構對信息系統災難恢復標準的政策發展和變遷，經歷了從要求運行安全，到制定信息系統災難恢復預案制定、開展應急演練，再到建立完善的應急保障和業務連續管理體系的過程。4.3.14.3.1

51、容錯能力容錯能力（1）數據副本：支持多副本數據存儲，數據可在多個節點之間進行同步。（2）實時監控：系統運行狀態的實時監控能力，當系統出現異常時自動報警或通知。（3）故障切換：計算節點發生故障后，系統自動切換到備份節點并對外提供服務。實例集群內故障切換指標：本地同城高可用方案可實現 RPO=0，RTO120S。4.3.24.3.2 集群冗余集群冗余（1）同城雙集群：基于共享存儲的高可用方案，提供性能更高，可靠性更強的高可用方案。支持同城雙集群數據庫強同步，實現 RPO=0，RTO120S。33（2）兩地三中心：支持同城雙數據中心，多地容災，實例可以在多個地域間進行遷移。實例跨地域故障切換指標，兩

52、地三中心異地高可用方案實現 RPO1 分鐘，RTO10 分鐘。4.3.34.3.3 備份與恢復備份與恢復（1）備份效率：支持 LanFree 級備份，數據備份流量走存儲網絡，降低對主機的影響，備份速率可達 2GB/s。（2）恢復時間：數據恢復所需的時間。支持任意時間點恢復，百 TB 級數據庫分鐘級恢復。（3）數據丟失點：數據恢復時允許的數據丟失量。支持分鐘級最小保護周期，通過備份數據恢復數據庫實例允許丟失的數據量最小可達到 5 分鐘。信息安全技術信息系統災難恢復規范 將災難恢復能力等級劃分為六個等級。數據庫系統在災難恢復能力等級需要滿足第6 級要求，即實現數據零丟失和遠程集群支持。銀行業信息系

53、統災難恢復管理規范在此基礎上，規定了銀行業信息系統災難恢復應遵循的管理要求。具體要求如下。表 1 銀行業 RTO/RPO 與災難恢復能力等級的關系示例344.44.4 成本效益分析成本效益分析成本效益也是選型時重要的考量因素。金融業需要在數據庫的性能、安全性與成本之間尋找平衡點，選擇性價比最優的數據庫產品。衡量數據庫存算分離架構的成本效益時，需要綜合考慮性能、資源利用率和運營成本等多個方面，確保在滿足業務需求的同時實現有效的成本控制。4.4.14.4.1 成本效益指標成本效益指標（1）資源利用率：存算分離架構允許資源按需分配，避免資源浪費。重點關注計算節點、內存池和存儲池的利用率，以確保資源得

54、到最佳利用。（2）硬件成本：存算分離架構通過實現多個計算節點共享同一份存儲數據，有效降低了存儲成本?？梢酝ㄟ^比較存算分離架構與傳統存算耦合架構的硬件成本，評估節省的金額。（3）維護成本：存算分離架構中，各個組件的維護工作相互獨立，不再受制于相同的故障域。這雖然降低了維護成本，但也需要考慮跨節點通信的延遲對性能的影響。（4）擴展成本：增加計算或存儲資源的成本和復雜性。成本效益測算舉例說明：對比同城高可用容災的兩種方案：1）采用服務器本地盤架構，需要部署兩套 MySQL 集群，每套集群一主兩從，總共需要 6 臺服務器；2）采用存算分離共享存儲架構，2 臺服務器+1 套外置存儲即可實現。兩個方案的成

55、本效益35測算對比如下。表 2 成本效益計算參考存算一體方案存算分離方案設備數(臺)高度（臺/U）高度合計（U）設備數(臺)高度（臺/U）高度合計（U）計算12224428交換機212212存儲144硬盤框224合計2618空間節省-30.8%結果表明：在機房空間占用方面，存算分離方案明顯可以減少空間占用。4.4.24.4.2 存儲存儲空間空間利用率利用率存儲空間節?。罕镜乇P三副本和專業存儲 RAIDTP（允許三塊盤故障）冗余對比，以 100T 數據為例，約減少 1/2 裸容量。表 3 空間效益計算參考本地盤存儲（三副本）存算分離專業存儲計算300TB存儲149.3TB合計-50%4.54.5

56、 能耗指標能耗指標自雙碳目標提出以來，中共中央對金融業綠色低碳發展提出了明確要求。然而，采用存算一體多副本技術架構的數據庫會導致數據量急劇膨脹數倍，加之服務器盤無法共享，往往需要使用小容量盤，從而致使硬盤數量、服務器數量激增，能耗也隨之快36速上升。這不僅難以滿足金融業綠色低碳發展要求，還會導致運營成本上升。在數據庫存算分離架構中，通過資源池化、多副本歸一等技術，可以減少數據副本的數量，降低容量消耗，進而實現能耗的降低。能耗指標包括：（1）服務器能耗：服務器在運行數據庫存儲和計算任務時所消耗的能量。（2）網絡能耗：網絡傳輸數據時所消耗的能量，包括服務器之間的通信和客戶端與服務器之間的通信。（3

57、）存儲設備能耗：數據庫存儲設備在讀寫數據時所消耗的能量，包括硬盤、固態硬盤等。（4）計算設備能耗：數據庫計算設備在進行數據處理時所消耗的能量，包括 CPU、GPU 等。能耗節省測算舉例說明：基于同城高可用容災場景，對比存算一體和存算分離的兩個方案的能耗指標：1）采用服務器本地盤架構，需要部署兩套 MySQL 集群，每套集群一主兩從，總共需要 6 臺服務器；2）采用存算分離共享存儲架構，2 臺服務器+1套外置存儲即可實現。兩個方案的能耗節省測算對比如下。表 4 能耗節省計算參考典型功耗（W）存算一體方案存算分離方案計算80096003200交換機400800800存儲22952295合計1040

58、06295功耗節省-39%結果表明：服務器數量越多，空間節省越大。若服務器本地盤為兩套 MySQL 集群，功耗預計節省 39%。374.64.6 擴展性指標擴展性指標金融行業的數據量非常龐大，且還會持續增長。因此，選擇具有良好可擴展性的數據庫顯得尤為重要。在數據庫存算分離架構中，擴展性是指系統在增加負載或擴大規模時，能夠保持性能和功能的一致性與可靠性。4.6.14.6.1 計算節點擴展性計算節點擴展性（1）節點數量：系統能夠支持的計算節點數量。（2）線性擴展性：增加計算節點時，性能是否能夠線性提升。（3）負載均衡：計算節點之間的負載均衡能力，確保沒有節點過載或空閑。4.6.24.6.2 存儲擴

59、展性存儲擴展性（1）存儲容量：系統能夠支持的最大存儲容量，支持按需擴展數據庫存儲容量，數據庫業務無感知，新增容量不影響原有數據庫業務性能。（2）存儲節點擴展：系統的性能能夠隨著節點數量的增加而線性增長，當系統中新增節點時，系統的性能提升能夠線性擴展到新增節點的 90%以上。4.6.34.6.3 數據一致性與高可用性數據一致性與高可用性（1）數據一致性：系統在擴展過程中，維持數據一致性和38性能的能力。（2）故障恢復：存儲節點或計算節點故障時數據恢復能力。（3）數據副本：數據副本機制及其對性能和可靠性的影響。4.6.44.6.4 資源調度和管理資源調度和管理（1）資源調度策略：計算任務與存儲資源

60、的調度和分配策略可按需擴展。（2）自動擴展：系統是否支持自動擴展計算和存儲資源。（3）管理工具：提供監控和管理系統性能、故障和資源使用情況的工具和接口，可預測擴展策略，確保系統始終具有良好的擴展性。4.74.7 安全性要求安全性要求由于金融業的信息系統關乎國計民生，因此對數據庫系統的安全性要求極高。人民銀行發布的中國人民銀行業務領域數據安全管理辦法（征求意見稿）明確要求：“除因業務影響、產業制約，并可提供詳細分析報告情形外，應當優先采用商用密碼技術對信息系統中第三層級以上數據項實施加密存儲，結構化數據項在對數據庫文件整體實施加密基礎上鼓勵進一步采用更細粒度的加密方式，非結構化數據項可僅對拆分的

61、第三層級以上結構化數據項單獨實施加密”。原有通過應用改造進行加密的方案將對業務產生較大的性能影響，使用存算分離架構，通過外置存儲的加密方案既能保證數據的有效加密又能降低對應用的性能39影響。存算分離架構將計算和存儲分離，而獨立的存儲資源管理有助于更好地保護數據的安全性。同時，數據持久化存儲的勒索防護和數據訪問控制有助于減少數據泄露和攻擊的風險。（1）數據加密：對于敏感數據，需要進行加密存儲，確保數據在傳輸和存儲過程中的安全。提供硬盤級加密，性能影響小于 5%。提供存儲陣列級加密，性能影響小于 20%。（2）數據防篡改：在數據庫的數據存儲區域，防止攻擊者對數據產生的數據文件和日志文件進行修改。（

62、3）偵測分析：檢測 I/O 行為是否異常，如發現異常，能及時感知數據被勒索病毒加密，立即進行主動防御，防止攻擊進一步擴散。100%業務負載時，偵測分析對性能影響下降小于 30%。（4）訪問控制：具備完善的訪問控制策略，限制用戶的訪問權限，確保只有授權用戶能夠訪問數據。（5）身份驗證：提供身份驗證機制，確保用戶的身份合法，防止惡意攻擊和數據泄露。（6）安全審計：需要建立安全審計機制，記錄數據訪問和操作的日志，確保數據的安全性和完整性。（7）網絡安全：基于零信任安全模型，建立網絡安全機制，防止網絡攻擊和數據泄露。（8）硬件安全：需要保證硬件設備的安全性，防止硬件故障和數據丟失。4.84.8 運維指

63、標運維指標隨著金融數據中心信息系統規模逐漸壯大，金融數據中心逐40步從最初的單數據中心延伸擴展到多地多中心運營的模式，運維工作的復雜性和繁重程度也日益增加。傳統的局部、粗放、碎片化的 IT 運維管理模式難以滿足新形勢下業務連續性保障的實際需求。在金融業數據庫架構選型過程中，考慮運維方面的相關指標非常重要。具備良好運維能力的數據庫系統可以有效減輕運維部門的工作量，降低運維復雜度，為金融業的數據庫系統平穩運行提供保障。（1）獨立擴展：存算分離允許獨立擴展存儲和計算資源，運維團隊可以根據需求，動態調整資源，避免資源浪費。（2）故障隔離：計算和存儲的分離意味著單個組件的故障不會直接影響到整體系統，便于

64、故障排查和恢復，提高系統的穩定性。（3）靈活性：運維人員可以根據不同的工作負載優化存儲和計算配置，進行精細化管理，提高資源利用率。（4）簡化維護：分離架構使得系統維護和升級更為簡單，運維團隊可以在不影響整體系統的情況下，對某一部分進行維護。（5）易于實施容災：存算分離架構更容易實現多活部署和災備方案，提升數據安全性和業務連續性。（6）集中管理：集中管理存儲資源，提高數據管理效率，簡化數據備份、恢復和遷移操作?；谶@些優勢，存算分離架構能夠在復雜的運維環境中提供更高的靈活性和可靠性。414.94.9 演進能力演進能力金融等行業在商業數據庫應用方面已積累了數十年的經驗，對商業數據庫提供的穩定性能有

65、著深厚的依賴。更換數據庫產品通常涉及復雜的應用改造和業務切割，這可能帶來業務風險。在當前復雜多變的國際局勢下，不確定性因素激增，數據庫架構選型需要考慮長期演進能力，以規避潛在的斷供風險。（1）全棧軟硬件自主可控：實現軟硬協同，數據庫與存儲深度適配，支持方案長期演進。（2）行業部署能力：適應和滿足不同業務場景和行業需求，技術架構在諸多行業得到驗證。（3）生態兼容性：能夠與多種技術棧、工具、平臺和服務進行無縫集成和互操作。4.104.10 總結總結在金融業的業務系統中，數據庫承擔著關鍵的角色，涉及大量的數據存儲和處理任務，同時需要保證數據的安全性和可靠性。因此，在評估存算分離架構和存算一體架構時，

66、需要從多個維度進行深入對比，以全面理解兩種架構的特性。表 5 數據庫存算分離架構 vs.傳統架構選型指標對比選型指標選型指標存算分離架構存算分離架構存算一體架構存算一體架構性能高性能，存儲和計算資源獨立優化。由于計算和存儲可以獨立擴展，性能瓶頸可以更容易地被緩解。性能有限，受制于單一節點的能力。計算和存儲資源緊密耦合，在某些情況下可能會出現資源爭用問題。42可靠性存儲和計算分離，提高系統的故障恢復能力。通過獨立的存儲節點，數據可以更可靠地存儲，且存儲和計算節點的故障不會相互影響。故障恢復較慢，單一節點故障影響大。雖然整體架構較簡單，但計算和存儲在同一節點上，某一節點的故障可能會影響更多服務?？?/p>

67、用性高可用性，通過冗余和分布式架構提高系統可用性，計算和存儲節點的獨立性使得故障隔離更容易。由于耦合度高，節點故障的影響范圍較大，可用性受限，單一節點的故障可能導致系統不可用。成本效益初期投資較大，但長期運營成本較低，更靈活，可節省資源。初期投資較低，但擴展和升級時成本可能較高。能耗初期能耗較高，但長期運行能耗較低，由于資源利用率高和優化的資源分配。初期能耗較低，但長期能耗較高，因為資源利用率較低，容易產生閑置。擴展性高擴展性，計算和存儲資源可以獨立擴展。擴展存在一定限制，需要同時擴展計算和存儲資源。安全性更強的安全性控制，可以分離安全域，獨立控制存儲和計算的安全策略，安全策略可以更細粒度地實

68、施。整體安全策略較易實施，安全性較低，單一節點的安全漏洞影響整個系統。運維按需動態調整資源，簡化維護，集中管理，便于實施容災方案。管理復雜度高，故障處理成本高，容災方案實施難度高。演進能力適應快速技術變化，獨立升級計算和存儲模塊。演進能力有限，升級需要更換整個節點?？偟膩碚f，存算一體架構在業務發展初期，適合中小規模業務，可滿足快速上線。但在業務大規模上線后，存算分離架構在性能、可靠性、可用性、成本收益、能耗、擴展性、安全性和運維能力等指標上具有比較明顯的優勢。因此，金融業需要根據具體的業務發展階段、應用規模和運行環境進行權衡和選擇，以確保選用的數據庫架構能夠最佳地滿足金融業的需要，實現可持續穩

69、健發展。實施存算分離架構要充分考慮業務的持續平滑演進，并著眼43于高可靠、高性能、綠色節能等長遠目標。對于具備條件的場景，優先采用共享存儲的技術，避免數據遷移和二次改造。根據當前數據庫能力，演進方案可分為兩種，分別適用于不同的業務目標。5.15.1 外置存儲的存算分離架構外置存儲的存算分離架構通過外置存儲和計算資源的分離部署，結合存儲的高可靠特性能力，提升整體業務的可靠性。分離數據庫進程和數據庫數據，將數據庫進程部署在我國服務器中，數據庫數據則通過外置高可靠高性能存儲，結合高速NoF+網絡，構建統一的數據庫存儲資源池。支持多種類型的數據庫接入。同時，利用基于 RoCE 技術的高性能網絡，提升數

70、據傳輸能力，實現數據庫 IOPS 性能提升，IO 時延下降。適用場景：適用于當前采用存算一體架構的數據庫，通過此方案可以實現可靠性增強，并靈活進行算力和存儲的獨立擴容。44圖 19 外置存儲的存算分離架構具體實施步驟：一是通過存算解耦實現資源池化，根據業務實際需求配置資源；計算層支持多節點橫向擴展，按需采用裸金屬或虛擬化部署，最大限度提升資源利用效率；二是采用容器化、虛擬化技術實現計算節點的資源隔離。通過企業級存儲，保障數據中心內及數據中心間的數據一致性和完整性；三是采用標準SAN 協議對接企業級集中式存儲，將數據高可用保障下沉到存儲層，計算與存儲之間通過高速網絡互連以保障高性能。四是架構支持

71、主流數據庫類型，以及 ARM、X86 等多計算平臺。5.25.2 存算協同的存算分離架構存算協同的存算分離架構在采用外置存儲方案基礎上，通過數據庫和外置存儲能力更加緊密地結合，軟硬協同，以提升容災能力、運維能力、成本優45化以及性能。場景 1：客戶關鍵類業務系統，兩地三中心部署，要求同城RPO=0，同城雙集群部署，故障隔離，可以采用數據庫和存儲協同，實現數據庫日志通過存儲復制跨中心強同步，實現數據零丟失。場景 2：現網的大庫集群，容量在 10 至 60TB 左右，采用數據庫層備份，全備窗口超過 12 至 24 小時，無法滿足客戶備份窗口要求?？蛻粝Ｍ捎?Lan-Free 方式備份，提升備份效

72、率。通過數據庫和存儲協同，數據庫提供快照備份接口，做備份時間戳和數據庫事務標記，存儲通過快照讀取備份數據，備份性能可達2GB/s，10 倍提升備份效率。場景 3：客戶批量改造現網數據庫，若采用 share nothing數據庫，存儲容量成倍增長，節點和容量壓力大，希望集群支持副本歸一，降低整網建設成本。通過數據庫和存儲協同，數據庫實現集群內多節點共享存儲，存儲實現數據本身的高可靠高性能。場景 4：數據庫全棧改造升級，需要在滿足當前業務性能基礎上，也要支持未來 3 至 5 年的業務增長。通過數據庫和存儲、計算、網絡的全棧協同，實現計算、存儲池化，數據庫實現多讀多寫架構，達成極致性能和可擴展性。4

73、6圖 20 存算協同的存算分離架構6.16.1 工商銀行數據庫存算分離架構實踐工商銀行數據庫存算分離架構實踐6.1.16.1.1 發展現狀發展現狀工商銀行金融產品數量多，服務客戶體量大，對應系統數量龐大和體系復雜，服務連續性要求高，且廣泛應用與數據庫產品耦合度較高的存儲過程等高級特性，歷史資產重。涉及總行應用接近 200 個涵蓋核心業務、渠道、前置、外聯、管理與支撐等多類業務系統，其中高等級應用超過 90 個。6.1.26.1.2 面臨挑戰面臨挑戰傳統數據庫有其極強的功能黏性、優秀的系統穩定性、良好的軟硬適配能力和對金融業務的良好支撐，且金融業存量系統往往與數據庫特性高度耦合，大量業務邏輯內嵌

74、到數據庫實現，且47具有歷史比較久遠、業務長期穩定、關聯應用較多等特點，在數據庫轉型過程中面臨諸多挑戰。（1）服務連續性能力要求高金融核心應用 7*24 小時對外服務不中斷，傳統數據庫及國際主流的通用基礎應用產品，具備優秀的系統穩定性和可靠性，能支持高性能、大容量業務的長期穩定運行。而自主創新軟硬件產品尚處于快速迭代、加速成熟的過程中，在保證金融業務服務連續性方面，對我國數據庫的數據可靠性高、系統可用性、集群性能及服務連續性能力提出更高要求，需要保證數據庫轉型過程中的生產安全和遷移后長期穩定可靠運行。（2）高級特性和存儲過程重度使用傳統數據庫轉型替代難度較大，尚無成熟的原位替代解決方案，金融機

75、構多采取對應用系統進行分布式改造，并對業務實現邏輯進行重構的方式實現轉型。工商銀行合計使用超過 40 類傳統集中式數據庫對象、24 類基礎數據類型、200 個系統內置函數、70 個系統高級包和 200 個系統視圖，且廣泛適用自定義類型、自定義函數、遞歸、嵌套、多表關聯、自連接等眾多高級語法特性，存儲過程代碼總行數達到億級規模，數據庫對象總數量超千萬。數據庫轉型過程中，面臨技術復雜度高、工作量大、項目周期長、實施風險高等挑戰。（3）業務邏輯復雜金融業存量業務系統具有歷史比較久遠的特點，經過長期演48進，業務邏輯復雜，且與其他業務系統的關聯關系復雜，交易調用鏈路相互交織。業務系統數據庫轉型往往伴隨

76、著存量技術資產、業務資產、關聯關系梳理，涉及數據庫對象遷移改造、應用代碼改造、新舊系統雙軌并行并疊加業務系統之間交易鏈路對接等工作，甚至涉及應用架構和業務邏輯重構等工作，技術復雜度高。涉及海量數據庫對象數量、存儲過程代碼行數、應用程序代碼行數和廣泛使用高級語法特性，要保證遷移后系統功能對等、性能滿足要求，應用遷移改造工作量大。自主創新軟硬件產品的性能、穩定性、成熟度等方面與傳統商用軟硬件產品相比還存在一定的差距，確保轉型的平滑、穩定、安全，成為數據庫架構轉型中的難點，需做好業務雙軌并行、灰度分批切流和應急回切等措施來規避。6.1.36.1.3 轉型實踐轉型實踐（1 1）突破數據庫關鍵技術）突破

77、數據庫關鍵技術1.構建分布式數據庫精簡模式部署形態，實現穩定性性能規格突破工商銀行對標主機 DB2 和 0racle 數據庫，按照“分布式架構+集中式體驗”的理念，基于全棧自主創新軟硬件產品，實現分布式數據庫的技術突破。一是軟硬件協同，提升性能。通過多核并行、基于代價的分布式并發事務并發優化和全鏈路并行編譯執行等，實現了分布式49查詢技術優化，良好地兼顧了金融業務系統高并發聯機業務場景和復雜計算批量場景的需求，具備百萬級 QPS 能力。二是采用存算分離架構打破單庫容量瓶頸，實現彈性擴容。通過計算存儲分離、存儲資源池化、在線彈性擴展等，具備 PB 級海量存儲能力，良好地支撐了歷史明細類、報表等金

78、融業務專題的海量數據處理需求。三是構建精簡模式支持集中式數據庫原位替換。構建精簡模式（分布式數據庫的集中部署），優化集中式部署性能可靠性，滿足業務對部署形態的不同需求，支撐大量存量業務原位替換需求，同時相同產品多部署形態實現開發、運維能力的統一構建。2.提升容災能力構建多級容災體系為確保應用轉型能力服務能力、安全穩定性能力持平，容災能力有提升，工商銀行對標原主機 AB 站點雙活方案，基于存算分離架構與廠商進行大型業務系統 0racle 數據庫轉型的多集群方案技術攻關，首創建成多集群多中心部署的高可用架構，滿足金融業務系統服務連續性要求。一是同城雙園區間通過存儲級復制實現增量數據強一致同步，異地

79、園區間通過異步方式實現增量日志同步，具備本地RPO=0&RTO30 秒、同城 RPO=0&RTO180 秒和異地 RPO1 分鐘&RTO10 分鐘的金融級高可用通力。二是實現雙集群故障和運維隔離、支持灰度發布?；谕请p園區雙集群部署架構，實現雙集群間跨數據庫版本的相互兼容50和增量數據的強一致同步,具備業務不中斷情況下數據庫版本灰度升級通力，在數據庫版本升級異常情況下,具備RPO=0&RTO180秒的回切能力。同城雙集群署架構示意如圖所示。圖 21 同城雙集群署架構示意圖目前工商銀行綜合應用存儲級日志復制、數據庫流復制等多種技術，形成多地多中心多集群容災方案體系，滿足不同等級金融業務系統的容

80、災需求。分級容災方案示意如圖所示。51圖 22 分級容災方案示意圖（2 2）構建原位替代模式降低存量遷移難度構建原位替代模式降低存量遷移難度針對存量業務累積構建大量業務邏輯內嵌到數據庫內分布式改造難、存儲過程遷移難等問題，工商銀行采用穩態業務原位替換模式有效降低技術復雜度和轉型工作量。1.穩態業務原位替換，平滑遷移對有存量存儲過程的業務，優先采用精簡模式，以集中式部署形態進行平移替換，對于當前部分國產數據庫并發性能無法滿52足的巨石類業務，優先考慮進行數據庫拆分，保留存儲過程，從架構層面避免或減輕了遷移改造的諸多挑戰。降低改造難度，減少工作量：避免了大量存儲過程、復雜SQL 改造，減少應用控制

81、分布式事務等方面的負擔，同時由于是架構平替，降低了存量業務工具化遷移難度，進一步減少工作量，使有限的精力可更聚焦于業務。降低應用遷移風險：降低了歷史大量累積的業務邏輯在遷移時出現問題的風險。在業務邏輯保持不變的情況下，可以通過自動化測試工具、流量回放工具減輕測試工作量，更好保障遷移質量。2.敏態業務分布式改造對業務增長迅速，可通過分片較理想實現并發、容量提升，且無存量存儲過程、復雜查詢的業務，可進行分布式改造，采用分布式數據庫替換。（3 3）實現平滑遷移實現平滑遷移為解決遷移轉換工作量大，測試覆蓋難等問題，工商銀行聯合頭部科技企業開展 Oracle 數據庫平滑遷移技術攻關，通過多試多用，不斷總

82、結經驗，研發全流程自動化遷移、自動化測試、自動化仿真驗證、灰度切流工具，配套建設完備的技術資產社區和全流程標準化轉型工藝，實現了復雜數據庫特性和巨量存儲過程的自動化遷移能力，人工改造成本壓降 90%以上，有效解放了生產力，讓科技力量更加聚集于金融業務創新和數字化轉型領域。53自動化遷移：實現數據庫表、索引、存儲過程、序列、視圖、觸發器、自定義類型等數據庫對象和高級包函數、自治事務、遞歸調用、自連接等復雜特性的自動化遷移能力，以及全量和增量數據的自動化同步，自動化遷移成功率達 95%以上，人工改造成本壓降 90%以上，突破了數據庫轉型的技術瓶頸和實施障礙。自動化測試：研發覆蓋單元測試、功能測試、

83、性能測試、生產驗證和測試管理過程的自動化測試工具鏈，降低測試人力投入和測試復雜度，提升測試效率，程序測試覆蓋率達 100%，分支覆蓋率達 95%，保障數據庫架構轉型過程平穩可控。自動化仿真驗證：構建交易錄放工具，通過一致性流量回放和性能回放，仿真階段實現業務功能全覆蓋測試和接近實際生產業務壓力的性能、可用性及可靠性測試?；叶惹辛鳎航ㄔO異構數據庫數據復制工具，實現異構數據庫間存量數據和增量數據雙向復制。在雙軌運行階段，通過業務增量歸檔數據在異構數據庫間的雙向復制，實現新舊系統業務數據的準實時一致，確保故降場景下能及時回切，提升對外服務的連續性。數據同步效率可達 15OGB/小時。6.1.46.1

84、.4 轉型效果轉型效果經過大量實踐，工商銀行形成了一套無需整體重構 Oracle存儲過程邏輯，低成本、高效可控的原位替換轉型技術方案、配套工具和轉型方法論，構建全金融業務場景支撐能力，廣泛用于54包括個人網銀、信貸系統、貴金屬等 130 多個業務系統，覆蓋辦公系統、一般業務系統和關鍵業務系統各類業務專題。采用精簡模式、存算分離等架構設計簡化復雜問題，通過數據庫與國產眾核處理器、企業存儲協同構建的高性能、高可用、高安全、彈性伸縮、雙集群容災能力以及自動化數據遷移、同步工具能力數據庫產品商業版本中落地，具備快速推廣的能力。6.26.2 農業銀行新一代存算分離數據庫實踐農業銀行新一代存算分離數據庫實

85、踐6.2.16.2.1 發展背景發展背景在金融數字化轉型浪潮中，銀行業務對信息系統的各項處理能力都有較高要求。這些系統不僅承載著農業銀行的核心業務，如賬務處理、支付結算和信貸管理等，也確保了內部管理系統的高效運作。數據庫作為金融信息系統的“記憶中樞”，負責存儲和檢索海量金融數據，處于技術架構的核心，是連接前端應用和后端基礎資源的關鍵紐帶。數據庫按存算功能是否解耦可分為兩種，一種是計算和存儲耦合的存算一體數據庫，優點是計算在本節點讀寫數據，數據傳輸速度快，缺點是不易靈活擴容。另一種是計算和存儲解耦的存算分離數據庫，優點是能夠實現計算資源與存儲資源的獨立配置和擴展，缺點是存儲和計算之間大量數據的傳

86、遞對 IO 要求較高。此外，存算分離架構與云基礎設施技術結合，使得數據庫的管理與運維能夠充分利用云計算的優勢，實現資源的自動化動態彈性55伸縮和快速按需分配。6.2.26.2.2 實踐經驗實踐經驗基于存算分離數據庫的技術特點，農業銀行結合自身需求特點與實際情況，采用策略規劃、產品驗證、行內落地這一思路整體推進數據庫的應用落地，聚焦如下關鍵方面。一是制定分類的硬件資源配置策略。結合存算分離技術特點與行內的資源供給及基礎設施情況，針對不同使用場景制定不同的使用策略。部署方式上看，虛擬機云服務資源利用率較高，物理機裸金屬性能強大。存儲方式上看，分布式存儲部署靈活，企業級高端存儲的性能強大，產品穩定性

87、、高可用性更好。農業銀行對于不同災備等級的系統，設計了不同的架構。高等級系統更注重系統的業務連續性，選擇“物理機裸金屬+企業高端閃存”的組合架構。低等級系統在穩定運行的前提下更注重資源利用率，采用“云服務虛擬機+分布式存儲”的組合架構。二是完成產品的全面驗證。農業銀行基于數據庫的存算分離架構，進行了詳盡的功能與性能測試，旨在提前識別并迅速解決潛在的產品問題。與存算一體數據庫系統相比，本次測試的范圍更廣泛，內容更復雜，和傳統測試具有較大差異性。功能測試方面，除了驗證數據庫的傳統基本功能外，還結合云計算技術，增加了對資源動態管理能力的測試，以確保系統能夠靈活配置資源。對于高可用，考慮到計算和存儲的

88、解耦，增加了計算節點切換機56制、存儲部分可靠性與冗余性的測試。對于數據備份恢復，存儲分離技術帶來了更靈活和復雜的要求，為此增加了計算與存儲節點的數據一致性校驗。性能測試方面，不僅涵蓋常規的性能評估，考慮到計算和存儲之間的分離特性，引入存儲網絡性能測試，以檢驗在高并發、大數據量場景下的存算分離數據傳輸效率與穩定性。此外，還特別注重資源擴展與回收的性能測試，旨在驗證系統在面對動態資源需求變化時的響應速度與效率，確保業務連續性和用戶體驗。三是推動我國數據庫在行內的落地。進行產品驗證的同時，完成存算分離數據庫與我行內部運維管理體系的融合工作，確保實現運維無縫集成和高效協同。在提升產品穩定性方面，為預

89、防存儲設備的單點故障風險，引入存儲池化和日志卷雙寫等特性。為進一步提升產品易用性，引入集群單浮動 IP 和跨集群單浮動IP。在提升運維效能方面，農業銀行對標行業頂尖實踐，在完成基礎運維體系搭建的基礎上，積極探索并實施自動化運維策略與工具創新。按照腳本化、自動化、智能化三步走的策略，構建智慧運維體系，實現了運維流程的全鏈路監控與分析。在精細運維方面，農業銀行充分利用云計算的彈性擴展優勢，結合持續迭代的高階運維功能，對數據庫容量實施了標準化的動態管理，為業務的長期穩健發展提供了堅實的支撐。576.2.36.2.3 實踐成果實踐成果經過一年多的努力，農業銀行基于存算分離數據庫，完成涵蓋信貸管理、資金

90、轉賬、金融市場交易等多個關鍵領域各類不同災備級別系統的投產運行，覆蓋京、滬、蒙三地多中心。自投產以后系統運行穩定，各項關鍵性能指標與功能需求均滿足各類業務和技術要求，標志著農業銀行基于存算分離架構的數據庫使用方面取得了重大進展。展望未來，農業銀行規劃將存算分離數據庫技術的應用范疇進一步拓展至快捷支付、超級柜臺服務、電子銀行等關鍵業務領域，旨在為全行提供更加穩定、高效、智能的技術保障，驅動銀行業務實現更加穩健與快速的發展。6.36.3 平安銀行平安銀行 MySQLMySQL 數據庫存算分離架構探索數據庫存算分離架構探索平安銀行當前主流架構為存算一體，數據庫使用開源MYSQL，通過 vmware

91、虛擬化進行資源隔離，操作系統是 REDHAT，存儲使用的是本地盤，主備同步使用 MYSQL 數據復制技術，建設的標準是兩地三中心一主四備的架構。圖 23 兩地三中心一主四備的架構示意圖586.3.16.3.1 面臨痛點面臨痛點一資源使用率不均，由于虛擬化后單物理機上部署多臺虛擬機，但是每個虛擬機上運行的 MySQL 數據庫因業務而異，導致的計算資源與存儲資源分配和使用不均衡，整機的資源使用率經常會出現計算或者磁盤先到達瓶頸，而剩下的資源卻比較空閑的情況，導致整體的資源使用率難以提升。二是故障場景下 RPO 難以滿足，因為傳統的 MySQL 架構基于數據庫事務日志的傳輸和回放，在故障場景下的主從

92、切換，因為日志的同步存在網絡時延、大事務等客觀影響因素，而且在繁忙的數據庫體現尤為明顯，切換的 RTO/RPO 可能會到 1 分鐘到 15分鐘甚至更久，難以滿足金融業的需求。三是受制于國外商用軟硬件，雖然 MySQL 為開源數據庫產品，但是使用的 VMWARE 虛擬化技術、紅帽操作系統、服務器硬件都是國外商用軟硬件，在基礎架構層技術仍然受制于人。四是虛擬機 OS 過多，如果選擇我國 OS 會顯著增加成本。6.3.26.3.2 解決方案解決方案方案一：存算分離虛擬化方案一：存算分離虛擬化 MYSQLMYSQL這種架構是對當前 MySQL 架構的改進，但是需要從下而上解決之前的問題。一是設備采用

93、ARM/海光信創服務器；二是采用59我國虛擬化技術；三是不再使用本地盤、改用外接的我國存儲；四是采用開源或者我國操作系統。圖 24 升級改造路徑示意圖上圖是規劃的建設路徑，路徑上各個環境的方案已經測試驗證通過，存算解耦只能幫助解決計算資源和存儲資源不均衡的問題，但是無法解決數據一致性的問題。解決數據一致性問題，目前有兩個思路。一是通過數據庫層的強同步實現，MySQL 最多只能實現半同步復制，無法實現強同步復制，所以需要使用數據一致性保障能力更強的數據庫版本。二是通過存儲層的數據共享，實現主寫備讀的模式，來實現主庫故障情況下保障數據一致性，實現 RPO=0。以上兩種方案各有優缺點，還在進一步研究

94、和驗證過程中。針對資源使用率的問題，如何避免過高和過低，還在研究如何合理調度通過削峰填谷來實現資源有效利用，可能會建設一套智能化的資源管理系統。60方案二：容器化方案二：容器化 MYSQLMYSQLMYSQL 上容方案，可能是未來的部署方案，目前還只是在測試方案探索階段，有很多問題需要解決。設想通過容器化實現數據庫服務化，數據庫可按需進行資源動態的擴縮容管理，實現Serverless 能力。圖 25 容器化后架構示意圖上圖為容器化后 MYSQL 的架構方案，該方案使用外接共享存儲，在上容的同時使用存算分離架構，是一種更加徹底的存算分離。該架構下同 IDC 內不再建設有備庫，主庫故障后利用 K8

95、S 的調度和共享存儲能力，在原存儲上可以迅速拉起新節點實現故障轉移，而在同城跨 IDC 機房建設有另外一套獨立的 K8S 集群，通過數據庫復制技術進行跨 IDC 主從同步。該架構有以下優點：一是 RTO 和 RPO 的提升。存算分離后，在容器化部署中，當出現主機故障時可以在原有外接存儲上利用 K8S 的調度能力迅61速拉起一個新 POD 節點，由于使用同樣的存儲，相比傳統架構可以做到數據零丟失。而在同城雙活中，MYSQL 運行在另外一套的K8S集群和共享存儲，使用數據庫自身的主從復制進行數據同步。極端場景下，單 IDC 的機房、K8S 集群、主機、存儲故障，都可以做到切換到雙活的 MYSQL

96、進行對外提供服務。二是資源利用率提升。計算資源和存儲資源解耦，資源調度更具有彈性，提高資源利用的同時，可增加單臺物理機的部署密度，進一步提升資源利用率。同時由于利用了存儲和容器的能力，MYSQL 的從庫也較傳統的一主四從架構減少到一主兩從，進一步減少資源的消耗。而且在容器化部署中，對于資源的彈性伸縮調度，相比傳統架構會變得更為靈活。6.46.4 上海上海銀行數據庫存算分離架構的應用試點實踐銀行數據庫存算分離架構的應用試點實踐6.4.16.4.1 項目背景項目背景上海銀行在推進新建系統和存量系統改造過程中，基于本行應用的數據庫體量，確定如下選型策略：優先集中式數據庫，降低開發成本與運維復雜度；單

97、庫達到較大交易量和數據量，將分布式數據庫納入考慮。本次試點的跨應用數據檢核系統，業務層面進一步深化數據檢核體系，從原先單一應用、單一維度的數據檢核向多層次、多維度交叉領域拓展。實現相關金融基礎數據和行內經營管理信息平臺的數據交叉比對，提高數據的一體化程度和數據口徑的一致62性?？鐟脭祿z核系統主要是數據分析，屬于 OLAP 類系統，為此試點使用 TDSQL 數據庫（使用集中式實例模式）和集中式存儲陣列。6.4.26.4.2 架構設計架構設計（1）資源池及架構設計服務器/存儲數量說明共享說明管控服務器3主 IDC：3多套系統共用一套管控數據庫服務器2主 IDC：2集中式存儲陣列2不同節點需要不

98、同的集中式存儲可共享部署拓撲：部署拓撲：圖 26 部署架構示意圖架構說明：架構說明：數據節點：運行數據庫實例，實現主從復制。63管控系統：負責 TDSQL 集群的監控運維，包括高可用切換、備份、監控、告警等功能。（2）存算架構選擇通過實際性能測試比較，使用集中存儲陣列(OceanStorDorado 18500 V6)、全閃 SSD 硬盤（NVME 協議），相比本地 SSD硬盤，綜合性能有較明顯提升（包括 IOPS、帶寬和時延等指標），具體數據如下：圖 27 數據對比示意圖結合性能影響、容量擴展便利性、磁盤設備可靠性等因素，集中式數據庫決定使用集中式存儲。6.4.6.4.3 3 實現收益實現收

99、益（1）實現方式存力和算力剝離，各司其職。計算節點 DN 節點負責執行應用請求、生成執行計劃、數據文件讀取。使用外置存儲將數據進行妥善、安全的存儲，即應用產生的實際數據文件存放在全閃集中式存儲上。同時全鏈路采用輕量級 NVMe 協議連接計算節點和存儲，達到充分利用 SSD 的高速讀寫能力和低延遲特性。64（2）效果和收益在擴展性方面，存與算不受資源配比影響，擴展性得到提升，計算與存儲按需各自獨立擴展。采用集中式陣列可以提供更大的容量空間，在線使用容量擴展更為便捷。從主機到交換機網絡到存儲，采用端到端 NVMe 協議通信,支持更高的隊列深度和并行性，在提高存儲設備的性能同時也可實現應用多底層多盤

100、并發讀寫，在多線程情況下讀寫表現高于本地盤。在性能方面，大數據量 IO 密集型數據庫，使用集中式存儲相比本地盤，性能有明顯提升。在可靠性方面，通過使用可靠性更高的專用存儲設備提升數據庫可靠性，也降低主備切換的概率，提高可用性。在數據安全方面，單盤或多盤故障對上層不感知，數據重構不影響性能，降低 IO 的敏感度。6.56.5 微眾銀行微眾銀行 TDSQLTDSQL+OceanDiskOceanDisk 存算分離架構存算分離架構6.5.16.5.1 項目背景項目背景微眾銀行 TDSQL 數據庫前期采用存算一體架構，在線業務數據存放于數據庫服務器本地 SSD 盤，該架構存在以下幾個問題。（1）本地

101、SSD 磁盤空間有限，隨著數據規模增長，數據庫容量瓶頸較難解決；（2）受限于本地 SSD 盤容量和 IOPS 能力，單臺數據庫服務器部署的實例數較少，服務器 CPU 資源相對空閑，存在資源浪費；65（3）慢查詢等大 IO 操作易導致磁盤高負載，引起數據庫性能抖動；（4）本地 SSD 故障需進行數據庫服務器替換，對業務有一定影響，每年因磁盤故障發起的自動或人工切換可達 20 次以上。經過產品調研和 POC 測試，選用華為分布式存儲設備OceanDisk，存放 TDSQL 在線業務數據，實現 TDSQL 存算分離架構。該架構可提升 TDSQL 可靠性，提高資源利用率。6.5.26.5.2 總體方案

102、總體方案（1 1）部署架構）部署架構TDSQL 采用存算分離架構，計算層采用 X86 或 ARM 架構服務器，存儲層采用分布式存儲 OceanDisk，數據庫服務器通過高速RoCE 網絡協議直接訪問 OceanDisk。TDSQL 以資源池的形式交付，一個資源池包含多臺計算服務器和 3 臺 OceanDisk，這部分硬件資源均勻分布在 3 個不同的數據中心。生產集群的 TDSQL 實例采用一主兩備的三副本架構，主節點可讀寫，備節點只讀。主備間通過 binlog 做數據同步，由 TDSQL 內置強同步機制保證主備數據一致性。單臺服務器部署多個 TDSQL 實例。通過 cgroup 技術為每個實例

103、設置 CPU 資源限制。每個實例使用獨立的邏輯卷，借助OceanDisk 的 SmartQoS 特性，設置單個邏輯卷的 IOPS 和帶寬上限，從而保障關鍵實例獲得優先的 IOPS、帶寬和時延保障。66限制單臺 OceanDisk 部署的 TDSQL 實例數量（如 50 個），降低 OceanDisk 故障影響范圍。避免 OceanDisk 負載過高，保證實例獲得的 IOPS、吞吐量和 IO 時延在可接受范圍內。將數據庫主備節點均勻分布在不同的 OceanDisk 上，實現存儲負載均衡。為確保 OceanDisk 穩定可靠運行，需控制其負載在一定閾值下。OceanDisk 采用雙控制器架構，控制

104、器 CPU 性能是常見瓶頸，日常 CPU 利用率應控制在 50%以下。當其中一個控制器發生故障，另一個控制器可以接管其請求，保障業務穩定運行。（2 2）容量管理）容量管理1.磁盤容量規劃OceanDisk 基于全閃存 SSD 構建，共 36 塊盤（36*7.68T），配置 RAID 6。應基于歷史數據和未來增長預期，評估 TDSQL 容量需求。OceanDisk 整體空間使用率控制在 70%以下，預留空間應對突增的數據量以及磁盤故障導致的可用容量下降。TDSQL 單實例掛載的邏輯卷可在線擴容，擴容上限為 6T，需避免因單實例過大導致影響范圍大、恢復時間長等問題。2.IOPS 資源管理制定分層級

105、的 IOPS 資源分配策略。新上線的 TDSQL 實例初始階段設置一個較大的 IOPS 上限值，充分利用 OceanDisk 的性能優勢。穩定運行一段時間后，根據實例的歷史性能監控數據，分析其 IOPS 使用模式，并結合業務 SLA 要求，合理評估所需的IOPS 能力。通過 OceanDisk 的 SmartQoS 功能，為不同 TDSQL 實67例或數據庫配置 IOPS 限額，避免資源競爭，保障關鍵業務的性能需求。（3 3）運維管理）運維管理1.監控告警機制OceanDisk 內置監控告警系統，捕捉異常生成告警信息后，會上報到行內統一告警平臺。通過 Restful API 拉取 OceanD

106、isk 的 IOPS、吞吐量、延遲、容量使用率、I/O 錯誤率等關鍵指標信息寫入數據庫，與 TDSQL監控數據做聯合分析：設置指標告警閾值（如 CPU、IOPS、IO 時延等），超過閾值則判定為異常；捕捉 IO、CPU 等監控指標閾值趨勢變化，關聯導致占用資源消耗較大的 SQL；采集全量 SQL 語句，跟蹤 SQL 耗時變化趨勢，有助于提前發現隱患 SQL。2.自動化運維TDSQL 運維管理平臺覆蓋了 80%以上的日常運維操作，包括服務器資源管理、服務器故障替換、實例主備切換、擴縮容、節點重建、故障分析等。WEB 頁面操作通過設置多重檢查規則，高危操作重復確認等，有效降低運維操作風險，提升操作

107、效率。OceanDisk 內置 web 管理臺 DeviceManager，操作功能完善，包含了存儲空間管理、任務配置、故障管理、性能管理等。68通過開發系列工具，對接 TDSQL OSS 接口及 OceanDiskRestful API，將 TDSQL 和 OceanDisk 操作連接起來，如 TDSQL一鍵部署功能，可自動完成服務器和 OceanDisk 資源分配，部署全程無需干預。6.5.36.5.3 難點問題難點問題（1）評估 IO 時延對數據庫性能影響OceanDisk 提供高 IOPS 和吞吐量，滿足高并發業務對性能的需求。但對比本地 SSD 盤，OceanDisk 較高的訪問時延

108、會帶來性能影響，如 SQL 耗時增長、數據庫的主備復制性能下降。圖 28 時延對數據庫性能示意圖如圖所示，當 OceanDisk 接收的請求壓力變大，伴隨著控制器 CPU 負載的增高，訪問 OceanDisk 的 IO 時延也會升高，尤其體現在讀 IO 讀時延上。影響數據庫性能，SQL 執行耗時上漲，69具體漲幅因 SQL 而異。在請求并發保持不變的條件下，隨 IO 時延上升，數據庫 QPS 呈下降趨勢。業務應用系統使用 TDSQL 存算分離架構前，應針對各業務場景進行全面的壓力測試，分析 SQL 耗時是否在可接受范圍內，以及如何優化應用數據處理邏輯，從而減少 IOPS 消耗、緩解 IO 時延

109、增高對業務的影響。（2）容量管理與成本控制均衡資源使用率，提高資源利用率。1 個 TDSQL 資源組包含3 臺 OceanDisk 和多臺數據庫服務器。TDSQL 資源均衡包括如下3 個層面。多個資源組之間的負載均衡；單個資源組內，不同服務器間的負載均衡，不同 OceanDisk間的負載均衡；單臺服務器上 CPU、內存的均衡使用，單臺 OceanDisk 容量、IOPS、IO 時延的均衡。存量 TDSQL 實例資源平衡。單個 TDSQL 資源組內，收集該資源組各 TDSQL 實例的運行數據。通過分析歷史資源消耗數據，計算出各實例所需資源配置。依據這部分配置數據，在 TDSQL 資源組內進行合理

110、的 DB 節點遷移調度，使資源池內各硬件負載盡量均衡。同時應兼顧實例重要程度，保障關鍵實例的 IOPS 能力及IO 時延。70新實例部署資源分配。根據新實例所需的容量、業務 TPS 等數據，通過自研算法，兼顧業務系統風險隔離以及資源均衡，選擇合適 TDSQL 資源組下的 3 臺服務器進行實例部署。新實例設置較高的資源上限，待運行穩定后，再評估實例實際所需資源。根據業務重要性決定如何實施資源限制。（3）運維復雜度增加存算分離架構下，運維需要同時關注 TDSQL 和 OceanDisk，更多監控信息，包括運行狀態、性能指標和容量使用情況等。由于 TDSQL 的性能和故障問題可能與數據庫自身、Oce

111、anDisk 或網絡連接相關，問題排查更加復雜。6.5.46.5.4 應用成效應用成效（1）緩解容量瓶頸TDSQL 存算分離架構帶來更靈活的容量管理，單實例容量規格支持從 10G 到 6T，支持在線擴容。靈活容量管理也帶來了空間利用率的提升。（2）提升服務器資源利用率借助于 OceanDisk 邏輯卷管理功能，包括 I/O 流量控制、數據壓縮等。當前單數據庫服務器部署實例數增加，提升了數據庫服務器 CPU 和內存利用率。（3）解決運維痛點71服務器故障無需進行 DB 節點重建，將存放數據和日志的邏輯卷掛載到新的服務器上，可直接啟動新實例。緩解了因節點重建拷貝數據帶來的 IO、帶寬資源消耗，以及

112、重建時間較長帶來的高可用風險。（4）TDSQL 故障率下降OceanDisk 內置雙控制器高可用架構，以及 RAID 6 配置。最大允許 2 塊盤同時故障，大幅降低磁盤故障對數據庫穩定性的影響。（5）TDSQL 資源成本下降存算分離架構增加了存儲產品 OceanDisk，但大幅減少數據庫服務器數量及機架機位數量。在提升數據庫可靠性的同時，降低資源成本。6.66.6 人保壽險人保壽險數據庫數據庫存算分離架構轉型升級存算分離架構轉型升級6.6.16.6.1 項目背景項目背景隨著核心業務規模的不斷擴大，面臨著日益增長的數據處理需求與數據存儲挑戰。公司核心業務系統數據庫基礎設施架構主要基于傳統的小型機

113、+SAN 網絡+集中式存儲解決方案。然而現有傳統 IT 基礎設施逐漸顯露出其局限性，包括設備老舊、性能表現不足、擴展性差、設備以及運維成本高昂等問題。為了進一步提升業務處理能力，優化資源利用效率，降低運維復雜度，公司對數據庫的基礎設施開展全面升級改造工作。本72次改造的核心目標是將現有的小型機+SAN網絡+集中式存儲的傳統數據庫架構，調整為基于存算分離的架構。6.6.26.6.2 架構方案架構方案（1）總體架構本項目通過選用基于存算分離架構的平臺為 Oracle 數據庫構建高性能基礎設施環境，通過內部高帶寬、低時延 RDMA 網絡將計算和存儲資源集成互聯，實現數據的快速處理和存儲，從而實現多個

114、業務系統數據庫的整合部署，提供高效、穩定的數據庫服務。目前基于該架構已部署 2 套數據庫生產環境與 1 套災備環境，涉及計算節點達 12 臺，存儲節點 17 臺，其中單臺計算、存儲節點可以提供不少于 20GB/s 的吞吐。每一套環境根據容量需求使用 6 臺或 5 臺配置 NVMe SSD 盤的 x86 服務器部署SmartStor 商業存儲軟件構建多副本全閃存儲資源池，為計算層提供安全、穩定、高效的存儲服務能力。本次構建的平臺可以根據實際的計算、存儲資源需求動態調整存儲、計算資源。圖 29 整體建設拓撲示意圖73（2）功能特性本方案架構主要包括分布式存儲資源池、網絡資源池、計算資源池、智能監控

115、管理系統。各資源池提供能力概述如下：1.高性能存儲資源池通過構建分布式存儲資源池為計算層提供存儲服務能力，在架構層面具有靈活敏捷、精細化管理、資源隔離、高性能等特點；在數據保護層面通過多副本機制充分保障數據可靠性；在資源擴容層面支持在線橫向/縱向靈活擴容。這些特點使得分布式存儲資源池能夠為企業提供高效、穩定、可擴展的數據存儲解決方案，支持企業業務的快速發展和靈活變化。2.高性能計算存儲互聯網絡計算存儲之間采用 RDMA 互聯網絡，實現了內存到內存的直接數據傳輸，極大地降低了數據傳輸的延遲。該網絡支持高達100Gbps 的帶寬，具有極低的網絡延遲，這使得在分布式存儲環境中，數據可以在多個節點之間

116、快速傳輸，可以滿足各種復雜業務場景的需求并提高整個系統的性能。3.高性能計算資源池計算層將數據庫部署在物理服務器上，通過 RAC 機制實現數據庫高可用集群，充分保障數據庫運行性能和可靠性。4.智能監控管理平臺智能監控軟件 SmartMon 對數據庫、主機、存儲、網絡進行統一監控管理，包含數據庫全生命周期管理、數據庫性能監控、74數據庫資源配置、數據庫運維管理、數據庫自動化巡檢、數據庫補丁升級、資源池管理、用戶/權限管理、告警配置、操作審計、計算/存儲/網絡設備監控管理等一體化功能。6.6.36.6.3 運行效果運行效果根據生產系統運維數據顯示，銷售人員管理系統遷移至該存算分離架構后，數據庫的繁

117、忙度從 45%下降到 5%，CPU 使用率從70%下降到 10%以下；其他系統遷移完成后，該數據庫的繁忙度從 50%下降到 1%，CPU 使用率從 20%下降到 5%以下，單筆處理的響應時間從平均 70 余毫秒下降至平均 40 余毫秒。根據極限壓測數據顯示，在 2 臺計算節點，3 臺存儲節點的存算分離架構下，隨機讀 IOPS 可達 500W+，隨機寫 IOPS 可達480W+，順序讀/寫吞吐能力可達 40GB/s，壓測 TPMC 可以達到 150萬。隨著節點數的增加，其性能值接近于線性增長。6.6.46.6.4 工作價值工作價值采用基于 X86架構的存算分離架構在提升系統性能的同時、通過集中的

118、管理平臺簡化運維復雜度，在降低總體設備成本的同時（相對于集中式 SAN 存儲），為公司的數字化轉型和快速發展提供了強有力的支撐。通過此方案選型，實際效益如下。資源高效整合與利用資源高效整合與利用：通過存算分離方案，將計算資源、存儲資源和網絡資源解耦。分別對計算以及存儲資源按需擴容，實75現了資源的優化配置和高效利用。這種整合不僅減少物理設備的數量，還通過內置的負載均衡、在線自動擴展等技術，確保了資源按需分配，避免資源閑置或過度使用的情況，從而提高整體資源利用率。簡化運維復雜度簡化運維復雜度：傳統的小型機+SAN 網絡+集中式存儲架構涉及多個獨立的組件和系統，運維人員需要掌握多種技術和工具，增加

119、了運維的復雜性和難度。而存算分離方案通過集中、豐富的管理界面，簡化了系統的配置、監控、維護和升級過程，降低了對運維人員的技能要求，提高了運維效率，降低了人為導致的風險。提升系統性能與穩定性提升系統性能與穩定性：該存算分離架構采用優化的硬件設計，如高速緩存、專用網絡等，以及針對數據庫優化的軟件堆棧，能夠顯著提升系統的處理能力和響應速度。同時，內置的高可用性和容災機制，如自動故障轉移、數據冗余存儲等，確保了系統的高穩定性和可靠性，即使在面對硬件故障或災難性事件時，也能保證業務的連續運行。加速業務響應速度加速業務響應速度：通過提升系統性能和穩定性，存算分離數據庫能夠更快地處理大量的業務數據，加速業務

120、處理流程，提高客戶滿意度和忠誠度。此外，它還支持實時數據分析和決策支持，幫助企業快速響應市場變化，抓住商業機會。降低總體擁有成本降低總體擁有成本：存算分離的架構，通過集中的管理平臺，可以帶來運維成本降低、資源利用效率提升、業務收益增加等效76益，將顯著降低企業的總體擁有成本。通過減少物理設備的數量和能耗，存算分離還有助于企業實現綠色、低碳的運營目標。隨著金融業持續創新發展，存算一體數據庫架構逐漸暴露出靈活性和效率不足的問題。為此，越來越多的金融機構開始探索存算分離架構的應用實踐，以提高系統性能和可靠性。同時，數據庫企業也推出存算分離的數據庫產品。金融機構在進行數據庫架構選型時，需綜合考慮業務需求、數據量、查詢復雜性、實時性、安全性和成本等因素，以選擇適合自身的數據庫產品。新技術和架構的涌現顯著提升數據庫性能和可用性，計算、內存和存儲的解耦增強系統可維護性和可擴展性，資源池化和彈性伸縮實現動態資源調整，提高利用率并降低成本。此外，獨立故障域的設計提升系統可用性和容錯性，減少單點故障的影響?？傊?，當前數據庫架構的發展趨勢在于充分利用新硬件技術和高速互聯網絡，實現計算、內存和存儲的解耦，從而提高系統的可用性、性能、擴展能力和資源利用效率。未來，存儲和數據庫技術將更加緊密地結合，對我國數據庫的發展產生深遠影響。1