從存算分離說(shuō)起：金融行業(yè)數(shù)據(jù)庫(kù)分布式改造之路

從上世紀(jì)90年代正式起步至今，中國(guó)數(shù)據(jù)庫(kù)發(fā)展已走過(guò)近30年歲月。以2000年前后為拐點(diǎn)，以MySQL為首的開源數(shù)據(jù)庫(kù)，在互聯(lián)網(wǎng)廠商的推動(dòng)下，逐步進(jìn)入生產(chǎn)業(yè)務(wù)；而為了使單實(shí)例能力平庸的MySQL能夠滿足高性能要求，互聯(lián)網(wǎng)廠商開始將原來(lái)的數(shù)據(jù)庫(kù)與表通過(guò)各種邏輯進(jìn)行拆分，形成了新的技術(shù)路線。這，就是分布式數(shù)據(jù)庫(kù)。

在2023華為金融創(chuàng)新數(shù)據(jù)基礎(chǔ)設(shè)施峰會(huì)，華為與一眾銀行、證券等金融行業(yè)伙伴，聯(lián)合發(fā)布OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案，提出以專業(yè)全閃存存儲(chǔ)和存算分離架構(gòu)，使能分布式數(shù)據(jù)庫(kù)創(chuàng)新升級(jí)，助力金融行業(yè)數(shù)據(jù)庫(kù)平滑改造。此次發(fā)布引起行業(yè)熱議，什么是“分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案”？華為為何與金融行業(yè)伙伴聯(lián)合發(fā)布？又為何如此強(qiáng)調(diào)“存算分離”？本文將從此話題出發(fā)，詳細(xì)剖析華為此次大會(huì)發(fā)布的方案內(nèi)容，和背后金融行業(yè)數(shù)據(jù)庫(kù)分布式改造不得不說(shuō)的故事。

存算分離，金融數(shù)據(jù)庫(kù)改造的重要抉擇

在金融行業(yè)內(nèi)，數(shù)據(jù)庫(kù)使用的主要場(chǎng)景有核心交易、互金類APP、分析類應(yīng)用、辦公等內(nèi)部應(yīng)用等。其中核心交易場(chǎng)景常使用IBM大型機(jī)+DB2或小型機(jī)+Oracle，對(duì)數(shù)據(jù)庫(kù)的時(shí)延、強(qiáng)一致性和可用性有非常高的要求；互金類應(yīng)用要求數(shù)據(jù)庫(kù)有高并發(fā)和易擴(kuò)展能力，同時(shí)對(duì)數(shù)據(jù)一致性、數(shù)據(jù)庫(kù)可用性也提出了較高的訴求，常常使用MySQL類分布式數(shù)據(jù)庫(kù)+容器的技術(shù)。

如今，隨著金融業(yè)務(wù)規(guī)模逐步擴(kuò)大和政策形式的變化，金融行業(yè)各業(yè)務(wù)場(chǎng)景數(shù)據(jù)庫(kù)系統(tǒng)正在逐步向國(guó)產(chǎn)數(shù)據(jù)庫(kù)改造；但除了辦公等非關(guān)鍵業(yè)務(wù)場(chǎng)景，核心業(yè)務(wù)場(chǎng)景改造仍進(jìn)展緩慢。對(duì)于這一現(xiàn)象，其根本問(wèn)題在于國(guó)產(chǎn)數(shù)據(jù)庫(kù)，尤其是分布式數(shù)據(jù)庫(kù)，大都采用存算一體架構(gòu)，使其在數(shù)據(jù)層面可用性、性能和可管理性都缺乏保障，難以滿足金融行業(yè)要求。

