都說“存算分離”好，分布式數(shù)據(jù)庫為何還要“進(jìn)一步分離”？

歷史上，數(shù)據(jù)庫“存算一體”和“存算分離”的變更

第一代的“存算一體”數(shù)據(jù)庫是80年代的IBM大機(jī)，提供計算、數(shù)據(jù)庫、存儲、中間件，解決了核心交易場景對性能和可靠性的訴求，但他的缺點同樣明顯，貴！高昂的采購費用、封閉的硬件生態(tài)和高昂的售后維保價格，大機(jī)的壟斷，即使是銀行這類不差錢的企業(yè)也感到肉疼。大機(jī)有限的存儲擴(kuò)展能力，也限制了數(shù)據(jù)庫的容量。

隨著商用數(shù)據(jù)庫和高端存儲的發(fā)展，IOE架構(gòu)出現(xiàn)了。IOE指以IBM小型機(jī)、Oracle數(shù)據(jù)庫和EMC存儲設(shè)備為代表的IT基礎(chǔ)體系。這一架構(gòu)極為“先進(jìn)”和“開放”，打破了大機(jī)的壟斷，在性能和可靠性上也完全滿足企業(yè)業(yè)務(wù)的訴求。這一架構(gòu)的出現(xiàn)，讓數(shù)據(jù)庫從“存算一體”，走向了“存算分離”。諷刺的是，隨著這一架構(gòu)的發(fā)展，形成了新的壟斷。

隨著云和互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，數(shù)據(jù)量和用戶量激增，雙11購物節(jié)、12306春運搶票等突發(fā)業(yè)務(wù)對數(shù)據(jù)庫業(yè)務(wù)造成了巨大的沖擊。IOE架構(gòu)欠缺橫向擴(kuò)展能力，讓數(shù)據(jù)庫無法滿足激增的性能訴求和靈活擴(kuò)容訴求。

芯片技術(shù)持續(xù)發(fā)展，Intel的Tick-Tock策略，讓芯片制程和架構(gòu)以每兩年一次的周期進(jìn)行更新，CPU的性能隨之水漲船高。X86通用服務(wù)器享受到了這一紅利，其性能越來越高，成本越來越低。ARM生態(tài)的持續(xù)發(fā)展，讓ARM架構(gòu)的處理器在服務(wù)器領(lǐng)域也開始嶄露頭角，讓企業(yè)擁有了更多的選擇。分布式數(shù)據(jù)庫無最大節(jié)點數(shù)的限制，巨大的性能沖擊可分散到海量的服務(wù)器集群并發(fā)處理。用戶需求的催化和服務(wù)器硬件的發(fā)展，使得分布式數(shù)據(jù)庫‘火’了起來。

分布式數(shù)據(jù)庫部署靈活，極為契合云原生應(yīng)用使用場景，再加上企業(yè)擺脫IOE依賴的商業(yè)考量，企業(yè)紛紛嘗試使用通用服務(wù)器打造靈活易擴(kuò)展的分布式數(shù)據(jù)庫，數(shù)據(jù)庫由“存算分離”再次轉(zhuǎn)向“存算一體”。

“存算一體”架構(gòu)

數(shù)據(jù)庫“存算一體”不是終極解決方案

從歷史上的“存算一體”和“存算分離”變更來看，客戶需求和業(yè)務(wù)需求的變化才是推動架構(gòu)變更的根源。

那么，當(dāng)前“存算一體”的架構(gòu)是否完全滿足客戶和業(yè)務(wù)的訴求呢？答案是否定的。

企業(yè)試水分布式數(shù)據(jù)庫的初期，數(shù)據(jù)量不大，整個集群的規(guī)模有限，運行的往往不是最核心的業(yè)務(wù)，對性能和可靠性的要求相對不高。隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量持續(xù)增加，分布式數(shù)據(jù)庫單庫性能較差，需要拆分成500G左右的分片。為了滿足性能和可靠性要求，企業(yè)往往通過堆疊服務(wù)器來解決，導(dǎo)致數(shù)據(jù)庫集群的規(guī)模越來越大，TCO持續(xù)增加。

為了實現(xiàn)高可靠，分布式數(shù)據(jù)庫通常采用1主多從的架構(gòu)，多個從節(jié)點大部分時間都處于閑置狀態(tài)，導(dǎo)致CPU資源利用率極低。每一臺服務(wù)器就是一個數(shù)據(jù)孤島，存儲無法按需分配，數(shù)據(jù)在服務(wù)器間流動困難，導(dǎo)致存儲利用率低且存在單點性能瓶頸。服務(wù)器故障后，無法自動切換，需投入大量人力和時間手工恢復(fù)數(shù)據(jù)，可用性變差。某運營商的核心分布式數(shù)據(jù)庫，CPU平均利用率7%，存儲利用率低于40%，節(jié)點故障平均4TB數(shù)據(jù)需要投入5人3小時恢復(fù)，分布式數(shù)據(jù)庫“存算一體”架構(gòu)資源浪費和可用性差已經(jīng)成為了企業(yè)的核心之痛。

分布式數(shù)據(jù)庫“存算分離”如何解決企業(yè)核心之痛

“存算分離”架構(gòu)

“存算一體”架構(gòu)需要考慮CPU、內(nèi)存、存儲容量/IOPS/帶寬，網(wǎng)絡(luò)IO/帶寬，多達(dá)7個維度，任意一個維度的資源不滿足就會導(dǎo)致無法滿足應(yīng)用訴求。而“存算分離”，按照計算和存儲兩個維度，將這7個維度拆分為兩個領(lǐng)域，降低選型復(fù)雜度。分別構(gòu)建計算資源池和存儲資源池，提升資源利用率。擴(kuò)容可實現(xiàn)計算和存儲的按需擴(kuò)容，節(jié)約投資。

