本文來自微信公眾號“twt企業(yè)IT社區(qū)”，作者/趙海 某金融系統(tǒng)高級主管。
一、引言
信創(chuàng)是國家近些年來的一項基本戰(zhàn)略。信創(chuàng)產(chǎn)業(yè)作為戰(zhàn)略性新興產(chǎn)業(yè)，國家不斷出臺相關(guān)政策對行業(yè)的發(fā)展進行支持。政策扶持對于信創(chuàng)產(chǎn)業(yè)發(fā)展推進的意義重大，我國信創(chuàng)產(chǎn)業(yè)競爭力不斷突破，國產(chǎn)化進程穩(wěn)步推進，政策重點提及“數(shù)字經(jīng)濟”、“數(shù)字政府”和國家信息化。在信息化產(chǎn)業(yè)當中，數(shù)據(jù)庫是企業(yè)信創(chuàng)戰(zhàn)略當中非常關(guān)鍵的一環(huán)。但是大多數(shù)企業(yè)在面對這個命題的時候可能會感到迷茫，從最初的Db2、Sybase替換為Oracle是順應(yīng)單機架構(gòu)向高可用架構(gòu)轉(zhuǎn)變的技術(shù)趨勢，今天面臨的是完全不一樣的環(huán)境背景，那么今天的抉擇又應(yīng)如何考慮呢？
二、數(shù)據(jù)庫轉(zhuǎn)型的基本原則
其實作為企業(yè)信息科技來講，無論做什么樣的抉擇，首要解決的問題就是應(yīng)該遵循什么樣的原則去做選擇題。只有原則清晰才能指導(dǎo)具體的決策選擇以及完善項目落地過程。就數(shù)據(jù)庫的信創(chuàng)替換來講，筆者認為要從國家戰(zhàn)略結(jié)合企業(yè)自身發(fā)展維度去定制響應(yīng)原則，具體說來有以下幾方面：
1.符合“自主可控”和“安全可靠”原則
從企業(yè)自身角度出發(fā)，“自主可控”并不代表數(shù)據(jù)庫產(chǎn)品品牌符合國產(chǎn)要求就可以了，而是需要考慮到企業(yè)自身對該產(chǎn)品的使用、升級以及維護有沒有控制力度，這個控制力度是不是可持續(xù)。所謂的“安全可靠”也并不是說甩掉了外資因素的產(chǎn)品就一定是安全的，這個安全是要考慮到產(chǎn)品本身的源頭技術(shù)是不是安全，產(chǎn)品的市場地位以及未來發(fā)展是不是安全。這個“安全”二字涵蓋了知識產(chǎn)權(quán)維度、產(chǎn)品生命周期維度、源頭技術(shù)維度以及產(chǎn)品使用維度。
2.最優(yōu)契合度原則
對于企業(yè)的數(shù)據(jù)管理系統(tǒng)來講，根據(jù)企業(yè)的行業(yè)、業(yè)務(wù)、客戶等方面的差異，會導(dǎo)致其數(shù)據(jù)模型、數(shù)據(jù)量級、數(shù)據(jù)分布、數(shù)據(jù)存取有自己的特點。另外，其數(shù)據(jù)管理平臺從架構(gòu)、數(shù)據(jù)保護、性能、使用方式等方面的需求也會不一樣。Oracle產(chǎn)品一代又一代的功能創(chuàng)新以及版本更新正是這些因素催生的結(jié)果。那么今天面對信創(chuàng)替換選型的時候，所選的產(chǎn)品應(yīng)該具備以下兩個必要條件：
①產(chǎn)品類型應(yīng)高度符合業(yè)務(wù)系統(tǒng)數(shù)據(jù)模型、量級、分布、存取之所需。
②產(chǎn)品功能應(yīng)覆蓋數(shù)據(jù)管理平臺的容災(zāi)、數(shù)據(jù)保護、性能、使用方式等方面之所需。
3.可持續(xù)發(fā)展原則
回顧Db2被Oracle替換的歷程，不是Db2原始版本的性能不再滿足客戶需求導(dǎo)致的，也不是因為其成本昂貴導(dǎo)致的。筆者認為真正導(dǎo)致它退出歷史舞臺的原因是它的迭代發(fā)展速度以及方向背離了客戶環(huán)境的可持續(xù)性發(fā)展需求。當廉價的硬件服務(wù)器替換掉昂貴的IBM小型機的時候，它選擇的不是順應(yīng)而是牽制；當客戶需要從單機、主備等架構(gòu)模式升級到雙活模式的時候，它的迭代沒有跟上；當人力市場上隨處可找到Oracle數(shù)據(jù)庫管理員的時候，它的培訓(xùn)還是那么高傲。對于企業(yè)來講，信創(chuàng)選型的時候難道還要重蹈覆轍再來一次替換么？當然，要想評估可持續(xù)這個因素，單從技術(shù)方面評估是片面的，更重要的是需要研究歷史并且綜合生態(tài)、市場、定位等很多非技術(shù)因素來判斷。
三、數(shù)據(jù)庫轉(zhuǎn)型的關(guān)鍵因素
1.應(yīng)用場景契合度
所謂應(yīng)用場景契合度，包含兩方面的意思：
首先，數(shù)據(jù)模型是不是契合？例如金融行業(yè)的賬務(wù)系統(tǒng)是以二維表模型設(shè)計的數(shù)據(jù)庫表，而信創(chuàng)選型的時候偏偏選擇了以文檔為主要數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)庫產(chǎn)品。即使業(yè)務(wù)層支持，那么數(shù)據(jù)模型以及存取邏輯需要重新設(shè)計，數(shù)據(jù)需要轉(zhuǎn)化，數(shù)據(jù)平臺的架構(gòu)配置等方面都需要面臨巨大調(diào)整以及風(fēng)險。這樣的選擇應(yīng)該說契合度不是很好。
其次，拿金融行業(yè)的業(yè)務(wù)系統(tǒng)舉例來說，有些系統(tǒng)是以少量數(shù)據(jù)隨機行為為主的聯(lián)機業(yè)務(wù)，有些系統(tǒng)是以大量數(shù)據(jù)有序行為為主的分析類業(yè)務(wù)。數(shù)據(jù)庫產(chǎn)品本身針對不同的數(shù)據(jù)行為場景也會有不同的類型及版本區(qū)分的，如果是錯配了的選擇一定會是糟糕的選擇。
當然，實際情況當中需要考慮的細節(jié)因素會因為應(yīng)用場景的多維度特點而更加復(fù)雜。
2.高可用及容災(zāi)架構(gòu)契合度
數(shù)據(jù)平臺的高可用及容災(zāi)架構(gòu)對于金融行業(yè)來講是非常重要的考慮因素。尤其是一些交易類的系統(tǒng)，通常容災(zāi)框架、節(jié)點高可用、數(shù)據(jù)讀寫這幾個方面都是經(jīng)過精心規(guī)劃設(shè)計的。
容災(zāi)框架通常會是包含網(wǎng)絡(luò)、平臺、數(shù)據(jù)庫、存儲等幾個層面的整體設(shè)計方案。那么數(shù)據(jù)庫作為其中的一環(huán)，信創(chuàng)轉(zhuǎn)型時不僅僅要考慮到產(chǎn)品本身的容災(zāi)架構(gòu)契合度，而且要考慮到其是否能融入現(xiàn)有或者轉(zhuǎn)型后的整體容災(zāi)體系。
節(jié)點高可用也是企業(yè)數(shù)據(jù)庫平臺的關(guān)鍵因素。這里不僅要考慮到產(chǎn)品是否可以實現(xiàn)ＡＡ的功能模式，更重要的是要考慮到故障場景下的切換機制以及性能極限時的分發(fā)機制。所以這里的契合度不在于功能層的實現(xiàn)，而在于實現(xiàn)功能的細節(jié)是否契合數(shù)據(jù)業(yè)務(wù)的需求。
數(shù)據(jù)讀寫伴隨著數(shù)據(jù)量級的增加是需要精細化規(guī)劃的，很多企業(yè)為了實現(xiàn)讀寫方面的隔離或者讀和寫的分離進行了大量的設(shè)計優(yōu)化，并且付出了大量的成本。這要求數(shù)據(jù)庫產(chǎn)品在讀寫識別方面與應(yīng)用有很好的親和度，在分發(fā)過程中有強悍的技術(shù)功底背書。如果信創(chuàng)轉(zhuǎn)型所選的產(chǎn)品不能實現(xiàn)這方面的功能或者實現(xiàn)的非常弱，那么顯然這應(yīng)該歸為契合度非常低的選型方案。
3.數(shù)據(jù)保護及恢復(fù)的契合度
數(shù)據(jù)保護是企業(yè)數(shù)據(jù)庫為了保障數(shù)據(jù)的安全在存儲副本、事務(wù)回溯以及數(shù)據(jù)備份方面采用的系列措施。例如Oracle的存儲副本可以采用ASM方式進行多種冗余方式，提供多種的副本讀寫以及容錯控制機制，正是這些靈活可控的優(yōu)化設(shè)計參數(shù)才能契合企業(yè)數(shù)據(jù)保護的需求。對于事務(wù)回溯來講，不同的產(chǎn)品對于事務(wù)記錄的原理、顆粒度、持久化機制以及回溯的準確性、時效性以及可控程度會有較大區(qū)別。對于數(shù)據(jù)備份和恢復(fù)，更是要結(jié)合RTO、RPO指標，綜合考慮其便利性、靈活性、安全性等方面因素。
所以，信創(chuàng)轉(zhuǎn)型后的產(chǎn)品設(shè)計也應(yīng)該有副本冗余、副本讀寫及恢復(fù)控制、事務(wù)記錄及恢復(fù)控制、數(shù)據(jù)備份及恢復(fù)方面的豐富可選、可控、可優(yōu)化的機制才能契合到契合的數(shù)據(jù)業(yè)務(wù)需求。當然，我們需要對這些機制的原理以及應(yīng)用案例方面評估它的技術(shù)成熟度以及可持續(xù)性。
4.工具使用契合度
工具使用包含兩個層面的含義：一方面是數(shù)據(jù)遷移替換過程中的工具，另外一方面是數(shù)據(jù)運維管理工程中所用的工具。
信創(chuàng)轉(zhuǎn)型涉及到企業(yè)數(shù)據(jù)以及數(shù)據(jù)接口整體遷移到信創(chuàng)平臺的全過程。這里面必然涉及數(shù)據(jù)轉(zhuǎn)化、數(shù)據(jù)遷移以及數(shù)據(jù)測試驗證等關(guān)鍵環(huán)節(jié)，這些環(huán)節(jié)的工作效率以及結(jié)果的正確都必須有相應(yīng)的工具來保障。當然，這個工具有效性的評估不是依靠產(chǎn)品專家的講解和說明，更多的是原理的分析和脫敏數(shù)據(jù)的驗證。
信創(chuàng)轉(zhuǎn)型之后涉及到企業(yè)的數(shù)據(jù)平臺運維管理。不同企業(yè)對待數(shù)據(jù)業(yè)務(wù)的運維管理有不同的要求，但是通常來講可以從數(shù)據(jù)指標監(jiān)控、數(shù)據(jù)收集匯總、數(shù)據(jù)分析利用、數(shù)據(jù)平臺變更、數(shù)據(jù)故障處理等幾個方面來分析其契合度。當然，這里面不僅是數(shù)據(jù)庫產(chǎn)品本身的事情，而是結(jié)合其生態(tài)上下游以及企業(yè)自身信創(chuàng)整體環(huán)境來綜合考慮這些因素的契合度。
四、結(jié)語
基于企業(yè)傳統(tǒng)數(shù)據(jù)庫信創(chuàng)轉(zhuǎn)型的場景，本文剖析了三個基本原則以及四個選型時應(yīng)該考慮的關(guān)鍵因素，整體詮釋了傳統(tǒng)關(guān)系型數(shù)據(jù)庫向信創(chuàng)轉(zhuǎn)型的選型思路以及方法。實際場景中，不同的企業(yè)有不同的IT背景和不同的訴求，在把握核心基本原則和要素的前提下，謀求業(yè)務(wù)發(fā)展的創(chuàng)新和蛻變或許是一種更有積極意義和現(xiàn)實價值的轉(zhuǎn)型，但是這種變革需要以業(yè)務(wù)因素為驅(qū)動力，組織業(yè)務(wù)、管理、科技等各個條線共同參與并推進的整體戰(zhàn)略。期盼未來更有先行者可以站在具體業(yè)務(wù)場景的整體高度分享信創(chuàng)的業(yè)務(wù)創(chuàng)新和技術(shù)變革案例。