從技術(shù)角度分析，存算一體架構(gòu)的數(shù)據(jù)庫(kù)，的確難以滿足金融核心場(chǎng)景訴求。存算一體架構(gòu)指的是采用服務(wù)器本地盤存儲(chǔ)數(shù)據(jù)的架構(gòu)；由于服務(wù)器本地盤的可靠性不足，存算一體架構(gòu)下數(shù)據(jù)庫(kù)往往通過(guò)一主多備的形式提升系統(tǒng)可用性。但在主庫(kù)和備庫(kù)間同步數(shù)據(jù)時(shí)存在一組難以克服的矛盾：如果主備間采用同步復(fù)制，即備庫(kù)數(shù)據(jù)庫(kù)從邏輯上與主庫(kù)完全一致，則嚴(yán)重影響主庫(kù)性能；如果主備間采用半同步或者異步復(fù)制，則無(wú)法保證主備數(shù)據(jù)完全一致。這一矛盾在分布式系統(tǒng)性中無(wú)法調(diào)和，這也使得該類數(shù)據(jù)庫(kù)幾乎無(wú)法同時(shí)滿足金融核心高性能和強(qiáng)一致性的要求。

對(duì)于金融核心場(chǎng)景，容災(zāi)是必要的能力。根據(jù)《商業(yè)銀行數(shù)據(jù)中心監(jiān)管指引》要求，總資產(chǎn)規(guī)模一千億人民幣以上的商業(yè)銀行和省農(nóng)信等，應(yīng)該設(shè)立異地模式災(zāi)備中心，且要求至少達(dá)到RTO <2天、RPO 0-30分鐘的容災(zāi)水平；實(shí)際上對(duì)于五大行或頭部股份制核心系統(tǒng)，基本要求達(dá)到RTO分鐘級(jí)、RPO=0的最高水平。而開始提到存算一體架構(gòu)在主從復(fù)制間產(chǎn)生的問(wèn)題，在容災(zāi)場(chǎng)景下表現(xiàn)更為顯著，因?yàn)殒溌防h(yuǎn)后故障場(chǎng)景更為復(fù)雜（如鏈路抖動(dòng)、光纖劣化等），而當(dāng)前還沒有廠商在服務(wù)器+以太網(wǎng)上對(duì)這一問(wèn)題進(jìn)行成熟優(yōu)化。因此，目前采用存算一體架構(gòu)的數(shù)據(jù)庫(kù)，幾乎都采用單集群拉遠(yuǎn)+異步復(fù)制模式，核心業(yè)務(wù)下分布式數(shù)據(jù)庫(kù)強(qiáng)一致性容災(zāi)的案例基本沒有。

在管理面上，存算一體同樣存在許多問(wèn)題。由于計(jì)算和存儲(chǔ)強(qiáng)綁定，導(dǎo)致資源無(wú)法按需擴(kuò)張，勢(shì)必導(dǎo)致一邊資源出現(xiàn)浪費(fèi)；從實(shí)際落地來(lái)看，由于服務(wù)器容量有限，計(jì)算資源往往是浪費(fèi)較多的一方。許多率先進(jìn)行數(shù)據(jù)庫(kù)分布式改造的金融用戶，已擁有近萬(wàn)臺(tái)服務(wù)器，但CPU資源利用率還不到10%；而這近萬(wàn)臺(tái)服務(wù)器里有數(shù)十萬(wàn)塊硬盤，對(duì)其健康度和故障的管理更是令運(yùn)維大呼頭疼。

對(duì)以上問(wèn)題進(jìn)行根因分析，除了分布式系統(tǒng)無(wú)法擺脫的“CAP詛咒”以外，歸根結(jié)底還是因?yàn)榉?wù)器本身不太關(guān)注數(shù)據(jù)可靠性和易管理設(shè)計(jì)；而當(dāng)前數(shù)據(jù)庫(kù)廠商基本只具備北向滿足用戶功能的能力，對(duì)南向提升數(shù)據(jù)高可用、高效率管理能力缺乏技術(shù)積累，無(wú)法彌補(bǔ)服務(wù)器在該方面的不足，最終導(dǎo)致數(shù)據(jù)庫(kù)整系統(tǒng)達(dá)不到金融核心要求。

