1.4　數據庫架構轉型

數據庫的工作負載可分為事務型（On-Line Transaction Processing，OLTP）、分析型（On-Line Analysis Processing，OLAP）和混合負載（Hybrid Transactional/Analytical Processing，HTAP）。事務型數據庫一般用于聯機交易，關鍵是響應速度要快；分析型數據庫大多被用于數據倉庫或者決策支持系統。但也有很多場景需要綜合考慮OLTP與OLAP特性。2014年，Gartner公司正式提出了HTAP，它是在保留原有在線交易功能的同時，也能夠針對最新的業務數據進行實時統計分析。

本節將針對這些不同負載的需求，探討數據庫的起源、數據庫的轉型、數據庫的國產化以及數據庫的選型策略。

1.4.1　關系數據庫起源

在數據庫管理系統（DBMS）出現以前，數據存儲在文件里，但文件對結構化的數據管理非常不方便，隨著人們對數據應用和處理的要求越來越高，傳統的文件系統已經不能滿足人們的需要，能夠統一管理和共享數據的數據庫管理系統便應運而生。網狀數據庫和層次型數據庫是最先發展起來的，但在20世紀70年代，關系數據庫逐漸興起。與網狀數據庫和層次數據庫相比，關系數據庫具有明顯的優點：數據獨立性高、重復性低、存取修改更方便等。這些顯著的優點，使關系數據庫逐漸取代了網狀數據庫和層次數據庫。

以下是關系數據庫發展過程中具有里程碑意義的歷史事件。

1970年，IBM研究員E.F.Codd在Communications of ACM雜志上發表了一篇名為“A Relational Model of Data for Large Shared Data Banks”的論文，這也成為關系數據庫歷史上的奠基之作。

1977年6月，Oracle公司創始人Larry Ellison抓住了關系數據庫這個巨大的商業機會，通過引入SQL、原子事務等關鍵特性，在數據庫領域迅速站穩了腳跟，并在1989年正式進入中國。Oracle數據庫目前最新版本為Oracle 19c。

1983年，Db2正式問世，被IBM大型機所專用，之所以名字為Db2，是由于以前已經有了一個著名的層次數據庫產品Information Management System（IMS）。

1992年，IBM將Db2帶向了多種開放式平臺，包括Linux、UNIX以及Windows服務器，也簡稱為Db2 LUW，目前最新版本為Db2 V11。

1979年，Monty Widenius開發了一個名為Unireg的面向報表的存儲引擎，這是MySQL數據庫的最早追溯。

1996年，MySQL 1.0發布。

1999年，瑞典MySQL AB公司成立，開發出了Berkeley DB引擎，從此MySQL開始支持事務處理，這意味著開源數據庫管理系統開始逐漸引領潮流。

2000年，MySQL采用GPL許可協議，正式進入開源的世界。

2005年，MySQL 5.0正式發布，這個版本加入了存儲過程、觸發器、視圖、查詢優化器的改進和支持，為MySQL邁向高性能數據庫服務器奠定了基礎。

2006年，MySQL InnoDB引擎發布并贏得青睞，成為最流行的開源數據庫引擎。

2008年，MySQL AB公司被Sun公司以10億美元收購，Sun公司對其進行了大量的優化和缺陷修復工作。

2009年，Oracle公司以74億美元收購Sun公司，自此MySQL數據庫進入了Oracle時代，MySQL開始出現企業版和社區版兩個分支進行演進。

MySQL社區版目前最新版本為V8，隨著互聯網和商業銀行更多的技術開發人員加入，相信它會不斷完善，發展會越來越好。

1.4.2　從商業數據庫到開源數據庫轉型

長久以來，數據庫由于技術挑戰大、產品成熟度和服務質量級別要求高，始終由IBM、Oracle等傳統巨頭緊握市場份額和獲取途徑。

面對著日漸繁雜且高度異構的企業環境，企業越來越無力應付數據的快速增長以及工作負載。然而，隨著金融科技的發展，開源數據庫因為能夠滿足企業新的需求，可以代替企業已有解決方案，從而逐步打開市場需求，已然成為商業銀行發展進化的必要選擇。

