大中型企業(yè)關鍵應用數(shù)據(jù)庫未來會如何走向?

在信創(chuàng)、云計算、開源等多重因素影響下,大中型企業(yè)關鍵應用數(shù)據(jù)庫未來將何去何從?本議題旨在剖析數(shù)據(jù)庫演進趨勢,揭示真實挑戰(zhàn),幫助企業(yè)幫助企業(yè)更好地把握關鍵應用數(shù)據(jù)庫建設發(fā)展趨勢。

本文來自微信公眾號“twt企業(yè)IT社區(qū)”。

【欄目主編】Bryan某國有大型銀行資深架構師:本議題由某農(nóng)商銀行架構師胡海光、某金融機構架構師李威、太平保險集團某省級分公司技術支持工程師張曉斌發(fā)表針對議題下關鍵點的主張,幾位專家的主張在招商銀行數(shù)據(jù)庫架構師張稞斌、金電信科數(shù)據(jù)庫架構師時朋泉及我本人等多位專家的復議后,形成了一定的共識,希望可以對同行有一定的參考。

李威 某金融機構架構師:

信創(chuàng)、開源和云計算,改寫了數(shù)據(jù)庫市場的未來走向。

縱觀中大型企業(yè)關應用支撐,OLTP和OLAP仍是中堅力量,新生代數(shù)據(jù)庫的推廣和應用仍需要一定時間來積蓄。中大型企業(yè)的業(yè)務起步積累較早,此時關系型數(shù)據(jù)庫正處在飛速發(fā)展時期,在業(yè)務系統(tǒng)的籌建、數(shù)據(jù)模型的設計、經(jīng)濟模式的拓展都與OLTP數(shù)據(jù)庫的更新迭代如影相隨,每一次數(shù)據(jù)庫的重大更新都在推進著中大型企業(yè)向前邁進躍進,OLTP數(shù)據(jù)庫也在企業(yè)信息化建設上占據(jù)上風。在完成初期業(yè)務積累后,數(shù)據(jù)分析及再利用的需求也加速了OLAP數(shù)據(jù)庫的實踐落地,隨著大數(shù)據(jù)概念逐步融入信息化轉型的進程中,湖倉一體化的分析型架構也現(xiàn)代信息基礎架構上留下了一筆。

云時代的到來,數(shù)據(jù)庫也能結合云原生架構和分布式架構的優(yōu)勢拓展與云上應用的聯(lián)動能力。在云架構中,上層數(shù)據(jù)庫應用可以選擇應用集群部署也能夠實現(xiàn)容器化落地。同時,數(shù)據(jù)庫的底層結合云原生能力與云原生架構能大幅提高每個數(shù)據(jù)庫元節(jié)點的處理能力,增強跨庫跨表的聯(lián)合查詢性能、更加匹配中大型企業(yè)關鍵應用的橫向能力要求。云原生能力對關鍵應用數(shù)據(jù)庫的持續(xù)賦能必將是數(shù)據(jù)庫進化的趨勢之一。

2022年1月份至6月份國務院、工信部相繼頒布《“十四五”國家信息化規(guī)劃》、《關于開展“攜手行動”促進大中小企業(yè)融通創(chuàng)新》、《關于加強數(shù)字化政府建設的指導意見》等政策,規(guī)劃指出進一步提高自主可控水平,加強自主創(chuàng)新,加快推動數(shù)字產(chǎn)業(yè)化、關鍵核心技術攻關,以開源生態(tài)構建為重點,打造高水平產(chǎn)業(yè)生態(tài),以軟件價值提升為抓手,推動數(shù)字產(chǎn)業(yè)能級躍升。國內(nèi)各信創(chuàng)廠商在MySQL及PostgreSQL等開源生態(tài)的基礎上推出了企業(yè)級數(shù)據(jù)庫產(chǎn)品。信創(chuàng)數(shù)據(jù)庫在金融、電商、游戲、通訊等中大型企業(yè)的主要業(yè)務場景已經(jīng)落地生根,其中基于MySQL生態(tài)的信創(chuàng)數(shù)據(jù)庫QPS(每秒查詢率)在實際交易場景上能夠達到2萬—5萬次。基于PostgreSQL生態(tài)的信創(chuàng)產(chǎn)品最高每秒可以處理超過10萬次查詢。中國從不缺少誕生希冀的土壤,信創(chuàng)數(shù)據(jù)庫的誕生與實踐也用事實說明了“開源+信創(chuàng)”技術路線的可行性,借助開源技術機動起步與本土化資源有機結合,將“業(yè)務助力技術”這種業(yè)務發(fā)展推動技術更新的被動轉化為“技術驅動業(yè)務”,技術根據(jù)業(yè)務的特性著力打造產(chǎn)品驅動業(yè)務在核心場景上落地的主動姿態(tài)。