如今，隨著政策形勢(shì)和業(yè)務(wù)需求變化，國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)走向核心已是大勢(shì)所趨；與其等待應(yīng)用層緩慢的技術(shù)演進(jìn)，把專業(yè)的事交給專業(yè)的人來(lái)做顯然是更可行的辦法。專業(yè)存儲(chǔ)專注于數(shù)據(jù)高可用、高性能、易管理，技術(shù)演進(jìn)已近40年，擁有豐厚的技術(shù)積累和實(shí)踐經(jīng)驗(yàn)，能夠更快的閉環(huán)分布式數(shù)據(jù)庫(kù)存在的諸多問(wèn)題；更重要的是，使用專業(yè)存儲(chǔ)將引導(dǎo)分布式數(shù)據(jù)庫(kù)走向Share Storage的數(shù)據(jù)共享架構(gòu)，為改變主備間數(shù)據(jù)同步這一底層邏輯提供了可行性，而這一邏輯正是分布式數(shù)據(jù)庫(kù)無(wú)法擺脫性能與強(qiáng)一致性矛盾的根源。以上幾點(diǎn)構(gòu)成了分布式數(shù)據(jù)庫(kù)走向存算分離架構(gòu)的技術(shù)必然性。如今，不論是AWS Aurora、openGauss，還是PolarDB、TDSQL，都在向存算分離架構(gòu)靠攏，這絕不會(huì)是一種巧合

分布式新核心，如何撐起“核心”之名？

因?yàn)楦鞣N原因，部分大型銀行已經(jīng)啟動(dòng)了核心系統(tǒng)分庫(kù)分表改造，并使用分布式數(shù)據(jù)庫(kù)打造新一代核心系統(tǒng)。這就是分布式新核心。然而，正如前面所述，銀行核心系統(tǒng)對(duì)于可靠性有非常嚴(yán)苛的要求，而當(dāng)前的分布式數(shù)據(jù)庫(kù)大都無(wú)法滿足，導(dǎo)致分布式新核心運(yùn)行的業(yè)務(wù)往往并不那么核心。如何讓分布式新核心撐起“核心”之名？華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案給出了自己的答案。

華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案基于存儲(chǔ)同步復(fù)制技術(shù)，實(shí)現(xiàn)了分布式數(shù)據(jù)庫(kù)的雙集群容災(zāi)。相比于傳統(tǒng)分布式數(shù)據(jù)庫(kù)采用單級(jí)群拉遠(yuǎn)的方式，該方案可以有效實(shí)現(xiàn)集群間故障隔離，是當(dāng)前唯一滿足金融核心容災(zāi)要求的方案。那么華為是如何做到的呢？

以下圖為例。當(dāng)前分布式數(shù)據(jù)庫(kù)大部分采用圖左的復(fù)制方式，通過(guò)服務(wù)器間的以太網(wǎng)絡(luò)，將 主節(jié)點(diǎn)日志同步到各個(gè)從節(jié)點(diǎn)。不論采用邏輯復(fù)制還是物理復(fù)制，該方案最大的問(wèn)題是因?yàn)榉?wù)器欠缺數(shù)據(jù)高可用保障能力，需要應(yīng)用層大量處理遠(yuǎn)程容災(zāi)下的腦裂、鏈路抖動(dòng)、壞塊、誤碼、丟包等等問(wèn)題，當(dāng)前任何數(shù)據(jù)庫(kù)都無(wú)法提供保障；許多數(shù)據(jù)庫(kù)僅通過(guò)PAXOS協(xié)議處理腦裂問(wèn)題，就已經(jīng)對(duì)業(yè)務(wù)性能產(chǎn)生巨大影響了。這也是為何當(dāng)前沒有分布式數(shù)據(jù)庫(kù)支持RPO=0的多地強(qiáng)一致性容災(zāi)的原因。

