分散式關係型資料庫RadonDB體驗歸來

前段時間收到吳老師的邀請，是參加青雲QingCloud分散式資料庫(RadonDB)的一個技術體驗活動，從今天的技術體驗來算，收穫還是很多的，大家相聊甚歡，交流了很多工作中和工作之外的想法，原來那些我們看起來難走的路大家都曾經走過。

總體來說MySQL方向的目前的技術架構是一種看起來相對穩定的體系，一般來說傳統的主從複製，半同步，一主多從，到分庫分表，加上中介軟體，高可用，好像可玩的花樣就差不多這些了，所以基於這些我們只能說MySQL的這種使用方式是基於分散式架構，從CAP的角度來看，一致性（C)，可用性(A)，分割槽容忍性(P)方面很難都佔全。

說實話，最開始聽到RadonDB這個名字感覺很陌生，開啟技術架構圖，猛一看看好像沒有什麼特別的新意，所以開始的環境部署和簡單體驗其實是帶著一種挑剔的眼光來看的，提出一些體驗和相容性的小問題。

但是隨著下午和設計師雁飛和RadonDB團隊的深入交流，發現這個架構確實很有意思，能夠在已有的架構模式下玩出新的花樣，而且確實解決了分散式方案的基本需求，很難得。

我來簡單補充下產品裡面的亮點。

1.首先整個一套方案都是打算開源的，目前在青雲的產品線中已經可以體驗。從部署到使用，整個過程都是基於雲平臺來完成，基礎運維的成本很低。

2.從架構設計的角度來說，RadonDB的設計定位充分利用了MySQL的開源紅利，儲存節點是直接使用MySQL5.7的版本，可以把儲存計算的任務下沉到MySQL層面，所以他是一套完全基於MySQL定製的分散式方案，架構方式看起來比較輕量級。

3.對於關係型資料庫來說，要實現擴容影響面是很大的。RandonDB在這裡的實現，上層是基於hash，儲存模式是基於Range,即一個大表也可以根據片鍵值的範圍橫向擴充套件，比如一個大表是30G,那麼如果是分為30個分片，那麼沒一片的粒度就是1G,在這種代價下，做online DDL還是資料的遷移都是相對來說可控的粒度，我個人最欣賞的就是它在彈性擴容上的實現方式，能夠基於這種拆分思想，借鑑參考了Redis Cluster裡面類似的思想，根據細粒度的slot級別的資料來實現擴容。

4.在高可用上面值得一提的是一個獨立的工具MySQL Plus,這款工具可以基於5.7版本以上的GTID來滿足原來MHA所做的事情，然後基於半同步保證了資料的完整性，目前的整個一套方案都是基於Raft實現的。

當然還有些其他的細節方面也做了一些蠻不錯的改進：

1. 比如審計日誌的功能其實對於很多公司來說還是有審計需求的

2. mydumper的定製，是基於go來實現的，能夠充分利用go的一些優勢

3. 壓測工具也是基於go做的一層定製，從現場的高可用測試來看，體驗會好一些。

當然在體驗的過程中也發現了一些待改進的地方，有些是顯示資訊的補充和改進，有些則是技術實現方案上的建議等。我簡單提兩點：

首先，RandonDB的角色其實就是一箇中介軟體，類似ProxySQL,MyCAT之類的中介軟體，能夠實現基本的SQL轉發，這裡考慮到給以後的分散式事務設計帶來技術改進，目前的SQL Node是一個節點寫入，其他節點是隻讀的。

對於OLAP的業務支援，其實從RadonDB的SQL轉發，對於複雜，聚合的需求就可以直接下沉到計算節點，對於計算節點，目前的初步設計是使用外掛的方式來實現，設計團隊的初步設想是引入MariaDB columnstore類似的方案來實現，我有一個建議是也可以採用類似MPP的方式，畢竟MPP也是分散式方案的而一種，在這種架構模式下就會充分用到儲存多副本的優勢，比如多個副本，我們可以利用其中的一個或者兩個的副本來滿足AP的需求，這樣對於主庫的寫入侵入性是最小的，而且能夠發揮當前架構的特點，類似Greenplum中的segment節點的角色。

和RadonDB的團隊交流中發現，他們的團隊規模其實不大，但是支撐起來這樣一個產品，能夠快速迭代出來，著實讓人佩服。

RadonDB會在5月份開源釋出，其實開源的不只是產品，還是一種開放的態度，希望RadonDB能夠給我們的運維工作中帶來一些新的思路和改進。