疫情后經(jīng)濟形勢的轉變,也在潛移默化地影響著關鍵業(yè)務數(shù)據(jù)庫的選型與更迭,數(shù)據(jù)分析類業(yè)務發(fā)展的刺激也將加速OLAP類數(shù)據(jù)庫的嶄露頭角,高性能數(shù)據(jù)庫支撐也在很長一段繼續(xù)作為中大型企業(yè)核心經(jīng)濟業(yè)務的中流砥柱。在國家政策高基攻堅的指導以及信創(chuàng)生態(tài)的蓬勃生長下,信創(chuàng)數(shù)據(jù)庫勢必在未來的十年里占據(jù)一席之地。任何的專業(yè)能力沉淀到產(chǎn)品力,都將經(jīng)歷一段時間的饋贈,信創(chuàng)數(shù)據(jù)庫的發(fā)展趨勢亦是如此。這也是眾多中小型企業(yè)對自主可控數(shù)據(jù)庫技術最大的期許。

胡海光 某農(nóng)商銀行架構師:

得益于互聯(lián)網(wǎng)業(yè)務和開源技術的快速發(fā)展,開源關系型數(shù)據(jù)庫MySQL和PostgreSQL為代表的數(shù)據(jù)庫相繼誕生和快速發(fā)展,在現(xiàn)有數(shù)據(jù)庫市場中嶄露頭角。

以大中型企業(yè)關鍵應用數(shù)據(jù)庫未來的走向為題簡要說明在開源和信創(chuàng)趨勢的浪潮下數(shù)據(jù)庫未來的發(fā)展趨勢和脈絡。

就數(shù)據(jù)庫行業(yè)的發(fā)展和演變歷程來看,大致歸類為三大階段。

1、前關系型階段:1964年第一個數(shù)據(jù)庫管理系統(tǒng)網(wǎng)狀數(shù)據(jù)管理系統(tǒng)IDS開發(fā)成型,到1968年IMS系統(tǒng)作為最早的商用數(shù)據(jù)庫管理系統(tǒng)正式發(fā)布,此階段數(shù)據(jù)庫主要用于解決數(shù)據(jù)獨立存儲、統(tǒng)一管理和統(tǒng)一訪問等問題,與之相應的是缺乏相應的數(shù)據(jù)庫理論基礎支撐;

2、關系型階段:1970年數(shù)據(jù)庫關系型模型理論初步提出隨后關系型數(shù)據(jù)庫RDBMS誕生,SQL語言被國際標準組織定義為數(shù)據(jù)庫國際標準語言并成為主流語言開始引領數(shù)據(jù)庫變革,之后PostgreSQL、MySQL和Access等關系型數(shù)據(jù)庫相繼誕生,進一步豐富和完善數(shù)據(jù)庫理論;

3、后關系型階段:隨著互聯(lián)網(wǎng)技術的迅猛發(fā)展,數(shù)據(jù)結構發(fā)生層次改變,數(shù)據(jù)量級呈現(xiàn)指數(shù)級增長,為有效應對海量數(shù)據(jù)及多樣數(shù)據(jù)結構,NoSQL和NewSQL等非關系型數(shù)據(jù)庫產(chǎn)品相繼推出,進一步豐富數(shù)據(jù)庫使用類別和適應企業(yè)業(yè)務發(fā)展需求,也進一步促進了數(shù)據(jù)庫相關技術的推進和發(fā)展。