外置存儲陣列本身有非常好的可靠性設(shè)計，如RAID冗余、靜默數(shù)據(jù)校驗、兩地三中心等可靠性保障，其可靠性等級高于服務(wù)器至少兩個數(shù)量級，因此存儲應(yīng)該是一個“長期”的共享存儲。服務(wù)器的可靠性偏弱，“存算分離”后，即使服務(wù)器故障，由于全局共享一份數(shù)據(jù)，可實現(xiàn)免數(shù)據(jù)復(fù)制快速恢復(fù)業(yè)務(wù)，實現(xiàn)分布式數(shù)據(jù)庫整體的高可用。

采用“存算分離”架構(gòu)后，由于全局共享一份數(shù)據(jù)，一些不必要的消耗可以被避免，可提升數(shù)據(jù)庫整體的性能表現(xiàn)。例如半同步，每增加一個從節(jié)點都會導(dǎo)致10%的性能下降。采用“存算分離”后，不再需要半同步技術(shù)。

外置存儲陣列對性能的優(yōu)化更加深入，全閃存存儲，尤其是全NVME的存儲，可提供極致的性能體驗。存儲共享資源池不僅可提升資源利用率，還能利用不同應(yīng)用不同時間對存儲性能峰谷要求不同的特點，將所有的IO分散到所有的磁盤，實現(xiàn)削峰填谷，達(dá)到最佳性能。

“存算分離”將走向何方

著名開源數(shù)據(jù)庫TiDB創(chuàng)始人黃東旭在《近十年數(shù)據(jù)庫流行趨勢縱覽！存儲計算分離、ACID 全面回歸......》一文中將“存儲和計算進(jìn)一步分離”作為近年數(shù)據(jù)庫流行趨勢之首。那么‘進(jìn)一步分離’到底如何做呢？且看業(yè)界大牛的做法。

阿里副總裁，數(shù)據(jù)庫產(chǎn)品事業(yè)部總裁李飛飛在《云原生分布式數(shù)據(jù)庫與數(shù)據(jù)倉庫系統(tǒng)點亮數(shù)據(jù)上云之路》一文中，提出了下一代分布式數(shù)據(jù)庫系統(tǒng)架構(gòu)，在“存算分離”的基礎(chǔ)上繼續(xù)將原本在服務(wù)器間進(jìn)行同步的Redo Log下推到共享存儲資源池，不再需要同步日志，減少了服務(wù)器主從同步的消耗。

亞馬遜的首席技術(shù)官兼副總裁在Werner Vogels在《Amazon Aurora 是如何設(shè)計原生云關(guān)系型數(shù)據(jù)庫的？》一文中介紹Aurora的“存算分離”架構(gòu)。這一架構(gòu)將在“存算分離”的基礎(chǔ)上，將原來在計算節(jié)點處理的緩存層和日志層功能下推到共享存儲，可提升5倍的寫IOPS。

2022年1月20日，阿里對多主架構(gòu)進(jìn)行了灰度發(fā)布，面向多租戶、游戲、電商等高并發(fā)讀寫的應(yīng)用場景，實現(xiàn)從一寫多讀架構(gòu)到多寫多讀架構(gòu)的升級。多主架構(gòu)是為了解決寫性能瓶頸問題。

同阿里一樣，亞馬遜從Aurora MySQL 版本1開始，提供了多主集群和多寫能力，在多主集群中，所有數(shù)據(jù)庫實例都可以執(zhí)行寫操作，以提供故障時的“持續(xù)可用性”。

在2021年第四屆中國金融科技產(chǎn)業(yè)峰會上，華為攜手愛可生、海量數(shù)據(jù)發(fā)布的分布式數(shù)據(jù)庫存儲解決方案，提出通過數(shù)據(jù)多寫使能引擎、數(shù)據(jù)共享加速引擎、數(shù)據(jù)持久保護(hù)引擎，三大引擎技術(shù)重新定義分布式數(shù)據(jù)庫‘存算分離’架構(gòu)。

這一架構(gòu)采用華為的OceanStor Dorado全閃存作為共享存儲資源池，支持分布式數(shù)據(jù)庫多主架構(gòu)，支持多寫多讀，免分庫分表，提升計算密度。將page管理和日志管理下推到OceanStor Dorado全閃存，讓企業(yè)存儲來取代服務(wù)器做數(shù)據(jù)同步，降低服務(wù)器開銷，提升數(shù)據(jù)庫整體性能。

今天，各個廠商，不論是國外國內(nèi)，不論是互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)ICT企業(yè)，關(guān)于分布式數(shù)據(jù)庫“存算分離”的看法和做法，都是一致的。即在“存算分離”的基礎(chǔ)上，進(jìn)一步將原服務(wù)器運行的數(shù)據(jù)庫存儲引擎功能進(jìn)一步下推至共享存儲，釋放計算節(jié)點的算力，提升單節(jié)點數(shù)據(jù)處理能力；推出多主架構(gòu)，拋棄從節(jié)點，節(jié)省大量服務(wù)器投資；支持多寫多讀，充分發(fā)揮共享存儲資源池共享一份數(shù)據(jù)的優(yōu)勢，免數(shù)據(jù)拷貝，降低故障切換時間。

未來，共享存儲必將取代傳統(tǒng)的分布式數(shù)據(jù)庫存儲引擎功能，結(jié)合容器技術(shù)，分布式數(shù)據(jù)庫將完成無狀態(tài)化改造。

生成海報

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

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