在當(dāng)前越來越強(qiáng)調(diào)云原生的環(huán)境下，存儲計(jì)算分離已經(jīng)是大勢所趨。幾乎所有我們熟知的云數(shù)據(jù)庫都已經(jīng)開始使用存算分離實(shí)現(xiàn)資源價(jià)值的最大化，比如阿里的PolarDB，AWS 的Aurora，華為GaussDB for MySQL等。大量企業(yè)自建數(shù)據(jù)中心也開始采用“開源數(shù)據(jù)庫+存算分離”的方式進(jìn)行部署。

　　那么，我們來看看這些先進(jìn)的互聯(lián)網(wǎng)公司和數(shù)字化轉(zhuǎn)型的企業(yè)，是怎么不約而同在數(shù)據(jù)庫改造中一步步走向“存算分離”的呢?

　　分布式數(shù)據(jù)庫是時(shí)代的選擇

　　從1970年IBM的E.F Codd在論文《A Ralational Model of Data for Large Shared Data Banks》中提出的數(shù)據(jù)庫系統(tǒng)關(guān)系模型，開創(chuàng)了數(shù)據(jù)庫關(guān)系方法和關(guān)系數(shù)據(jù)理論的研究，為數(shù)據(jù)庫技術(shù)奠定了理論基礎(chǔ)，到1977年 Oracle數(shù)據(jù)庫發(fā)布，開啟了IBM DB2和Oracle等大型商業(yè)公司壟斷數(shù)據(jù)庫市場二十年。

　　直到90年代中期，隨著互聯(lián)網(wǎng)時(shí)代的來臨，開源數(shù)據(jù)庫MySQL，PostgreSQL的出現(xiàn)，這種壟斷現(xiàn)象才被打破，以MySQL為代表的開源數(shù)據(jù)庫開始迅速發(fā)展。

　　21世紀(jì)10年代，數(shù)據(jù)的井噴式增長，對數(shù)據(jù)庫提出了水平擴(kuò)展，大集群規(guī)模，高并發(fā)等新訴求，緊接著隨著公有云的蓬勃發(fā)展，以云為載體兼具高可擴(kuò)展性、高并發(fā)性、高可用性的分布式數(shù)據(jù)庫，如谷歌Spanner，Snowflake，AWS Aurora等逐漸走進(jìn)我們的視野。

　　至此我們可以看到分布式數(shù)據(jù)庫的誕生是順應(yīng)時(shí)代的發(fā)展，是時(shí)代的選擇。

　　分布式數(shù)據(jù)庫改造，存算一體部署之殤

　　分布式數(shù)據(jù)庫最成功的應(yīng)用場景就是支撐了早期電商業(yè)務(wù)的快速發(fā)展，然而隨著企業(yè)數(shù)字化轉(zhuǎn)型的深入，數(shù)據(jù)總量和形式呈現(xiàn)指數(shù)級的增長，數(shù)據(jù)庫要應(yīng)對的是不斷飆升的業(yè)務(wù)下高性能、高可靠的挑戰(zhàn);與此同時(shí)，不斷飆升的業(yè)務(wù)高峰還要求數(shù)據(jù)庫有極好的彈性伸縮能力、持續(xù)服務(wù)能力和合理的成本。

　　而原有的分布式數(shù)據(jù)庫“存算一體”，采用服務(wù)器本地盤的部署方式就越發(fā)顯得力不從心。

　　例如，由于計(jì)算、存儲資源捆綁，在應(yīng)對如雙11這類突發(fā)資源高峰時(shí)，無法只對計(jì)算資源進(jìn)行快速擴(kuò)容，分布式改造后無法支持單獨(dú)彈性擴(kuò)展，有悖分布式改造的初衷。同時(shí)亞馬遜、阿里等廠家在自身和云客戶的使用中也發(fā)現(xiàn)以服務(wù)器本地盤的方式部署，在存儲可靠性、爆炸半徑、綜合成本等方面存在難以解決的問題。

　　以某運(yùn)營商為例，在基于MySQL開源軟件自研的數(shù)據(jù)庫使用服務(wù)器本地盤部署的模式下，計(jì)算資源(CPU和內(nèi)存)與存儲資源(SSD磁盤)存在著不可調(diào)和的沖突(使用不均衡、擴(kuò)容受限、運(yùn)管困難等)，并帶來成本的增加。

　　而這類問題在互聯(lián)網(wǎng)、金融、運(yùn)營商一些云轉(zhuǎn)型企業(yè)中尤為突出：