華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案，讓分布式數(shù)據(jù)庫(kù)將Redo Log流寫入存儲(chǔ)，并通過(guò)OceanStor存儲(chǔ)強(qiáng)大的同步復(fù)制功能，將日志復(fù)制到遠(yuǎn)端容災(zāi)數(shù)據(jù)中心的存儲(chǔ)當(dāng)中；遠(yuǎn)端數(shù)據(jù)中心通過(guò)日志實(shí)時(shí)回放，保證了備數(shù)據(jù)庫(kù)與主庫(kù)的數(shù)據(jù)一致。由于有專業(yè)存儲(chǔ)強(qiáng)大的復(fù)制能力保障，主庫(kù)事務(wù)執(zhí)行不必等待遠(yuǎn)端備庫(kù)寫入成功，只要日志寫入完成就可以提交，使得其性能相比于當(dāng)前分布式數(shù)據(jù)庫(kù)大幅提升。該方案中，主數(shù)據(jù)中心和容災(zāi)數(shù)據(jù)中心的數(shù)據(jù)庫(kù)是兩個(gè)互相隔離的集群，從數(shù)據(jù)面到管理面都是完全隔離的，這很好的解決了因管理節(jié)點(diǎn)或存儲(chǔ)故障導(dǎo)致整個(gè)集群發(fā)生癱瘓的問(wèn)題。相信不少人已經(jīng)發(fā)現(xiàn)，華為方案與oracle ADG實(shí)現(xiàn)方式有異曲同工之妙，而Oracle正式憑借企業(yè)級(jí)存儲(chǔ)成熟而強(qiáng)大的復(fù)制能力做到了這一點(diǎn)。

除了存儲(chǔ)同步復(fù)制以外，針對(duì)遠(yuǎn)程容災(zāi)難以解決的鏈路質(zhì)量劣化問(wèn)題，OceanData解決方案也有自己的獨(dú)家解法。傳統(tǒng)的容災(zāi)方案中，只能通過(guò)主數(shù)據(jù)中心和容災(zāi)中心間的心跳包感知復(fù)制鏈路劣化，需要花費(fèi)數(shù)分鐘時(shí)間才能察覺，并倒換到冗余的鏈路上，可能導(dǎo)致金融企業(yè)數(shù)千筆交易失敗；華為的解決方案通過(guò)波分設(shè)備與存儲(chǔ)設(shè)備聯(lián)動(dòng)感知的SOCC技術(shù)，可在毫秒級(jí)時(shí)間內(nèi)感知到鏈路劣化，并在兩秒內(nèi)完成鏈路倒換，時(shí)刻保證復(fù)制鏈路的暢通無(wú)阻，避免因抖動(dòng)對(duì)前端業(yè)務(wù)造成性能影響或者交易失敗。專業(yè)存儲(chǔ)強(qiáng)大而有效的可靠性保障手段，始終是金融企業(yè)核心價(jià)值的守護(hù)神；即使在分布式新核心時(shí)代，這一點(diǎn)也絲毫不例外。

金融微服務(wù)改造，如何擁有金融級(jí)高可靠？

容器技術(shù)以其輕量化部署和敏捷化管理的特點(diǎn)，開始逐步在金融行業(yè)獲得廣泛應(yīng)用；許多金融企業(yè)選擇將互聯(lián)網(wǎng)金融APP等敏態(tài)業(yè)務(wù)部署到容器上；而對(duì)于部分傳統(tǒng)應(yīng)用，也掀起了一股微服務(wù)化改造的熱潮。

根據(jù)《容器有狀態(tài)應(yīng)用調(diào)研報(bào)告》，由于各類應(yīng)用需求，數(shù)據(jù)庫(kù)是容器化部署最多的應(yīng)用。然而，容器對(duì)于應(yīng)用的可靠性保障機(jī)制事實(shí)上比較缺乏，尤其對(duì)于分布式數(shù)據(jù)庫(kù)這類有狀態(tài)應(yīng)用，很多故障場(chǎng)景都需要人工介入保障；但對(duì)于金融企業(yè)的應(yīng)用，可靠性都是最不能忽視的重要特性。想象在微服務(wù)改造環(huán)境下，成千上萬(wàn)個(gè)Pod同時(shí)運(yùn)行，如果所有錯(cuò)誤都需要人工介入處理，運(yùn)維成本無(wú)法想象，容器集群穩(wěn)定性將完全不可控。

針對(duì)這一痛點(diǎn)，華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案通過(guò)自研容器存儲(chǔ)接口，打造出一套高可靠又不失敏捷的分布式數(shù)據(jù)庫(kù)容器化部署方案，讓金融微服務(wù)改造的應(yīng)用，也擁有金融級(jí)高可靠。