（1）依托源代碼不斷開發、優化人才、社區、開源的生態。開源本身對工程師非常有吸引力，它的理想主義，會感召完美主義和理想主義追求者加入。

（2）通過開源數據庫社區的打造，吸引技術的追求者和開源的熱愛者加入，將有共同理念和夢想的人聚在一起，相互學習交流，形成積極正向循環。

（3）互聯網或技術圈很喜歡進行技術分享，通過分享產品樹立品牌，所以，總體社區會變成一個正向的循環，使用越頻繁，問題反饋越多，修復問題越多，從而形成開源數據庫的超強適應能力和修復能力。

從商業銀行云平臺市場環境來看，云計算已然由概念走向實踐，發展勢頭迅猛。對未來的開發者來說，如果在云上有使用數據庫的需求，這是開源數據庫的用武之地。未來一切的業務都會依托云端，不管是私有云、公有云還是混合云，運維團隊接觸的不再是數據庫服務器，而是一個個隔離的虛擬機或者容器。

1.4.3　從集中式到分布式數據庫轉型

20世紀70年代初興起的關系數據庫屬于集中式數據庫，這種數據庫一直延續到21世紀初，在金融行業發揮了巨大作用。

但是，集中式數據庫就像一個容器，數據就是容器中的液體，容器無論如何都有上限，能接納的液體也是有限的。特別是隨著商業銀行應用（也包括互聯網應用）的用戶規模、數據量都越來越大，并且要求7×24 h在線。傳統集中式數據庫在這種環境下成為瓶頸，通常有兩種解決方法：一是升級服務器硬件，這稱為垂直擴展（Scale Up），這種方式簡單直接，但單機處理能力有限；二是對數據分片，使用由廉價機器組成的分布式的集群，這稱為水平擴展（Scale Out），但以前在一個數據庫里的數據，現在跨了多個數據庫，涉及關聯、分布式事務時復雜度高。在集中式數據庫出現性能瓶頸的時候，分布式數據庫應運而生。

2009年，Google提出了Spanner方案，并隨后實現了全球化的分布式關系數據庫F1，用于其廣告系統。

2015年，亞馬遜發布了Aurora數據庫，它專為云而打造，在分布式存儲上提供高性能的MySQL和PostgreSQL數據庫集群，既具有傳統企業數據庫的性能和可用性，又具有開源數據庫的簡單性和成本效益。

2016年，螞蟻集團發布分布式數據庫OceanBase 1.0，并在支付寶賬務系統中成功上線。

2019年，中信銀行與中興通訊聯合研發的GoldenDB分布式數據庫在2020年5月成功上線，替代了在中信銀行核心系統服役了多年的IBM AS400數據庫。

當前，正處于商業銀行從集中式數據庫到分布式數據庫轉型的關鍵期，后續將有不斷的自研分布式數據庫涌現，并會有更多的系統從集中式數據庫遷移到分布式數據庫。

1.4.4　國產數據庫發展

近兩年逐漸看到一些重大的核心業務系統遷移到國產數據庫上，國產數據庫正在不斷發展，提供了豐富的產品功能，受到各大商業銀行前所未有的重視。

說起國產數據庫的開山始祖，非人民大學的薩師煊教授莫屬。薩師煊與其學生王珊合著的《數據庫系統概論》，直到現在依舊是我國數據庫領域的經典教材。早在1978年，薩師煊教授就開始為中國人民大學的學生們普及數據庫的知識。

總結來看，國產數據庫的自主可控之路大概經歷了以下三個階段。

第一階段：跟隨階段。2000年前后，主要跟隨國外的Oracle、Db2等數據庫，國產數據庫面臨很大的困境，技術比國外的數據庫技術落后十年以上，國外數據庫成熟的產品、成熟的客戶、成熟的使用案例都是國內跟隨者所不具備的，國產OLTP數據庫通過國家的扶持進行技術的積極拓荒。