　　-可靠性低：“服務(wù)器可靠性低，出問題數(shù)據(jù)無法訪問甚至就都丟了，必須用多從同步來補(bǔ)可靠性的缺口”，“服務(wù)器網(wǎng)絡(luò)抖動或磁盤亞健康問題很難監(jiān)控處理，影響系統(tǒng)穩(wěn)定性”，“服務(wù)器故障修復(fù)需要比較長時(shí)間，不能放太多實(shí)例”。

　　-運(yùn)維困難：“更換設(shè)備或擴(kuò)容需要搬遷數(shù)據(jù)庫，全量同步數(shù)據(jù)很慢”，“以前數(shù)據(jù)庫數(shù)量小，現(xiàn)單庫拆分成數(shù)10個實(shí)例，未來全網(wǎng)整改后，預(yù)計(jì)上千個實(shí)例，運(yùn)維太復(fù)雜”，“原來只有兩臺小型機(jī)，現(xiàn)在需要20多臺機(jī)器，4、5個機(jī)柜，機(jī)房和電都不夠了”。

　　-成本高：“存算綁定，無法彈性擴(kuò)容”，“資源閑置，CPU利用率低”，“為保證可靠性增加副本數(shù)，現(xiàn)有架構(gòu)成本是原來的1.5倍”。

　　怎么去解決分布式數(shù)據(jù)庫架構(gòu)上服務(wù)器本地盤部署這一系列問題呢?業(yè)界一直在不停的探索，2014年AWS首次推出了Aurora，阿里在2017年推出了PolarDB，華為云在2020年推出了GaussDB for MySQL，華為存儲也在2021年針對企業(yè)自建數(shù)據(jù)中心，推出OceanData分布式數(shù)據(jù)庫存算分離方案，希望基于成熟的基礎(chǔ)設(shè)施“云”化技術(shù)，解決分布式數(shù)據(jù)庫架構(gòu)上的短板。

　　業(yè)界云原生實(shí)踐：“存算分離”，共享存儲是分布式數(shù)據(jù)庫的最優(yōu)選擇

　　沒有一個概念和架構(gòu)是無緣無故憑空冒出來的，存算分離也是業(yè)界基于當(dāng)前分布式改造的現(xiàn)狀和本地盤部署的弊端不斷探索出來的，更是互聯(lián)網(wǎng)，數(shù)字化轉(zhuǎn)型企業(yè)的共同選擇。

　　存算分離帶來的四大價(jià)值：

　　-可靠性提升：外置共享存儲可靠性結(jié)合云原生故障隔離和遷移能力，解決一體化方案可靠性短板，并為降低資源冗余提供基礎(chǔ);

　　-資源優(yōu)化：解決數(shù)據(jù)快速移動，實(shí)現(xiàn)計(jì)算、存儲彈性擴(kuò)展，按需分配，減少因可靠性、運(yùn)維能力不足造成的硬件冗余;

　　-能力復(fù)用：使用共享存儲成熟的備份恢復(fù)、SSD介質(zhì)延壽、亞健康等能力，快速提升數(shù)據(jù)庫整體解決方案能力，節(jié)約開發(fā)成本;

　　-架構(gòu)先進(jìn)：基于開放生態(tài)存儲底座，可快速實(shí)現(xiàn)云原生數(shù)據(jù)庫能力，不影響上層應(yīng)用，實(shí)現(xiàn)平滑演進(jìn)。

　　各行業(yè)在數(shù)字化轉(zhuǎn)型中都面臨著業(yè)務(wù)量爆炸性增長，業(yè)務(wù)互聯(lián)網(wǎng)化等挑戰(zhàn)。為了在新形勢下提升服務(wù)體驗(yàn)，國內(nèi)某運(yùn)營商聯(lián)合華為開展創(chuàng)新和應(yīng)用實(shí)踐，采用分布式數(shù)據(jù)庫存算分離方案構(gòu)建高效BSS系統(tǒng)，實(shí)現(xiàn)了計(jì)算、存儲資源在線彈性擴(kuò)容，整體資源利用率從10%提升到50%;數(shù)據(jù)重建恢復(fù)全自動化，恢復(fù)時(shí)間從3小時(shí)縮短至5分鐘;共享存儲帶來設(shè)備級6個9高可靠。

　　總結(jié)

　　隨著5G、分布式技術(shù)、云計(jì)算技術(shù)的不斷發(fā)展，及各行業(yè)數(shù)字化轉(zhuǎn)型的不斷深入，數(shù)據(jù)庫云化、數(shù)據(jù)庫云原生架構(gòu)已成為趨勢，計(jì)算、存儲分離，采用共享存儲的方式是數(shù)字化轉(zhuǎn)型的企業(yè)共同的選擇。

特別提醒：本網(wǎng)信息來自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時(shí)聯(lián)系我們，本站將會在24小時(shí)內(nèi)處理完畢。