一直以來，金融場景都是數(shù)據(jù)庫的最大練兵場，不僅是因為數(shù)據(jù)量龐大，同時，交易、分析、事故更加復(fù)雜，高頻高并發(fā)是金融數(shù)據(jù)庫的特性，更因為金融行業(yè)本身7×24小時不間斷，對數(shù)據(jù)庫安全性、穩(wěn)定性都有更高要求，運維也更加復(fù)雜。

王爽舉了一個例子：“以前銀行的交易來自于營業(yè)網(wǎng)點，存錢、取錢、轉(zhuǎn)錢，但現(xiàn)在已經(jīng)互聯(lián)網(wǎng)化了，頻率大大增加。以前一年去營業(yè)廳也就三五次，但現(xiàn)在用戶每天都在交易，每天點外賣、坐公交/地鐵，每刷一次都會產(chǎn)生數(shù)據(jù)。這就造成了爆炸性的數(shù)據(jù)量增長，傳統(tǒng)數(shù)據(jù)庫處理起來，成本非常巨大。所以，并不只是為了國產(chǎn)替代，更是為了升級。”

此前，企業(yè)在選擇國產(chǎn)數(shù)據(jù)庫時，第一考慮的是與Oracle的適配和兼容關(guān)系，以降低應(yīng)用和遷移成本?！?020年之前，幾乎所有的國產(chǎn)數(shù)據(jù)庫對企業(yè)宣傳的核心價值就是兼容Oracle和MySQL?！币晃粩?shù)據(jù)庫廠商對光錐智能講道。

但在真正落地時發(fā)現(xiàn)，兼容是不夠的，在適配時必須要取舍。Oracle數(shù)據(jù)庫壟斷了近20年，有很多特性逐漸落后，國產(chǎn)數(shù)據(jù)庫的單純替代沒有意義，底層架構(gòu)發(fā)生改變之后，性能要做到更加優(yōu)化。

更重要的是，銀行、保險、券商過去與Oracle進行了深度綁定，包括?定義鎖、?治事務(wù)、嵌套表、索引組織表、PLSQL包、物化視圖、DBlink、觸發(fā)器、系統(tǒng)視圖，改造難度極?，如何提升龐?存儲過程中的識別效率?關(guān)重要。

這不只依賴數(shù)據(jù)庫廠商一家來完成，更需要使用方一起深度改造。太保集團與OceanBase打磨的過程中，馬波勇總結(jié)了升級過程中的三大挑戰(zhàn)：

第一是國產(chǎn)數(shù)據(jù)庫的性能，能否滿足業(yè)務(wù)需求。“由于之前大部分系統(tǒng)使用傳統(tǒng)數(shù)據(jù)庫做支撐，在制定數(shù)據(jù)庫的選型策略和升級方案方面，系統(tǒng)的兼容性、穩(wěn)定性，數(shù)據(jù)遷移的便捷性、完整性是我們考慮的首要問題。第二，要考慮它在金融行業(yè)的應(yīng)用案例是否廣泛，是否具備足夠的成熟度。第三個是在運維方面，需要具備較強的自主營運能力和支撐能力”，馬波勇談道。

第二是數(shù)據(jù)庫的安全性和彈性伸縮能力。銀行保險業(yè)數(shù)據(jù)量大、私密性強、波峰波谷期動蕩，本地部署的數(shù)據(jù)庫能保證安全性，但是相應(yīng)的成本也會更高，且彈性伸縮能力差，無法靈活應(yīng)變銀行互聯(lián)網(wǎng)化后的高頻和多發(fā)需求。

第三是平滑遷移的能力。遷移的過程中保證業(yè)務(wù)不停，同時要高度兼容，節(jié)省調(diào)試時間。馬波勇談到：“太保集團作為32年的國企，數(shù)據(jù)量及業(yè)務(wù)量都很大，如何在有限的時間窗口，完成數(shù)據(jù)遷移，成為擺在太保集團面前的一大難題?！?

那么，這三座“大山”，太保和OceanBase是如何攜手跨過的？

最難的P17系統(tǒng)，OceanBase如何搞定？

OceanBase所升級的太保P17核心系統(tǒng)，同時面臨著上述的三座大山。

在太保的業(yè)務(wù)系統(tǒng)中，有P20的級別之分，P17是集團排名中的高級別，因此，該系統(tǒng)的成功升級具有標桿作用和里程碑意義?！癙17客戶服務(wù)系統(tǒng)”是太平洋保險產(chǎn)、壽、健康、長江等所有子公司客戶服務(wù)系統(tǒng)的整合，為公司6地8個電話中心超過2000坐席提供系統(tǒng)服務(wù)?！碧＜瘓F數(shù)智研究院首席數(shù)據(jù)庫專家林春介紹道。