第二階段：追趕階段。針對數據倉庫領域的MPP數據庫技術蓬勃發展，國產OLAP數據庫領域與國外同類產品的技術差距逐漸縮小，同時國內客戶對國產OLAP的接受度逐漸提升。這個階段OLAP數據庫主要應用在非核心業務場景，客戶對系統可靠性、穩定性接受度較好。國產OLAP數據庫在數據倉庫領域得到了較大的發展。

第三階段：技術大爆發階段。在大數據、互聯網、開源等技術的發展推動下，現有數據庫技術無法滿足國內企業應用場景的規模和性能等需求，國內技術人員對數據庫內核相關技術掌握越來越深入和全面。

隨著國家對自主可控的需求不斷提高，國產數據庫迎來更大的發展機遇。

1．戰勝Oracle的國產利器——螞蟻OceanBase

時間到了2020年，國產數據庫可謂是精彩紛呈：螞蟻OceanBase再破TPC速度記錄；阿里云PorlarDB首進Gartner數據庫領域的領導者象限；華為GaussDB革命性功能全密態地發布。

隨著移動互聯網大潮來臨，我國IT巨頭應用方面的創新令人印象深刻，如O2O、共享單車、自動駕駛、移動支付等新應用，但是各大商業銀行的核心數據庫卻一直被Oracle與Db2等國外產品牢牢把持著。

2019年，螞蟻的OceanBase數據庫成功登頂世界上最權威的數據庫評測機構TPC（國際事務處理性能委員會）排行榜榜首。

2020年5月，OceanBase再次將自己之前創造的記錄提升了近十一倍，將甲骨文、IBM等一眾老牌數據庫巨頭甩在身后，正式宣告國產數據庫落后于國際先進水平的時代已成過往云煙，自研數據庫產品自此站起來了。

2．金融級核心數據庫——GoldenDB

2019年10月26日，中信銀行與中興通訊聯合研發的GoldenDB分布式數據庫在中信銀行信用卡核心業務系統投產；2020年5月3日，GoldenDB在中信銀行總行賬務核心業務系統投產。兩大核心投產后，GoldenDB順利通過網聯壓測、雙11、年終決算、618與季度結息等現網考驗，運行穩定。這標志著GoldenDB分布式數據庫已是成熟穩定的產品，達到業界領先水平。

中興通訊GoldenDB是一款具有銀行基因的金融級分布式數據庫產品，從架構層面保證事務強一致和數據高可靠，并可根據業務需要實現在線擴容，具備如下特點。

（1）對應用透明、實時強一致的分布式事務。銀行業務邏輯相對復雜、數據一致性要求嚴格，當前大部分的分布式數據庫產品不支持實時強一致的分布式事務，不適合直接拿來借鑒和使用。同時，銀行應用遷移也要求分布式事務處理必須對業務透明，像使用傳統集中數據庫一樣使用分布式數據庫。GoldenDB通過全局事務管理器（GTM）、自動補償機制等架構設計，保證分布式事務的實時一致性讀和一致性寫。基于GoldenDB分布式數據庫，不僅能夠快速開發新業務，銀行已有的應用系統也能夠平滑遷移，幾十年來積淀的應用資產得以繼承。

（2）系統組件高可靠。GoldenDB為分布式計算與數據存儲分離的架構設計。在計算集群中，每個計算節點均為無狀態設計，可以隨時接入或移出計算集群，任意計算節點異常，由對等節點接管業務；表數據在數據集群中切分為多個數據分片，每個數據分片對應一個安全組，安全組由多臺機器組成，通過多副本冗余機制保障數據的高可靠。

（3）兩地三中心高可靠。GoldenDB支持兩地三中心部署，本地機房和同城機房之間數據實時同步，本地機房故障時切換到同城機房，數據零丟失。本地機房和異地機房之間距離較遠，通常采用異步方式復制。

（4）在線擴容。GoldenDB滿足銀行大容量存儲、高并發訪問的要求。當存儲容量或者處理規模達到瓶頸時，通過在線增加機器設備即可實現擴容。數據節點擴容時，通過后臺計劃任務自動完成數據重分布，整個擴容過程不影響在線業務運行，滿足銀行業務7×24 h不停機要求。

3．傳統數據庫的終結者——PolarDB

