什么是數據庫“存算分離”架構？

今天的話題要從一個朋友的咨詢開始

所以準備寫一篇短文談談我對“存算分離”架構的理解，不一定全面，歡迎在評論區探討。

其實這個朋友是誤解了“存算分離”這個概念。他認為普通MySQL云數據庫用evs做存儲，計算資源和存儲資源是分開的，比如可以單獨擴容計算資源或單獨擴容存儲資源，所以就是存算分離的架構，其實這么理解是片面的。要理解“存算分離”架構，還得追根溯源，從傳統MySQL主備架構說起。

這張圖熟悉MySQL的人應該都見過，我們知道，MySQL的master端有數據變更時，備機是通過讀取和回放binlog，涉及到三個線程，一個運行在主節點（log dump thread），其余兩個(I/O thread, SQL thread)運行在備節點，三個線程配合完成數據復制的工作。但是，不難發現，這個架構在某些場景會有明顯的缺陷：

主庫寫入壓力大時。當主庫的寫入壓力比較大的時候，主備復制的時延會變大，因為需要回放完所有binlog的事務才會完全達到數據同步。

增加只讀節點時。增加備機/只讀節點的速度很慢，因為我們需要將數據全量的復制到從節點，如果主節點此時存量的數據已經很多，那么擴展一個備機節點速度就會很慢高。

使用多個只讀節點時。存儲的成本線性增長，如果數據庫磁盤空間比較大，那么相應的所有只讀節點掛載的磁盤空間都需要和主節點一樣大，成本將會隨著只讀庫數量增加進行線性增加。

這些問題通過存算分離架構就能得到很好的解決，以華為云GaussDB（for MySQL）為例，作為華為自研的最新一代高性能企業級分布式數據庫，基于華為最新一代DFV分布式存儲，采用計算存儲分離架構，最高支持128TB的海量存儲，可實現超百萬級QPS吞吐。

首先，GaussDB（for MySQL）采用計算與存儲解耦的技術架構，讓所有的節點都共享一個存儲，也就是說，增加計算節點時，無需調整存儲資源，真正做到計算與存儲分離，并且可支持 15 個只讀節點的擴展，主節點和只讀節點之間是 Active-Active 的 Failover 方式，計算節點資源得到充分利用，由于使用共享存儲，降低了用戶使用成本。完美契合了企業級數據庫系統對高可用性、性能和擴展性、云服務托管的需求。GaussDB（for MySQL）將MySQL存儲層變為獨立的存儲節點，在GaussDB（for MySQL）中認為日志即數據，將日志徹底從MySQL計算節點中抽離出來，都由存儲節點進行保存，與傳統 RDS for MySQL 相比，不再需要刷 page，所有更新操作都記錄日志，不再需要 double write，從而大大減少了網絡通信。

小結一下，以“存算分離”架構來答復一下上面的3個問題：

1. 當主庫的寫入壓力比較大的時候，由于不再有double write入，主節點和只讀節點之間的復制時延基本得以消除。

2. 增加只讀節點的速度非常快，因為不再需要將數據全量的復制到只讀節點，無論多大數據量，只需 5 分鐘左右即可完成增加只讀節點。

3.?使用多個只讀節點時，因為只有一份存儲，所以存儲的成本不會有變化，存儲空間越大，只讀節點越多，節省成本越明顯。

云數據庫 MySQL 云數據庫 GaussDB(for MySQL) 數據庫 云原生

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。