“與一般熱線系統(tǒng)相比，‘P17客戶服務(wù)系統(tǒng)’涵蓋了太平洋保險幾乎所有子公司業(yè)務(wù)的服務(wù)入口功能，包括車險報案、車險增值服務(wù)、非車人意報案、道路救援、壽險保單查詢、壽險保全受理、投保預(yù)約等等，對接周邊系統(tǒng)超過200個，是太平洋保險關(guān)聯(lián)關(guān)系最為復(fù)雜的系統(tǒng)之一。”?

同時，作為太平洋保險的服務(wù)品牌，“P17客戶服務(wù)系統(tǒng)”需要提供7*24?時的全天服務(wù)，系統(tǒng)可?性要求全年99.9%以上，對停機時間有著嚴苛的控制。因此，也是太平洋保險運維保障最?的核?系統(tǒng)之?。

毫無疑問，對于P17的升級，是最為慎重的決定。2021年初，太保對國產(chǎn)分布式數(shù)據(jù)庫，從功能、性能、易用性、完整性、可移植性、可靠性、擴展性、安全性等指標進行了全方位評估，最終選擇了OceanBase升級傳統(tǒng)數(shù)據(jù)庫。

2022年上半年，在不少項目暫停、放緩之時，太保和OceanBase正在緊鑼密鼓的遠程協(xié)作，加班加點，只為搞定P17。

據(jù)林春回憶，2022年初啟動項目到8月31號，核心業(yè)務(wù)場景就完成了數(shù)據(jù)功能的開發(fā)；12月18日，P17第一個子系統(tǒng)成功上線，并完成了全量數(shù)據(jù)庫遷移；2023年5月6日，核心交易、相關(guān)的報表庫遷移上線；5月13日核心系統(tǒng)中最難的核心交易庫上線。至今，P17核心系統(tǒng)已經(jīng)成功運行了200多天，確保交易成功率達到99.99%。

“項目剛開始時，正是上海管控最緊張的時刻。大家沒辦法到場地，造成了很多困難，但是OB在產(chǎn)業(yè)側(cè)和技術(shù)側(cè)聯(lián)合攻堅，把這塊硬骨頭啃了下來?！绷执赫勂鸬巾椖康娜^程，仍然不禁感慨。

整個升級的流程，可以分為四個階段：

第一階段的重點，是通過OceanBase的分布式架構(gòu)徹底升級傳統(tǒng)商用的主備架構(gòu)，破除傳統(tǒng)數(shù)據(jù)庫與操作系統(tǒng)、中間件的耦合。據(jù)了解，與Oracle配套的DS、Cognos等產(chǎn)品對于Oracle深度依賴，適配改造復(fù)雜度很?，將數(shù)據(jù)庫分庫分表，從集中式拆分成分布式，每個分片都能夠獨立執(zhí)行讀寫，這個過程中需不斷拆解中間件和操作系統(tǒng)之間的關(guān)系。

第二階段，OceanBase和太保并沒有急著對業(yè)務(wù)進行升級，而是建立了遷移“標準”，一次次探索形成行業(yè)經(jīng)驗，破除替換升級的壁壘。

OceanBase華東區(qū)金融技術(shù)服務(wù)總監(jiān)郭文講道：“廠商和用戶側(cè)的目標是希望效果穩(wěn)定的與傳統(tǒng)數(shù)據(jù)庫兼容，標準化、流程化、制式化能夠降低雙方的人力投入，少走彎路，同時能夠復(fù)制工具和經(jīng)驗?！?

郭文介紹道：“OceanBase通過制定33類標準規(guī)范和28類最佳實踐，以及打磨了16款數(shù)據(jù)庫轉(zhuǎn)向工具，實現(xiàn)了標準化的Oracle兼容，這會極大程度破除遷移的不透明性，讓企業(yè)更有信心，意識到升級不再是一件特別困難的事情?！?

比如創(chuàng)新研發(fā)的“指南針”工具，能夠?qū)鹘y(tǒng)數(shù)據(jù)庫進?改造評估預(yù)掃描，包括近20個檢查?類，近200多個檢查項，評估項全??效，極?提升項?組問題排查的效率，縮短項?周期從?降低應(yīng)?改造成本。以“P17客戶服務(wù)系統(tǒng)”為例，掃描出改造項約6000個，假設(shè)???式排查2個問題/?時，單個項?即節(jié)約??成本12.6?/?。

第三階段，對P17中的業(yè)務(wù)場景進行逐個點測。對壽險保監(jiān)會稽核接口系統(tǒng)、壽險營銷員系統(tǒng)的傭金計算、智能決策服務(wù)平臺和壽險統(tǒng)一承保平臺等“一事一議”的替換。

第四階段，從點測到全面替換。這里的全面替換，并不只是P17系統(tǒng)的全面替換，而是太保秉持著“先難后易、應(yīng)替盡替”的原則，以P17這套最復(fù)雜的系統(tǒng)為模版，對太保幾百套系統(tǒng)進行分布式替換。