首先，我們需要介紹下傳統(tǒng)容器的故障處理機(jī)制。以目前最常用的Kubernetes為例，在使用有狀態(tài)應(yīng)用時(shí)，一般采用StatefulSet控制器進(jìn)行容器管理。當(dāng)一個(gè)節(jié)點(diǎn)故障，節(jié)點(diǎn)上的所有Pod與Kubernetes管理節(jié)點(diǎn)失聯(lián)；此時(shí)由于Kubernetes無(wú)法判斷該節(jié)點(diǎn)是否真的故障了，上面的Pod和服務(wù)是否已經(jīng)停止，它不會(huì)自動(dòng)將Pod在另一個(gè)正常節(jié)點(diǎn)重新啟動(dòng)，以避免引起不可預(yù)測(cè)的業(yè)務(wù)錯(cuò)誤。此時(shí)需要人工介入，將故障的節(jié)點(diǎn)從集群中強(qiáng)行刪除，Kubernetes才會(huì)重新在新的節(jié)點(diǎn)上拉起Pod和服務(wù)。

即使解決了故障拉起問(wèn)題，采用存算一體架構(gòu)的數(shù)據(jù)庫(kù)還會(huì)面臨另一個(gè)問(wèn)題：數(shù)據(jù)恢復(fù)。由于故障節(jié)點(diǎn)本地盤上的數(shù)據(jù)無(wú)法訪問(wèn)，新節(jié)點(diǎn)需要全量重構(gòu)數(shù)據(jù)后才能成為真正的從庫(kù)，這往往依賴于主節(jié)點(diǎn)到從節(jié)點(diǎn)的復(fù)制。根據(jù)業(yè)務(wù)壓力，單節(jié)點(diǎn)重構(gòu)一般耗時(shí)6-10小時(shí)，期間業(yè)務(wù)性能和可靠性都會(huì)受到影響。

針對(duì)上述痛點(diǎn)，華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案從兩方面著手，提升數(shù)據(jù)庫(kù)可靠性。

首先，還是基于存算分離，將數(shù)據(jù)庫(kù)改造為Share Storage架構(gòu)，通過(guò)專業(yè)存儲(chǔ)保障數(shù)據(jù)高可用，服務(wù)器故障數(shù)據(jù)不丟；當(dāng)新節(jié)點(diǎn)拉起時(shí)，可將數(shù)據(jù)重新掛載給新節(jié)點(diǎn)，只需要增量同步故障恢復(fù)期間寫入的數(shù)據(jù)即可，這樣補(bǔ)從時(shí)間可縮短至5分鐘左右，對(duì)業(yè)務(wù)影響和可靠性風(fēng)險(xiǎn)都大大降低了。

其次，通過(guò)存儲(chǔ)與主機(jī)間的IO狀態(tài)，主動(dòng)感知服務(wù)器故障，并通過(guò)華為自研容器存儲(chǔ)接口實(shí)現(xiàn)故障節(jié)點(diǎn)的主動(dòng)驅(qū)逐，并將故障POD的PV掛載給新拉起的POD，彌補(bǔ)原生Kubernetes依賴人工處理故障的問(wèn)題。華為解決方案依托存算分離優(yōu)勢(shì)，有效解決了云原生應(yīng)用中存在的固有問(wèn)題，使金融微服務(wù)改造真正達(dá)到金融級(jí)高可用要求。

傳統(tǒng)核心應(yīng)用分布式數(shù)據(jù)庫(kù)，不分庫(kù)分表行不行？

說(shuō)完了分布式改造的場(chǎng)景，最后來(lái)討論這個(gè)話題：使用分布式數(shù)據(jù)庫(kù)，能不能不分庫(kù)分表？相信這是許多DBA的心聲。傳統(tǒng)核心做分布式改造，涉及到大庫(kù)表的拆分、切片，存儲(chǔ)過(guò)程的改寫，上層業(yè)務(wù)要做單元化修正、事務(wù)一致性保證、串并邏輯修正等，這些都需要花費(fèi)大量時(shí)間和人力，且很難做到完美。即使完成了改造，跨表Join和事務(wù)執(zhí)行效率等還是降低許多，很多存儲(chǔ)過(guò)程無(wú)法使用，大事務(wù)無(wú)法使用，對(duì)后期的開發(fā)也造成了許多困難。