2010年前后，中國的互聯網企業普遍迎來了一波流量爆發。其中，繼2003年推出支付寶以后，淘寶在2005—2012年的交易迅速增長，交易額從80億元、200億元到1000億，直到破萬億。不過這種爆炸式增長，也成為阿里人甜蜜的負擔，因為阿里電聯用戶的增長速度已經漸漸超出系統處理能力的提升速度，而原來一直沿用的IOE（IBM小型計算機、Oracle數據庫和EMC存儲）中心化系統與這種高用戶并發的場景幾乎格格不入，暫且不論達到如此性能的IOE系統成本會有多驚人，問題的關鍵在于即使是當時最強大的科技公司，也沒有經歷過上億用戶同時在線的業務場景，使用國外的產品方案有如南轅北轍，無法真正解決問題。

正因此，王堅院士率先提出去IOE的目標，通過技術自研來解決用戶爆發式增長的問題。

在IOE架構的系統中提升算力的思路是讓服務器越來越強，云計算的分布式思路是只需要增加服務器節點的數量，就能處理更多的并發服務請求，而分布式系統的業務連續性，并不是靠高可用性來保證，而是靠整個服務體系的容錯能力造就的。在不斷探索的過程中，也誕生了新的分布式架構，通過發揮云計算的威力，使得看似普通的虛擬機集群，能夠碾壓一體機，能夠為億萬用戶同時提供優質的服務。

根據Gartner于2020年11月24日發布的2020年度全球數據庫魔力象限評估結果，阿里云憑借PolarDB的強大性能首次挺進全球云數據庫供應商的第一陣營，進入領導者（LEADERS）象限。Gartner在報告中指出“阿里云擁有豐富的數據庫種類覆蓋度和完善的產品布局，為用戶提供了多種關系型和非關系型數據庫產品，還提供了混合云環境部署，同時集成了備份、數據遷移與同步等能力。”

PorlarDB除了在索引結構、鎖機制等傳統數據庫組件方面進行優化以外，還特別針對云服務特有的全球跨域數據同步與容災需求，進行了重點設計。很多云服務客戶的業務遍及世界各個大洲，因此對于云數據庫的跨域數據同步也會有非常高的要求。PolarDB全球數據庫（PolarDB Global Database Network，PolarDB-GDN）采用了數據庫物理日志異步復制的方案。PolarDB-GDN通過高并發流水線技術將同步速度提升了7倍，將數據跨大洲同步延遲控制在2 s內。全局讀寫分離技術結合多級別的一致性能力，讓業務在不做任何改造的前提下降低整體的訪問延遲，全面滿足了云用戶的需求。

國產數據庫的未來可期！

1.4.5　數據庫選型策略

目前可選的數據庫種類繁多，關系數據庫既存在商業數據庫Oracle、Db2、SQL Server、Sybase、Teradata等；也存在開源數據庫MySQL、MariaDB、PostgreSQL等。那么伴隨著各種數據庫的發展，商業銀行如何選擇適合自己技術路線的數據庫產品呢？

這個問題本質上是數據庫技術路線規劃問題。

商業銀行需要結合本行數據庫部署現狀，結合數據庫技術和市場發展方向，規劃符合本行實際的數據庫發展演進路線圖。通過技術路線規劃，指導新建系統數據庫軟件的使用，并對存量系統制訂遷移計劃，以降低運維溝通成本。

（1）梳理存量產品目錄：對數據庫使用情況進行梳理，形成目錄清單，給出使用標準。

（2）制訂產品部署標準：明確不同部署需求下數據庫選擇和配置標準，規范新建系統數據庫使用，降低運維資源投入。

（3）規劃產品技術路線：對技術方向不明確、存在路線選擇的領域，給出選擇意見或選擇策略，制訂數據庫發展技術路線規劃。

（4）針對人民銀行推進國產化的要求，開展數據庫國產化路線研究，制訂評估流程、準入標準、定期評估機制等，明確數據庫軟件國產化的策略、節奏、路徑、試錯機制。

對產品目錄、部署標準進行線上化管理，建立數據庫特性和系統指標的關聯關系，指導針對應用系統的數據庫技術架構和部署架構設計。