在全面替換后，國產(chǎn)數(shù)據(jù)庫的優(yōu)異性能開始展現(xiàn)出來。據(jù)太保反饋數(shù)據(jù)，在保持了高運行性能、高可用能力的同時，數(shù)據(jù)庫軟件的運維費用大幅降低，每年可節(jié)省設(shè)備投入數(shù)億元。特別是OceanBase的高級壓縮技術(shù)，結(jié)合“數(shù)據(jù)庫瘦身”，將存儲容量節(jié)省80%以上。

可以說，升級后的應(yīng)?系統(tǒng)彈性擴縮容、處理速度、數(shù)據(jù)加?能?均實現(xiàn)?幅提升。

長于金融的數(shù)據(jù)庫，更懂金融

?OceanBase與太保的探索經(jīng)驗，也帶動著金融數(shù)據(jù)庫發(fā)展進入下一個階段。

在整個實踐的過程中能夠明顯發(fā)現(xiàn)，金融場景考驗的不只是性能，更多還在于復(fù)雜業(yè)務(wù)中的靈活應(yīng)變能力和適應(yīng)能力。顯然，誕生于金融場景的OceanBase更懂行業(yè)的需求和痛點，也有機會能將實驗室的解決方案，搬到了業(yè)務(wù)中去。

2013年，OceanBase開始應(yīng)用于螞蟻集團的支付業(yè)務(wù)，當(dāng)時大部分互聯(lián)網(wǎng)企業(yè)都在采買Oracle，但隨著雙十一交易量的瞬時爆發(fā)，成本高企壓力之下，促使了云廠商們開始自研數(shù)據(jù)庫。

彼時OceanBase最核心的任務(wù)，是完成降本增效和彈性伸縮。在這兩個方面的經(jīng)驗，也在太保案例中得以體現(xiàn)。

正如前文所講，之所以將存儲容量節(jié)省至80%以上，來源于OceanBase獨創(chuàng)的高壓縮比的分布式存儲引擎，在提升業(yè)務(wù)系統(tǒng)穩(wěn)定性和安全性的前提下，存儲成本為70%-90%，同時硬件和維保資源投入顯著降低。

林春就算過一筆賬：“1TB的存儲成本傳統(tǒng)數(shù)據(jù)庫要4500塊錢，OceanBase壓縮到了三分之一，成本會大幅減少。另外數(shù)據(jù)庫加密之后，對場地成本要求就沒有那么高，也能降低硬件成本?！?

2020年山東移動計費業(yè)務(wù)系統(tǒng)接入OceanBase，其計費業(yè)務(wù)詳單處理時長縮短至5分鐘，處理效率提升30%，數(shù)據(jù)由7T壓縮至0.7T，存儲投入成本降低90%。

另一方面，OceanBase的單機一體化分布式架構(gòu)也能夠在硬件存儲資源幫助企業(yè)控制成本和靈活擴縮容。顧名思義，單機一體化的數(shù)據(jù)庫，既能夠適應(yīng)大型企業(yè)的系統(tǒng)逐步替換需求，在不需要分布式架構(gòu)時，也可以作為一個完整的集中數(shù)據(jù)庫提供，讓企業(yè)能夠部署更靈活。

同時，HTAP集TP（交易）和AP（分析）于一體的數(shù)據(jù)庫架構(gòu)，也能夠同時適應(yīng)TP場景和AP場景，單一引擎支持高性能混合負載應(yīng)用，通過基于時間片的混合負載調(diào)度技術(shù)，解決混合負載的資源隔離問題。一個典型案例是太保的壽險需要與保監(jiān)會稽核系統(tǒng)接口，以前該系統(tǒng)夜間批處理占據(jù)整體計算資源的90%以上，現(xiàn)在，相同資源的批處理節(jié)省了時間62%，監(jiān)管報送批量場景的性能提升了3倍。

除此之外，全自研數(shù)據(jù)庫也成為了OceanBase換道超車的關(guān)鍵。

OceanBase數(shù)據(jù)庫創(chuàng)始人、首席科學(xué)家陽振坤此前提到，“全自研是個苦活累活，OceanBase數(shù)據(jù)庫是從第一行代碼開始，到現(xiàn)在積累了幾百萬行代碼量，但是好處也顯而易見?！?

讓林春印象最深刻的是OceanBase對Bug的修復(fù)速度非常震撼。常常很多問題，大致是第一天發(fā)現(xiàn)，第二天就能更新一個修復(fù)版本，這就體現(xiàn)了OceanBase全自研數(shù)據(jù)庫，將內(nèi)核代碼都掌握在自己手中的特點。Bug修復(fù)速度是技術(shù)兜底的一個很好的驗證，如果沒有對核心代碼的掌控，從排查問題到解決問題，就做不到閃電速度。

也正是因為上述原因，讓大型銀行、保險業(yè)開始對國產(chǎn)數(shù)據(jù)庫充滿信心。

但這也只是萬里長征的第二階段，數(shù)字化、智能化的車輪滾滾向前，國產(chǎn)數(shù)據(jù)庫從金融場景“殺”出來之后，千行百業(yè)中還有更廣闊的星辰大海。

歡迎關(guān)注光錐智能B站號，獲取更多前沿科技知識！