分庫(kù)分表雖然在高并發(fā)場(chǎng)景的確有一定優(yōu)勢(shì)，但對(duì)于大部分非互聯(lián)網(wǎng)企業(yè)而言，其代價(jià)和收益不成正比。是否有辦法幫助金融企業(yè)平滑渡過(guò)這最難的一關(guān)呢？華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案同樣給出了回應(yīng)。

追本溯源，為什么分布式數(shù)據(jù)庫(kù)需要分庫(kù)分表？其根本動(dòng)機(jī)是，以MySQL為代表的開源生態(tài)數(shù)據(jù)庫(kù)，其實(shí)例能力完全無(wú)法與Oracle等商用數(shù)據(jù)庫(kù)比擬。Oracle在使用RAC以后，可以多實(shí)例并發(fā)讀寫，性能強(qiáng)上加強(qiáng)，單個(gè)節(jié)點(diǎn)故障也不影響業(yè)務(wù)；而MySQL等由于不支持RAC，多節(jié)點(diǎn)最多只能一寫多讀，性能有瓶頸，且主從切換業(yè)務(wù)會(huì)斷，為了減少性能影響面和爆炸半徑，只能做分庫(kù)分表。假如能讓MySQL這類開源生態(tài)數(shù)據(jù)庫(kù)，也擁有多讀多寫的能力，甚至擁有和RAC類似的機(jī)制，是否可以不需要再分庫(kù)分表了呢？

華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案正是從這一突破口入手破解難題。華為在共享存儲(chǔ)的基礎(chǔ)上，推出了多寫使能接口，包含兩大引擎—“參天”多寫使能引擎和“DBStor”共享加速引擎—以實(shí)現(xiàn)MySQL等開源生態(tài)的多讀多寫。

“參天”多寫使能引擎在ShareStorage的基礎(chǔ)上，進(jìn)一步實(shí)現(xiàn)ShareMemory。它將傳統(tǒng)在持久化層分布式改造的邏輯，改為在緩存層分布式改造；通過(guò)緩存層高性能數(shù)據(jù)處理和RDMA的高性能通信能力，彌補(bǔ)持久化層數(shù)據(jù)同步帶來(lái)的性能與可靠性問(wèn)題。“參天”多寫使能引擎主要完成了四大功能：

全局資源管理：完成全局節(jié)點(diǎn)資源的注冊(cè)、頁(yè)面與鎖資源的傳輸?shù)裙ぷ?，將散布在各個(gè)節(jié)點(diǎn)緩存中的資源進(jìn)行統(tǒng)一管理與調(diào)配，是全局并發(fā)讀寫提供執(zhí)行層面保障；

全局鎖管理：完成不同節(jié)點(diǎn)間鎖資源的請(qǐng)求、釋放等管理邏輯，支持spinlock、分布式latch、死鎖檢測(cè)等，它是全局并發(fā)讀寫時(shí)的事務(wù)一致性的主要保障者；

全局頁(yè)面管理：完成不同節(jié)點(diǎn)間的頁(yè)面資源的加載、請(qǐng)求、釋放等管理邏輯，它為全局資源視圖的一致性提供邏輯層面保障，以支持并發(fā)讀寫和分布式MVCC；

全局集群管理：完成在共享存儲(chǔ)上注冊(cè)節(jié)點(diǎn)信息，管理各自節(jié)點(diǎn)的進(jìn)程狀態(tài)、網(wǎng)絡(luò)狀態(tài)等，并與其它節(jié)點(diǎn)及共享存儲(chǔ)互通狀態(tài)信息的工作；單節(jié)點(diǎn)故障時(shí)，會(huì)觸發(fā)仲裁、選主等故障恢復(fù)流程，與共享存儲(chǔ)共同確保整集群對(duì)外正常提供業(yè)務(wù)。