貫穿數(shù)據(jù)庫技術的發(fā)展歷史,數(shù)據(jù)庫經(jīng)歷了從理論的形成、發(fā)展到成熟,從架構的提出、優(yōu)化到成型,從產(chǎn)品的打磨、豐富到迭代三個階段,數(shù)據(jù)庫已經(jīng)奠定了一定理論和技術基礎,同時在架構上也日趨成熟。在過去國內(nèi)大中型企業(yè)對國外數(shù)據(jù)庫產(chǎn)品(如Oracle、Db2、SQL Server等)的依賴程度非常高,普遍應用于企業(yè)的核心和重要系統(tǒng)業(yè)務上,當然由于國外數(shù)據(jù)庫產(chǎn)品起步早,產(chǎn)品比較成熟,在產(chǎn)品穩(wěn)定性和性能表現(xiàn)力等方面都處于領先地位,因此在國內(nèi)企業(yè)數(shù)據(jù)庫市場份額居高不下。

隨著開源關系型數(shù)據(jù)庫MySQL和PostgreSQL(簡稱:PG)為代表的數(shù)據(jù)庫相繼誕生和快速發(fā)展,得益于互聯(lián)網(wǎng)業(yè)務和開源技術的快速發(fā)展,去IOE浪潮的持續(xù)深化,特別是國內(nèi)一些大廠(如阿里、騰訊、華為等)以開源MySQL和PG為底層架構相繼推出自家的數(shù)據(jù)庫產(chǎn)品迅速打開市場,貼合和匹配企業(yè)用戶的切身需求,贏得了一定的市場份額。

同時國際形勢的快速變化及科技競爭的日趨激烈,我國在一些關鍵技術和關鍵標準的構建上經(jīng)常處于較為被動的態(tài)勢,為解決此問題我國提出“數(shù)字中國”建設宏偉戰(zhàn)略,搶占數(shù)字經(jīng)濟產(chǎn)業(yè)鏈制高點。其中信息技術應用創(chuàng)新產(chǎn)業(yè)成為國內(nèi)數(shù)據(jù)庫行業(yè)發(fā)展的轉折點。在信創(chuàng)改革的推進下,數(shù)據(jù)庫的信創(chuàng)步伐早已完成布局、探索、優(yōu)化及落地,對于信創(chuàng)的適配度和支持度也在不斷提升?;诖?,對于國內(nèi)大中型企業(yè)來說,“開源+信創(chuàng)”是未來幾年不得不面對的方向,也是企業(yè)數(shù)據(jù)庫架構發(fā)展的趨勢。

在信創(chuàng)的加持下,以數(shù)據(jù)庫為代表的計算機軟硬件產(chǎn)品迎來一波爆發(fā)潮。在積極支持和適配硬件信創(chuàng)服務器的趨勢下,以信創(chuàng)和非信創(chuàng)兩種技術路線并存,同時進一步改造和優(yōu)化信創(chuàng)數(shù)據(jù)庫產(chǎn)品,使之在性能和穩(wěn)定性上能與非信創(chuàng)數(shù)據(jù)庫并駕齊驅。

市面上使用較廣的開源關系型數(shù)據(jù)庫有MySQL和PostgreSQL兩種技術路線,各有各的優(yōu)勢。PostgreSQL相比MySQL,有SQL的標準實現(xiàn)上要比MySQL完善、存儲過程的功能支持要比MySQL友好、對表連接支持較完整等優(yōu)勢。MySQL相比PostgreSQL,有MySQL的優(yōu)化器較簡單等優(yōu)勢。

基于這兩者的產(chǎn)品特性可以得出,PG更適合嚴格的企業(yè)應用場景(如金融、電信、ERP等);而MySQL更適合業(yè)務邏輯相對簡單、數(shù)據(jù)可靠性要求較低的互聯(lián)網(wǎng)場景。當然兩種技術路線數(shù)據(jù)庫都有自身的優(yōu)缺點,特別是國內(nèi)幾家大廠對于兩種技術路線的數(shù)據(jù)庫產(chǎn)品進行相應的改造、優(yōu)化、改進和封裝,在成熟度和穩(wěn)定性上進一步提升,同時推出基于兩種技術路線的相應數(shù)據(jù)庫產(chǎn)品線搶占市場,也為大中型企業(yè)在數(shù)據(jù)庫的選型上提供多種產(chǎn)品選擇。

張曉斌 太平保險集團某省級分公司技術支持工程師:

如今業(yè)務系統(tǒng)紛繁復雜,應當結合不同的場景找尋最合適替換的數(shù)據(jù)庫,這其實也是一個優(yōu)化配置,實現(xiàn)價值最大化的過程。

