論分散式資料庫TiDB架構的“存”與“算”
作者:何朝洋
在雲端計算基礎設施IaaS服務中,“存”與“算”的分界是清晰的,客戶會分別為“存”與“算”按需消費。不只是專門的儲存服務如S3、物件儲存、檔案儲存、NAS等,即使是在最基本的虛擬機器服務ECS上,“存”也需要由消費者進行選擇,而選擇的物件是雲盤,即位置對使用者透明,不需要消費者關心是否在計算節點的本地:其實連計算節點本身位於何處也是無需關心,又何談本地。隨著雲端計算服務的持續發展,“存”與“算”的界限,無論是從消費模式上,還是從技術上,都呈現出越來越清晰的趨勢。
而在PaaS層的資料庫服務中,則出現兩種情況。一種是“存”與“算”也由消費者分別選擇並擴縮,而另一種則是購買服務時,“存”與“算”是固定捆綁的架構組合,可以定義大小,但無法相對獨立地選擇、部署與擴縮。
引發上述資料庫服務不同消費模式的因素,實質上是在雲中部署的資料庫產品本身不同的技術架構,即“存”“算”分離,或“存”“算”一體。由於對單體資料庫談“存”與“算”的分離與一體,並沒有多大意義,因此,主要是針對分散式資料庫而言,其不同的特性帶來了業界較為廣泛的討論。
那麼,首先分析一下,在“存”“算”基礎設施愈來愈獨立清晰的趨勢下,建立在其上的資料庫服務“存”“算”一體現象從何來呢?不難發現,雲平臺上這樣的資料庫服務,大多都是基於“從非雲環境中、應企業級On Premise需求產生與發展而來”的資料庫產品。也就是說,其產品本初的設計理念就與“雲”無關,只是後來為了尋求不同的商業模式而部署在雲上而已;而大多數“存”“算”分離的資料庫產品,其創始之初,就面向雲環境進行設計,其中最典型的就是雲原生分散式資料庫TiDB。這裡,順便澄清一下現在極為流行的雲原生概念,相當多的人混淆了雲適配部署與雲原生的概念,認為只要部署在雲上,就是雲原生了。其實雲原生的概念與其字面意思極為直白契合,就是指在“雲環境”中“原生”的,而不是從別的地方遷來的,即**“雲原生”就是生長於雲上的,而非雲原生則是遷移到雲上的,這也正是TiDB區別於同類產品的設計初衷與架構特點**。這與要深入理解目前同樣火熱的NFT,就必須先正確理解“區塊鏈原生”概念的道理是一樣的。
相信現在,關於“雲”的問題應該是比較清晰了:“存”“算”分離是雲原生的架構,而“存”“算”一體則不是,這一點相信讀者不會有太多的疑問。那麼,接下來的問題是:“雲原生”就一定好嗎?面向企業級的需求,“存”“算”分離與“存”“算”一體孰優孰劣?
世界上本來就沒有絕對的好與絕對的壞,“存”“算”一體架構的設計,也是在滿足企業需求的過程中自然產生的,對分散式資料庫而言,“存”“算”一體的設計,無論是對傳統單體資料庫的替代上,還是對採用業務單元化策略的區域性性滿足上,還是對基於已有成熟資料庫體系以二次開發構建分庫分表資料庫產品的方便性上,都產生了積極的歷史作用。在那種情況下,不去考慮“雲”的趨勢與設計需求,也是合理的。
然而,過去幾十年的歷史已經證明,計算機技術的發展是極為迅速的,無論是軟體還是硬體,當然包括資料庫技術同樣如此。
首先,往遠處看的話:從電腦科學發展的角度,在雲端計算大趨勢的驅動下,“計算”與“儲存”技術相對獨立的發展道路已經越來越明顯,越來越清晰。可以想見,未來“計算”力相關的技術、架構與產品必將會發展到比如今所有極為先進的狀態;未來“儲存”相關技術、架構與產品也必將會進展到一個無法完全預計的嶄新階段,同時越來越“智慧”。並且從目前的形勢看,這個未來並不會太久遠,如TiDB這樣的“存”“算”分離架構無疑是適合那個未來的各種可能的,因為它本身就是為此而原生的,而“存”“算”一體在未來或許將變得無從談起;而從國際上先進資料庫技術發展的實際情況來看,絕大多數嶄新的、最前沿的資料庫相關技術與產品,都是雲原生的,換句話說,都是採用“存”“算”分離的架構,這一點,幾乎少有例外;而近期TiDB Cloud產品與相關的雲運營策略釋出與實施以後,為了在儲存與計算層面都能很適配各種優秀的雲基礎設施,“存”“算”分離的架構就顯得更加必要與先進了。
(或許可以猜測,把磁碟掛在本地這種現存商業計算機的架構,也是由企業/個體對計算機使用的商業模式驅動的,而不一定是技術驅動的必然結果)
其次,往近處看:對企業級現階段數字化轉型中,傳統單體資料庫替換的緊迫需求而言,大量的事實已經證明,TiDB“存”“算”分離的架構的雲原生架構的資料庫完全可以滿足各種實際的業務轉型需求:
. 對於企業線上彈性伸縮的業務發展需求,多地多中心多活的可靠性需求來講,雲原生架構無疑是最為得心應手的,因為這本就是其設計的初衷;
. 對於企業業務執行的效能訴求,首先從架構上並沒有分散式架構中“存”“算”分離就劣於“存”“算”一體的技術理由;同時,近年來國際上雲端計算基礎設施(存、算、網)的高速進展以及其上雲原生資料庫驚人的效能飛躍事實,也證明了雲原生資料庫的高效能與無限發展潛能;或許有人說“存”“算”一體同時還可以相容單體資料庫的優勢,1. 試問,在新一代業務發展升級對分散式資料庫提出強烈訴求的前提下,單體資料庫的適配還有意義嗎?2. 其實,雲原生資料庫廠商如果想做,也完全可以實現對單體資料庫的相容。但大多數的雲原生資料庫開發者並不想做這樣的事情:有開發頻寬為什麼不用在更有意義的進展上呢?
. 對於從傳統資料庫時代就一直強調的、CPU級別的多租戶功能,試問:在現階段K8S容器化雲端計算標準環境進展普及如此迅猛的時代,這個級別的多租戶還有意義嗎?其實還是同樣的邏輯,這樣的功能開發也並不困難,雲原生的廠商應該也不會把頻寬優先放到這裡來;
. 對於企業降本增效的訴求,“存”“算”分離不但可以各自根據“計算”與“儲存”不同的發展速度(多數情況下各有增長快慢)與不同的服務級別要求(有的是計算要求高,有的是資料量大)靈活設計各自的方案規模,同時,對於膾炙人口的通過資料壓縮“降本”,很明顯也是“存”“算”分離能夠真正產生降本的實效,因為它可以把“降本”與“增效”分開來看,而不是“降本”的同時必須“降效”,那這種降本的意義就會大打折扣。
例子還有很多.......
還有一個比較重要的方面: TiDB一直認為自己最開始並不是面向開發一個數據庫而設計的,其最初的價值觀就是提供未來社會的新一代“資料服務平臺”,因此它更加需要一個“存”“算”分離的設計架構,而不是傳統資料庫領域最常見的存算一體。
最後還有一點需要強調:除了TiDB Cloud之外,對於其它將“雲”策略當成技術與業務核心發展戰略的企業來講,雲原生架構無論是面向現在與未來,自然是最為適合的;
或許可以這樣說,“存”“算”一體的架構是現代分散式資料庫技術進化過程中的一個重要過渡階段,其歷史作用不可否認,毋庸質疑;而不久的將來,以TiDB為典型代表與先行者的分散式資料庫架構向雲原生快速發展普及的趨勢將會越來越明顯,步伐將會越來越加快......
世界潮流,浩浩蕩蕩;順之者昌,逆之者亡,順應歷史的潮流與趨勢的選擇一般都是明智的。
- TiFlash 儲存層概覽
- TiFlash 計算層概覽
- TiCDC 架構和資料同步鏈路解析
- TiKV & TiFlash 加速複雜業務查詢
- 讓秒殺狂歡更從容:大促背後的資料庫(下篇)
- TiCDC 6.0原理之Sorter演進
- TiDB 之 TiCDC6.0 初體驗
- 帶你全面瞭解compaction 的13個問題
- TiDB 6.1 新特性解讀 | TiDB 6.1 MPP 實現視窗函式框架
- TiFlash 面向編譯器的自動向量化加速
- 你踩過這些坑嗎?謹慎在時間型別列上建立索引
- TiDB和C#的簡單CRUD應用程式
- TiDB VS MySQL
- TIDB監控升級解決panic的漫漫探索之路
- 記憶體悲觀鎖原理淺析與實踐
- TiDB 效能分析&效能調優&優化實踐大全
- TiDB 效能分析和優化
- tiflash 6.0 on k8s擴容與新特性實踐
- 論分散式資料庫TiDB架構的“存”與“算”
- MySQL正常執行的SQL在TiDB中變慢了