在全局一份數(shù)據(jù)共享的基礎(chǔ)上，“參天”多寫使能引擎解決了緩存層上的數(shù)據(jù)統(tǒng)一，使得過(guò)去的主從節(jié)點(diǎn)間可以保持實(shí)時(shí)強(qiáng)一致性，進(jìn)化為多主架構(gòu)，進(jìn)而實(shí)現(xiàn)并發(fā)讀寫，大大提升了數(shù)據(jù)庫(kù)集群的性能、吞吐量和可靠性。

“DBStor”共享加速引擎主要是在ShareStorage的基礎(chǔ)上實(shí)現(xiàn)讀寫能力增強(qiáng)，其主要功能包括：

數(shù)據(jù)庫(kù)IO協(xié)議棧簡(jiǎn)化：減少主機(jī)側(cè)數(shù)據(jù)庫(kù)IO在數(shù)據(jù)庫(kù)、文件系統(tǒng)、塊設(shè)備間頻繁的上下文切換，進(jìn)而降低IO直通時(shí)延；

數(shù)據(jù)庫(kù)算子下推：感知數(shù)據(jù)庫(kù)語(yǔ)義，并將大表掃描等部分SQL運(yùn)算下推至存儲(chǔ)完成，并提供索引存儲(chǔ)，大幅優(yōu)化SQL執(zhí)行效率；

高速網(wǎng)絡(luò)：通過(guò)華為NoF+高速網(wǎng)絡(luò)處理IO，大幅優(yōu)化傳輸時(shí)延，保障網(wǎng)絡(luò)穩(wěn)定無(wú)抖動(dòng)。

“DBStor”共享加速引擎增強(qiáng)了開源數(shù)據(jù)庫(kù)的執(zhí)行效率，使其性能大幅增加，大大彌補(bǔ)了其與Oracle之間的處理能力差距。

從過(guò)去到現(xiàn)在，金融核心系統(tǒng)的訴求并沒有發(fā)生根本變化，因此解題思路也應(yīng)該是相似的。華為OceanData分布式數(shù)據(jù)庫(kù)存儲(chǔ)解決方案秉承這一理念，以專業(yè)存儲(chǔ)+創(chuàng)新引擎，填補(bǔ)了分布式數(shù)據(jù)庫(kù)在Oracle ASM和 RAC上缺乏對(duì)標(biāo)產(chǎn)品的空白，將持久化層分布式邏輯轉(zhuǎn)移到緩存層，破解了“分布式數(shù)據(jù)庫(kù)必分庫(kù)分表”的業(yè)界難題。從當(dāng)前現(xiàn)網(wǎng)實(shí)踐效果來(lái)看，大表性能已經(jīng)基本匹配Oracle；節(jié)點(diǎn)故障業(yè)務(wù)不中斷，可靠性也已向Oracle看齊。自此，核心系統(tǒng)分布式數(shù)據(jù)庫(kù)改造，終于有了免分庫(kù)分表的平滑改造方案。

在需求與政策的大趨勢(shì)，金融行業(yè)數(shù)據(jù)庫(kù)改造已經(jīng)在所難免。但是，不論是哪一種改造方式，高可用都是金融行業(yè)不變的核心訴求。過(guò)去幾十年來(lái)，通過(guò)傳統(tǒng)數(shù)據(jù)庫(kù)與高可靠專業(yè)存儲(chǔ)的良好配合，金融行業(yè)逐步形成了值得信賴的高可用系統(tǒng)建設(shè)體系；如今，在分布式數(shù)據(jù)庫(kù)新生態(tài)下反復(fù)摸爬與碰壁中，我們可以看到存算分離+專業(yè)存儲(chǔ)體系，依然是數(shù)據(jù)庫(kù)高可靠的堅(jiān)實(shí)守護(hù)者。

生成海報(bào)

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評(píng)論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個(gè)人觀點(diǎn)，與極客網(wǎng)無(wú)關(guān)。文章僅供讀者參考，并請(qǐng)自行核實(shí)相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。