以保險企業(yè)運營部門核心系統(tǒng)為例,核心數(shù)據(jù)庫的建設與維護工作,集中體現(xiàn)在存儲、流程、服務。存儲方面,如我們的應用需求,首先要綜合分析整個系統(tǒng)的容量規(guī)劃,預計客戶信息等數(shù)據(jù)量增長,數(shù)據(jù)如何匯總;流程方面,流程如何做到快速故障響應和服務響應,各個數(shù)據(jù)接口之間數(shù)據(jù)是如何串聯(lián)的,如何進行統(tǒng)一查詢與分析;服務方面,對應用系統(tǒng)開發(fā)部門提出的需求、日常變更能夠快速響應和執(zhí)行,怎么能讓應用系統(tǒng)開發(fā)部門更了解數(shù)據(jù)庫的運行狀況,讓其幫助自身做一些性能方面的檢查,如何保證數(shù)據(jù)庫的數(shù)據(jù)安全和訪問安全也是重點。

大中型保險企業(yè),核心關鍵應用數(shù)據(jù)庫有三大核心需求:可用性、性能及安全。保險企業(yè)經(jīng)營當以穩(wěn)字當頭,用戶購買保險的目的是當客戶遇到合同約定的問題時可以進行快速理賠,而保險另外一個功能是存放資金。以上都決定了保險的經(jīng)營方式,而后臺能夠支撐得到理賠系統(tǒng)或是資金運作整個方面,數(shù)據(jù)庫均需要有極其嚴格細致的要求。時間需要準確,數(shù)字更要準確。保險業(yè)務隨時代發(fā)展而不斷轉變,同樣作為金融業(yè)的銀行系統(tǒng),它的進步驅動保險業(yè)同樣與時俱進,購買查詢、保單查詢、理賠查詢一氣呵成。再是需要應對監(jiān)管要求,在整個大環(huán)境中,要求每筆理賠款項都不能出錯。但實際上運維難度大,體現(xiàn)在磁盤和節(jié)點眾多,一旦出現(xiàn)問題就難以管理。

保險行業(yè)的關鍵應用數(shù)據(jù)庫正在經(jīng)歷國產(chǎn)化替代。如今國產(chǎn)數(shù)據(jù)庫尚未成熟,很多關鍵應用還待以驗證其可行性,在持續(xù)替換的過程中,企業(yè)或將面臨數(shù)據(jù)內(nèi)核、數(shù)據(jù)周邊、整體遷移、運維自動化等幾個方面的難題。分布式數(shù)據(jù)庫是近幾年的一個熱詞,金融企業(yè)關鍵應用一定需要用分布式數(shù)據(jù)庫嗎?并不見得。有三個事實不容忽視。第一,金融企業(yè)大多數(shù)業(yè)務復雜不至于集中式數(shù)據(jù)庫處理不過來,或者做一些數(shù)據(jù)庫的分庫拆分就能應對。第二,分布式數(shù)據(jù)庫從底層架構上有很強的的容錯能力,但不同數(shù)據(jù)庫這個能力參差不齊,在故障切換時,還不一定總是很平穩(wěn),而且人工無法干預。第三,保險企業(yè)要上真正的分布式數(shù)據(jù)庫,業(yè)務需要做大量改造,這個改造、適配的成本往往是很大的。

原先Oracle數(shù)據(jù)庫支撐了保險企業(yè)非常豐富的業(yè)務系統(tǒng),現(xiàn)階段幾乎無法找到一款數(shù)據(jù)庫產(chǎn)品能全方位替換,因此選擇適合具體業(yè)務場景的數(shù)據(jù)庫十分復雜而關鍵。是否一定要上分布式數(shù)據(jù)庫需要深思?;貧w初心,我們不是為了分布式而分布式,尋求整體TCO最優(yōu)、保障關鍵業(yè)務穩(wěn)定才是我們做國產(chǎn)化數(shù)據(jù)庫替換的核心。

結束語

數(shù)據(jù)庫國產(chǎn)化勢不可擋,“開源+信創(chuàng)”融合是落地數(shù)據(jù)庫國產(chǎn)化替代的可行策略。數(shù)據(jù)庫國產(chǎn)化≠分布式數(shù)據(jù)庫。尋求整體TCO最優(yōu)、保障關鍵業(yè)務穩(wěn)定才是數(shù)據(jù)庫國產(chǎn)化工作的核心。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論